INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-12.txt Columbia University July 12, 2001 Erik Guttman Expires: January 12, 2002 Sun Microsystems mSLP - 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: January 12, 2002 [Page 1]
Internet Draft DA Interaction July 12, 2001 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. However, 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 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 simplifies SA registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. Currently, there are three types of DA message flows in SLPv2 [1]: acknowledging SA registrations, answering UA queries and enabling 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. 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 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. Zhao, et al. Expires: January 12, 2002 [Page 2]
Internet Draft DA Interaction July 12, 2001 Mesh-aware SA A mesh-aware SA understands the "mesh-enhanced" attribute keyword in the DAAdvert and uses the Mesh Forwarding extension 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 from mesh-aware SAs, the first mesh-enhanced DA that accepts the update is the Accept DA for the update. Normally, a registration update is propagated from its Accept DA to other DAs in the registration scopes. Accept Timestamp The Accept Timestamp of a registration update is the millisecond-accuracy system clock value at its Accept DA when the update is accepted. Any two updates accepted by the same DA MUST have different Accept Timestamps. Version Timestamp A mesh-aware SA MUST provide a Version Timestamp in the Mesh Forwarding extension for each SrvReg/SrvDeReg message sent to a mesh-enhanced DA. This Version Timestamp is the millisecond-accuracy system clock value at the SA when it issues the message. Any two SrvReg/SrvDeReg messages from the same SA MUST have different Version Timestamps. 3. 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. To enhance SLP DA services and simplify SA registrations, mSLP defined a fully-meshed peering DA architecture based on service scopes. The first part of this architecture is on DA peer relationship management. DAs that share service scopes are peers. Peer DAs may have exactly the same service scopes or only one scope in common. Each pair of peer DAs maintain a single persistent peering connection which provides a reliable FIFO channel for their message exchange. In other words, there is a set of fully-meshed peering connections among peer DAs. Zhao, et al. Expires: January 12, 2002 [Page 3]
Internet Draft DA Interaction July 12, 2001 In Figure 1, as DA3 shares service scopes with DA1, DA2 and DA4, it maintains peering connections to them and exchanges registration updates with them in scope y, y and z, respectively. DA1 and DA2 have exactly the same service scopes, they exchange registration updates in scope x and y using a single peering connection. +-----------+ | DA4 (z) | +-----------+ | (z) +-----------+ (y) +-----------+ (y) +-----------+ | DA1 (x,y) | ---------- | DA3 (y,z) | ---------- | DA2 (x,y) | +-----------+ +-----------+ +-----------+ | (x,y) | +-------------------------------------------------+ Figure 1. Fully-meshed Peering Relationships among DAs The second part of this architecture is on registration update propagation control. 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. This 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. 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. This architecture also 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. Furthermore, this architecture 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. 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. 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 registrations will then be propagated automatically to other DAs in their scopes. In Figure 2, SA1 may choose to register with DA2 only or to register with both DA1 and DA3. For compatibility reason, mSLP supports two registration models: the original SLPv2 model in which an SA Zhao, et al. Expires: January 12, 2002 [Page 4]
Internet Draft DA Interaction July 12, 2001 registers with all DAs and the new model in which a mesh-aware SA uses the Mesh Forwarding extension to request that mesh-enhanced DAs distribute its registrations. By simplifying SAs, the overall SLP system scalability can be improved. (x) +-----------+ (y) +----------------- | SA1 (x,y) | -----------------+ | (option2) +-----------+ (option2) | | (x,y) | (option1) | +---------+ (x) +-----------+ (y) +---------+ | DA1 (x) | ----------- | DA2 (x,y) | ----------- | DA3 (y) | +---------+ +-----------+ +---------+ Figure 2. Options for Registration with Mesh-enhanced DAs For easy of presentation, we first focus discussion only on mesh- enhanced DAs and mesh-aware SAs (Section 4, 5), then address the mixed deployment of mesh-enhanced DAs, non-mesh-enhanced DAs, mesh- aware SAs and non-mesh-aware SAs, and mSLP compatibility with SLPv2 (Section 6). 4. Registration Update Propagation Control mSLP defined a new SLP message - Data Request, and a new SLP extension - Mesh Forwarding for registration update propagation control. A mesh-enhanced DA MUST support the Data Request message and the Mesh Forwarding extension. 4.1. Accept ID and Propagation Order An Accept ID has two components: Accept DA and Accept Timestamp. Each registration update has a unique Accept ID, and 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. Figure 3 shows 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept Timestamp, cont'd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Accept DA URL | Accept DA URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Accept ID Zhao, et al. Expires: January 12, 2002 [Page 5]
Internet Draft DA Interaction July 12, 2001 Accept IDs define a total order for all updates accepted by the same DA and a partial order for all updates in the system. Thus, Accept IDs can be used to propagate registration updates in order. In mSLP, a mesh-enhanced DA MUST propagate registration updates in the increasing order of their Accept IDs, which means that all updates accepted by the same DA MUST be propagated in the increasing order of their Accept Timestamps, and updates accepted by different DAs MAY be propagated in any orders. The ordering propagation enables a receiving DA to represent its received registration updates using a State Summary, i.e., up to what points (in term of Accept Timestamps) the receiving DA has received updates accepted by DAs in its peer set. A State Summary at a DA 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 it means that DAi has received all registration updates 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 this update MUST be bigger than the corresponding entry in its State Summary - if there is no corresponding entry in its State Summary, the receiving DA needs to add an entry for this Accept DA. If a received update has a smaller Accept ID (this indicates an error), the receiving DA SHOULD discard the update. The ordering propagation ensures that no update is missed for propagation. By using the State Summary, 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). 4.2. 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 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 doesn't need to compare Version Timestamps from two different SAs. Zhao, et al. Expires: January 12, 2002 [Page 6]
Internet Draft DA Interaction July 12, 2001 A mesh-enhanced DA installs a registration update if and only if the update 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). As incremental registrations and partial deregistrations may result in incomplete registration states, especially when updates are propagated, a mesh-aware SA MUST use the Mesh Forwarding extension with a fresh SrvReg and a complete SrvDeReg only. 4.3. Mesh Forwarding Extension The Mesh Forwarding (MeshFwd) extension is used in the 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 Forward 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 A mesh-aware 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) forward the message. In other words, a mesh-enhanced DA propagates a registration update from an SA if and only if the update has the RqstFwd Mesh Forwarding extension. A mesh-enhanced DA uses the Fwded Mesh Forwarding extension (Fwd-ID = Fwded, Accept Timestamp != 0) in a forwarded SrvReg/SrvDeReg message sent from it to another DA. 4.4. Data Request Message The Data Request (DataRqst) message carries an Accept ID. Its Function-ID is 12. Figure 5 shows its format. Zhao, et al. Expires: January 12, 2002 [Page 7]
Internet Draft DA Interaction July 12, 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 = DataRqst = 12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Accept ID \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. DataRqst Message The DataRqst message is used by a mesh-enhanced DA to request new registration states from a peer. The requested new registration states have the same Accept DA as the specified Accept DA in the DataRqst message, but have a bigger Accept Timestamp. Note that one DataRqst message pulls new registration states of one Accept DA at a time; pulling new registration states of all Accept DAs needs to use multiple DataRqst messages with different Accept DAs. 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 in the increasing order of their Accept Timestamps (Figure 6). 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 SrvDeReg. +-----+ DataRqst +-----+ | | -------------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <------------------------------------------- | | +-----+ New Registration States via Srv(De)Reg(s) +-----+ Figure 6. Pulling New Registration States via a DataRqst As mSLP uses the fully-meshed peering DA architecture, normally a mesh-enhanced DA only needs to pull new registration states directly from their Accept DAs. Only when failures occur, it needs to pull new registration states indirectly. For example, DA1 with scope x and y, DA2 with scope x, and DA3 with scope y have already set up peer relationships. Now DA1 crashes, then DA4 with scope x and y joins, and DA4 wants to get all existing registrations accepted by DA1, DA2, and DA3. DA4 pulls DA2 and DA3 accepted registrations directly from DA2 and DA3, respectively, but pulls DA1 accepted registrations indirectly from DA2 for scope x and from DA3 for scope y (Figure 7). Zhao, et al. Expires: January 12, 2002 [Page 8]
Internet Draft DA Interaction July 12, 2001 DA4 ---- DataRqst (DA2, 0) ---> DA2 DA4 ---- DataRqst (DA3, 0) ---> DA3 DA4 ---- DataRqst (DA1, 0) ---> DA2 DA4 ---- DataRqst (DA1, 0) ---> DA3 Figure 7. Pulling New Registration States Directly and Indirectly The DataRqst message is used in the initial population exchange among peer DAs. It is also used after failures (DA crashes and network partitions) to enable peer DAs to catch up the difference of their observed registration updates. The DataRqst message enables a lightweight anti-entropy [5, 6] among peer DAs. In the traditional anti-entropy, a DA pulls updates of all Accept DAs in one round (in this case the DataRqst should carry a list of Accept IDs - the State Summary of the sending DA, not only one Accept ID), but the DA needs to pull updates from one peer at a time, otherwise it will get repeated updates. In mSLP, a DA pulls updates of one Accept DA at a time from a peer, thus a newly joined (rebooted, or reconnected) DA can directly pull updates from all existing peer DAs at the same time without getting repeated updates. This data pulling scheme is simple for use, efficient in the normal case (no failures) and flexible to support different requirements. 4.5. Propagation Model Once a mesh-enhanced DA has sent all new registration updates accepted by itself to a peer in answering the peer's DataRqst, it starts to direct forward newly received updates from mesh-aware SAs to the peer in a push fashion. If any failure occurs in the direct forwarding, a mesh-enhanced DA MUST stop the direct forwarding to the peer. The typical update propagation model from DA1 to DA2 is a loop of the following four steps. (1) DA1 receives a DataRqst (DA1, TSx) from DA2. (2) DA1 sends new states to DA2 in answering DA2's DataRqst. (3) DA1 direct forwards DA1 accepted updates to DA2. (4) DA1 stops direct forwarding to DA2 if any failure occurs. 4.6. Direct Forwarding In Figure 8, when DA1 directly forwards an update from SA1 to DA2, it sets the message's Fwd-ID to Fwded and changes the message's Accept Timestamp to its arrival timestamp. A direct forwarding is performed asynchronously, DA1 can send a SrvAck to SA1 before it gets the SrvAck from DA2. Zhao, et al. Expires: January 12, 2002 [Page 9]
Internet Draft DA Interaction July 12, 2001 +-----+ RqstFwd Srv(De)Reg +-----+ Fwded Srv(De)Reg +-----+ | | ---------------------> | | ---------------------> | | | SA1 | (Peering Connection) | DA1 | (Peering Connection) | DA2 | | | <--------------------- | | <--------------------- | | +-----+ SrvAck +-----+ SrvAck +-----+ Figure 8. Direct Forwarding of a SrvReg/SrvDeReg Note that the direct forwarding of a registration update only goes one-hop from its Accept DA to other DAs in the registration scopes. 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. 4.7. SrvDeReg Messages When a SrvDeReg arrives, a mesh-enhanced DA needs to mark the corresponding service entry in the database as deleted so that the entry will not appear in any query reply. However, no matter a deregistered service entry exists or not, a mesh-enhanced DA needs to 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.8. SrvAck Messages A mesh-enhanced DA MUST properly reply with a SrvAck to a SrvReg/SrvDeReg no matter the message is received from an SA or from a peer DA. Also, a mesh-enhanced DA MUST properly handle SrvAck messages from its peer DAs. 4.9. Control Information for Each Registration URL For each registration URL from mesh-aware SAs, a mesh-enhanced DA needs to maintain the following control information: the latest update (SrvReg or SrvDeReg), Accept ID (for update propagation), and Version Timestamp (for registration version resolution - rejecting previous updates). 4.10. State Summary for All Received Registrations A mesh-enhanced DA needs to maintain a State Summary 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 State Summary directly, otherwise, the DA needs to update its State Summary on scope basis. Consider the example in Figure 7, when DA4 receives DA1 accepted registrations from DA2, it updates DA1 latest Zhao, et al. Expires: January 12, 2002 [Page 10]
Internet Draft DA Interaction July 12, 2001 Accept Timestamp for scope x, similarly, when DA4 receives DA1 accepted registrations from DA3, it updates DA1 latest Accept Timestamp for scope y. Thus, when pulling new registration states form a peer indirectly via a DataRqst, a mesh-enhanced DA needs to use a scope-based Accept ID. 5. Peer Relationship Management A mesh-enhanced DA maintains a peer table. For each peer, the DA needs to keep the peer DAAdvert and a reference to the peering connection. 5.1. Learning about a New Peer A mesh-enhanced DA can learn about a new peer 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 obtain a DAAdvert from a new peer before establishing the peer relationship to it. 5.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 to the peer, then it MUST create such a connection and send its DAAdvert via the connection (Figure 9). A mesh-enhanced DA can identify a peering connection initiated by a peer by receiving the peer's DAAdvert from the connection. +-----+ (1) DA2 DAAdvert | +-----+ | | <--------------------+ | | | DA1 | (2) Create a Peering Connection | DA2 | | | ---------------------------------------> | | +-----+ (3) DA1 DAAdvert +-----+ Figure 9. Establishing a Peering 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. 5.3. 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 of its existing peers and the Accept DAs in its State Summary to the new peer (Figure 10). The DAAdvert forwarding Zhao, et al. Expires: January 12, 2002 [Page 11]
Internet Draft DA Interaction July 12, 2001 enables a DA to learn peers incrementally from its known peers, and to know the Accept DA set of the new peer. +-----+ DAAdvert(s) of DA1's Peers +-----+ | | ---------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <--------------------------------------- | | +-----+ DAAdvert(s) of DA2's Peers +-----+ | | V DA2 DAAdvert DA1 DAAdvert V +----------------------+ +----------------------+ | DA1's Existing Peers | | DA2's Existing Peers | +----------------------+ +----------------------+ Figure 10. Forwarding DAAdvert Messages 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 11) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 8). +-----+ DA1 DAAdvert +-----+ | | ---------------------------------------> | | | DA1 | (Peering Connection) | DA2 | | | <--------------------------------------- | | +-----+ DA2 DAAdvert +-----+ Figure 11. 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. Compatibility and Incremental Deployment 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 Zhao, et al. Expires: January 12, 2002 [Page 12]
Internet Draft DA Interaction July 12, 2001 kept unchanged. SAs can simplify their service registrations by using the RqstFwd Mesh Forwarding extension. mSLP supports incremental deployment of mesh-enhanced DAs and mesh- aware SAs. In a mixed deployment of mesh-enhanced DAs, non-mesh- enhanced DAs, mesh-aware SAs and non-mesh-aware SAs, there are six types of interactions among DAs and SAs. Mesh-enhanced DAs vs. Mesh-enhanced DAs A mesh-enhanced DA interacts with other mesh-enhanced DAs as described in Section 4 and 5 of this document. Mesh-enhanced DAs vs. Mesh-aware SAs A mesh-enhanced DA interacts with mesh-aware SAs as described in Section 4 of this document. Mesh-enhanced DAs vs. Non-mesh-enhanced DAs A mesh-enhanced DA MUST establish a TCP connection with non-mesh-enhanced DAs in its scopes, and forward newly received SrvReg/SrvDeReg messages on behalf of mesh-aware SAs to non-mesh-enhanced peers (registrations from non- mesh-aware 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 doesn't send the DataRqst message, nor DAAdvert messages of other DAs to a non-mesh-enhanced peer. Mesh-enhanced DAs vs. Non-mesh-aware SAs A mesh-enhanced DA operates in the same way as a non-mesh- enhanced DA [1] for all non-mesh-aware SAs. Mesh-aware SAs vs. Non-mesh-enhanced DAs If there are no mesh-enhanced DAs cover its scopes, for uncovered scopes, a mesh-aware SA operates in the same way as a non-mesh-aware SA [1] to interact with non-mesh- enhanced DAs. Non-mesh-aware SAs vs. Non-mesh-enhanced DAs They operate as described in [1]. In a mixed deployment of mesh-enhanced DAs and non-mesh-enhanced DAs, 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, therefore, uniform deployment of mesh-enhanced DAs is much more desirable than partial deployment. Zhao, et al. Expires: January 12, 2002 [Page 13]
Internet Draft DA Interaction July 12, 2001 7. 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 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-aware SA It only needs to discover 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 message MUST be sent AND processed. Also, it accepts registrations from SAs and mesh-enhanced DAs, propagates registrations in order and processes SrvAck messages from mesh-enhanced DAs. Furthermore, it SHOULD forward the DAAdvert message from a new peer to its existing peers and vice versa. 8. Constants Mesh Forwarding Extension ID 6 (Section 4.3) Data Request Message Type 12 (Section 4.4) CONFIG_DA_KEEPALIVE 200 seconds (Section 5.4) CONFIG_DA_TIMEOUT 300 seconds (Section 5.4) 9. 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, a successful attack at a mesh-enhanced DA may affect all DAs in the meshed DA set, a mesh- Zhao, et al. Expires: January 12, 2002 [Page 14]
Internet Draft DA Interaction July 12, 2001 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 malicious mesh-enhanced DA. 10. 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. 11. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Email: Erik.Guttman@sun.com Zhao, et al. Expires: January 12, 2002 [Page 15]
Internet Draft DA Interaction July 12, 2001 12. 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: January 12, 2002 [Page 16]