INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-08.txt Columbia University Expires: March 30, 2001 Erik Guttman Sun Microsystems September 30, 2000 mSLP - Mesh-enhanced Service Location Protocol draft-zhao-slp-da-interaction-08.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 (2000). All Rights Reserved. Abstract This document presents mSLP - the Mesh-enhanced Service Location Protocol, which enhances SLP with a fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange service registration information and maintain the same consistent data for shared scopes. mSLP improves the reliability and consistency of SLP directory services. It also greatly simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. Zhao, et al. Expires: March 30, 2001 [Page 1] Internet Draft DA Interaction September 30, 2000 1. Introduction In the Service Location Protocol (RFC 2608 [1]), Directory Agents (DAs) are introduced for caching service advertisements from Service Agents (SAs), and answering queries from User Agents (UAs). They exist to enhance the performance and scalability of SLP. When multiple DAs are present, how should they interact with each other? This is an open issue in SLPv2. This document presents mSLP - the Mesh-enhanced Service Location Protocol, which defines a scheme for the interaction of SLP DAs. mSLP proposes that if DAs are needed in an SLP system, 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 data for shared scopes when they set up a peer relationship, and continue to exchange new service registration information 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: Section 2 defines the terminology. Section 3 reviews the current DA message flows in SLPv2. Section 4 defines the mesh control message type and the mesh-forwarding extension. In Section 5, we describe the DA peer relationship. In Section 6, we present the message forwarding control among DAs. We discuss our design in Section 7, list constants in Section 8, and give security considerations in Section 9. 2. Terminology Peer DAs: They have one or more scopes in common within one administrative domain. Peer DAs coordinate with each other and maintain the same consistent data for shared scopes. Peering Connection: It is a persistent TCP connection kept by a pair of peer DAs for the entire peering period. It provides a reliable communication channel for the peer DAs to exchange messages. Therefore, a DA implementation is not burdened by managing message retransmissions. The closing of the connection terminates the peer relationship. Mesh-enhanced DA: It maintains a peering connection to each of its peers and forwards messages to its peers according to the rules given in Section 6. Such a DA MUST carry the "mesh-enhanced" attribute keyword in its DAAdvert messages. Zhao, et al. Expires: March 30, 2001 [Page 2] Internet Draft DA Interaction September 30, 2000 Mesh-aware SA: It understands the "mesh-enhanced" attribute in DAAdvert messages and uses the mesh-forwarding capability of mesh- enhanced DAs for its service registrations. 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 [5]. 3. DA Message Flows in SLPv2 This section reviews the DA message flows defined in SLPv2. Figure 1 illustrates SA registrations with DAs. For each service registration (SrvReg) and deregistration (SrvDeReg) message, a DA replies with a service acknowledgment (SrvAck) message. +----+ +----+ | | --- SrvReg/SrvDeReg --> | | | SA | | DA | | | <------- SrvAck ------- | | +----+ +----+ Figure 1. SA Registrations Figure 2 shows UA queries with DAs. A DA replies with a service reply (SrvRply) message to a service request (SrvRqst) message, a service type reply (SrvTypeRply) message to a service type request (SrvTypeRqst) message, and an attribute reply (AttrRply) message to an attribute request (AttrRqst) message. +----+ +----+ | | ----- SrvTypeRqst/SrvRqst/AttrRqst ----> | | | UA | | DA | | | <---- SrvTypeRply/SrvRply/AttrRply ----- | | +----+ +----+ Figure 2. UA Queries Figure 3 depicts DA discovery. A DA replies with a unicast DA advertisement (DAAdvert) message to a multicast SrvRqst message which has "service:directory-agent" as service type. +-------+ Multicast SrvRqst +----+ | | ----- (service:directory-agent) ----> | | | UA/SA | | DA | | | <-------- Unicast DAAdvert ---------- | | +-------+ +----+ Figure 3. DA Discovery Zhao, et al. Expires: March 30, 2001 [Page 3] Internet Draft DA Interaction September 30, 2000 Figure 4 shows DA advertisements which are multicast periodically. +----+ +-------+ | | | | | DA | ---- Multicast DAAdvert ---> | UA/SA | | | | | +----+ +-------+ Figure 4. DA Advertisement From Figure 1 to 4, we can see that SLPv2 does not define the message flows among DAs. We will define these flows in this document. 4. Definitions for Mesh Enhancement To facilitate the mesh-enhancement functionality, we define a new SLP message type: mesh control (MeshCtrl) and a new SLP extension: mesh-forwarding. They are used to specify the extended operations of mesh-enhanced DAs. 4.1 Mesh Control Message Mesh-enhanced DAs support the MeshCtrl message, whose Function-ID is 12. The format of this message is given in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = MeshCtrl = 12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action-ID | Action-Data \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. MeshCtrl Message Table 1 lists the five defined Action-IDs. The Action-Data can be empty. Its format is determined by its preceding Action-ID. Action-ID Abbreviation 1 Peer_Conn_Indication 2 Peer_DA_Indication 3 Data_Copy_Rqst 4 Data_Send_Done 5 Peer_Keepalive Table 1. Action-IDs in MeshCtrl Message Zhao, et al. Expires: March 30, 2001 [Page 4] Internet Draft DA Interaction September 30, 2000 Peer_Conn_Indication (peer connection indication): This Action-ID does not have an Action-Data part. It informs the receiving DA that the connection from which the message is received is a peering connection. Peer_DA_Indication (peer DAs indication): This Action-ID has an Action-Data part whose format is given in Figure 6. It carries a DA list in the form of URLs. This list includes those DAs in the sending DA's peer list that share some scopes with the receiving DA. Moreover, a DA's URL can be included in this list only when the sending DA has already had that DA's data for shared scopes, i.e., the sending DA has got synchronized with that DA. The receiving DA SHOULD peer with all DAs in this DA list. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of DA URLs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of DA URL #1 | DA URL #1 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ . . . \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of DA URL #N | DA URL #N \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. Action-Data for Peer_DA_Indication Data_Copy_Rqst (data copy request): This Action-ID has an Action-Data part whose format is given in Figure 7. It requests that the receiving DA send all the service registration data in the "Requested Scopes" to the requesting 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Requested Scopes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String of Requested Scopes \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Action-Data for Data_Copy_Rqst Data_Send_Done (data sending done): This Action-ID does not have an Action-Data part. It informs the receiving DA that all the data of requested scopes have been sent. Zhao, et al. Expires: March 30, 2001 [Page 5] Internet Draft DA Interaction September 30, 2000 Peer_Keepalive (peer keepalive): This Action-ID has an Action-Data part whose format is given in Figure 8. It indicates that the peering connection from which the message is received is alive and SHOULD not be closed. It also indicates the current stateless boot timestamp of the sending 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA Boot Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA Boot Timestamp, contd. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8. Action-Data for Peer_Keepalive 4.2 Mesh-forwarding Extension Mesh-enhanced DAs also support the mesh-forwarding extension, whose extension ID is 6. The format of this extension is illustrated in Figure 9. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mesh-forwarding Extension ID | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, contd. | Action-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Mesh-forwarding Extension Table 2 lists the two defined Action-IDs for the mesh-forwarding extension. Action-ID Abbreviation 0 No_Action 1 Mesh_Forward_Rqst Table 2. Action-IDs in Mesh-forwarding Extension No_Action (null operation): It is used by the sending DA to turn off the "Mesh_Forward_Rqst" Action-ID in a message. Mesh_Forward_Rqst (mesh forwarding request): It requests that the receiving DA forward the message to all DAs (both mesh-enhanced and non-mesh-enhanced) in the registration scope. Zhao, et al. Expires: March 30, 2001 [Page 6] Internet Draft DA Interaction September 30, 2000 5. Peer Relationship Peer DAs maintain a fully-meshed peer relationship, which uses a set of fully-meshed peering connections. A mesh-enhanced DA has a peer list. Each entry in this peer list includes the peer URL, a list of shared scopes, a boot timestamp for the peer to distinguish it from its rebooted instance, a reference to the peering connection, and a mesh flag indicating whether the peer is mesh-enhanced or not. A mesh-enhanced DA adds an entry to its peer list when it discovers a new peer, removes an entry from the peer list when it finds the corresponding peer is down, and updates an entry when it detects the corresponding peer has rebooted. A peer relationship has three stages: setting up, maintaining and tearing down. mSLP considers the situation where mesh-enhanced DAs, non-mesh-enhanced DAs, mesh-aware SAs and non-mesh-aware SAs coexist. It works even if multicast is NOT supported or a DA's multicast DAAdvert messages cannot reach all of its peer DAs. 5.1. Setting Up a Peer Relationship In SLP, each DA periodically sends DA Advertisement (DAAdvert) messages to the administratively scoped SLP multicast [3] address (239.255.255.253 is the default address in the IPv4 local scope). All DAs listen to this address. This enables a DA to discover other DAs. A DAAdvert message from a mesh-enhanced DA MUST carry the "mesh- enhanced" attribute keyword (Figure 10). +------------------+ +----------+ | | | | | Mesh-enhanced DA | ------- Multicast DAAdvert ------> | DA/UA/SA | | | [attr = mesh-enhanced] | | +------------------+ +----------+ Figure 10. Mesh-enhanced DA Advertisement 5.1.1 Initiating a Peer Relationship When a mesh-enhanced DA (such as DA1 in Figure 11) learns about a new peer (either mesh-enhanced or non-mesh-enhanced) by receiving a DAAdvert message from the peer (if it knows the peer through a configuration file or DHCP, it unicasts a SrvRqst message with service type "service:directory-agent" to the peer to solicit a DAAdvert), it creates a peering connection to the peer if such connection does not exist. The mesh-enhanced DA uses this peering connection to forward messages to the peer. The peer, if mesh- enhanced, also uses the connection to forward messages in the opposite direction. Therefore, a peering connection can be set up Zhao, et al. Expires: March 30, 2001 [Page 7] Internet Draft DA Interaction September 30, 2000 between two mesh-enhanced DAs or between a mesh-enhanced DA and a non-mesh-enhanced DA. In the latter case, messages are only forwarded from the mesh-enhanced DA to the non-mesh-enhanced DA. +-----+ +-----+ | | | | | DA1 | <------- Multicast DAAdvert --------- | DA2 | | | | | +-----+ +-----+ +-----+ Unicast SrvRqst +-----+ | | ----- (service:directory-agent) ----> | | | DA1 | | DA2 | | | <-------- Unicast DAAdvert ---------- | | +-----+ +-----+ Figure 11. Learning about New Peer For a non-mesh-enhanced peer, the mesh-enhanced DA just creates a peering connection with it and forwards messages to it. But for a mesh-enhanced peer, the peer relationship setup needs additional procedures described below. 5.1.2 Identifying a Peering Connection After a peering connection is established, the DA who initiates the connection (such as DA1 in Figure 12) sends the following two messages over the connection: a "Peer_Conn_Indication" MeshCtrl message marking the connection as the peering connection, and an unsolicited DAAdvert message enabling the peer to know it promptly (otherwise, the peer cannot know it until its next multicast DAAdvert). On the other hand, when a mesh-enhanced DA (such as DA2 in Figure 12) receives a "Peer_Conn_Indication" MeshCtrl message, it marks the TCP connection from which the message is received as the peering connection to the sending DA and uses it properly later. A mesh-enhanced DA SHOULD not create a new peering connection to a peer if there exists one already (initiated by the peer). Note that there is a small possibility that a pair of peering connections might be created between the two peer DAs if they try to set up a peering connection to each other almost at the same time. That is inefficient, but it does not affect the correctness of mSLP. +-----+ (1) "Peer_Conn_Indication" MeshCtrl +-----+ | | (2) Unsolicited DAAdvert | | | DA1 | ------------------ (TCP) ----------------> | DA2 | | | | | +-----+ +-----+ Figure 12. Peering Connection Indication and DAAdvert Zhao, et al. Expires: March 30, 2001 [Page 8] Internet Draft DA Interaction September 30, 2000 5.1.3 Exchanging Peer Information After sending the "Peer_Conn_Indication" MeshCtrl message and the unsolicited DAAdvert message, or receiving the above two messages, a mesh-enhanced DA sends a "Peer_DA_Indication" MeshCtrl message (Figure 13) to the peer. This message carries a DA list in the form of URLs. Algorithm 1 illustrates how to build this DA list which includes those DAs that are common peers between the sending DA and the receiving DA, and with whom the sending DA has got synchronized. +-----+ "Peer_DA_Indication" MeshCtrl +-----+ | | ------------------ (TCP) ----------------> | | | DA1 | | DA2 | | | <----------------- (TCP) ----------------- | | +-----+ "Peer_DA_Indication" MeshCtrl +-----+ Figure 13. Exchanging Peer Information Input: peer_url: the peer URL to which the message is sent peer_table: the peer table of this DA including all peer information Output: da_list: the DA list for the "Peer_DA_Indication" MeshCtrl Algorithm: build_da_list(peer_url, peer_table) { da_list = empty peer_scope = the scopes of "peer_url" for each "da" in "peer_table" { da_scope = the scopes of "da" shared_scope = common scopes between "peer_scope" and "da_scope" if ("da" <> "peer_url" && "shared_scope" <> empty && this DA has synchronized with "da") then add "da" to "da_list" } return da_list } Algorithm 1. Building DA list for "Peer_DA_Indication" MeshCtrl The exchange of "Peer_DA_Indication" MeshCtrl messages among peer DAs serves for two purposes. First, it enables a mesh-enhanced DA to learn about other DAs that share some scopes with it from its known peers. This is useful in case multicast is not supported or a DA's multicast DAAdvert messages cannot reach all of its peer DAs. Initial peer relationships can be configured by hand or through DHCP [4]. Zhao, et al. Expires: March 30, 2001 [Page 9] Internet Draft DA Interaction September 30, 2000 Second, a "Peer_DA_Indication" MeshCtrl message also informs the receiving DA that the sending DA has already had data for each DA in the DA list for their shared scopes. This enables the receiving DA to decide whether it needs to download data from the sending DA (more details are given later). 5.1.4 Handling New Peers Upon receiving a "Peer_DA_Indication" MeshCtrl message, a mesh- enhanced DA checks the DA list in the message. If any URL in the list is NOT in its peer list, it unicasts a SrvRqst message with service type "service:directory-agent" to the DA corresponding to the URL, to obtain a DAAdvert message from that DA. In Figure 13, if DA1 received the URL for DA3 from DA2 in the "Peer_DA_Indication" MeshCtrl message, and DA3 is NOT in DA1's peer list, DA1 MUST then acquire a DAAdvert message from DA3 (Figure 14). Upon receiving the DAAdvert message from DA3, DA1 can go through the whole process to set up a peer relationship with DA3. +-----+ Unicast SrvRqst +-----+ | | ----- (service:directory-agent) ----> | | | DA1 | | DA3 | | | <-------- Unicast DAAdvert ---------- | | +-----+ +-----+ Figure 14. Solicit DAAdvert from Peer 5.1.5 Data Synchronization Upon receiving the "Peer_DA_Indication" MeshCtrl message from a peer DA, the mesh-enhanced DA SHOULD decide whether it needs to download data from the peer. If it does, it sends a "Data_Copy_Rqst" MeshCtrl message with "requested scopes" (non-empty) to the peer (Figure 15). Algorithm 2 illustrates how to build the "requested scopes" which includes those scopes that this DA and the peer have in common but they do not have a common peer yet (if they have a common peer for a scope, they should have the same data for that scope already). +-----+ "Data_Copy_Rqst" MeshCtrl +-----+ | | ----------------- (TCP) ---------------> | | | DA1 | | DA2 | | | <---------------- (TCP) ---------------- | | +-----+ (1) SrvReg (data of requested scopes) +-----+ (2) "Data_Send_Done" MeshCtrl Figure 15. Getting Data from Peer Zhao, et al. Expires: March 30, 2001 [Page 10] Internet Draft DA Interaction September 30, 2000 Input: peer_url: the peer URL from which to get data da_list: the DA list in the peer's "Peer_DA_Indication" MeshCtrl peer_table: the peer table of this DA Output: rq_scopes: "requested scopes" for the "Data_Copy_Rqst" MeshCtrl Algorithm: build_rq_scopes(peer_url, da_list, peer_table) { rq_scopes = empty peer_scope = the scopes of "peer_url" my_scope = the scopes of this DA shared_scopes = common scopes between "my_scope" and "peer_scope" for each scope "s" in "shared_scopes" { my_peer = all peers that this DA has for scope "s" shared_peer = common peers between "my_peer" and "da_list" if "shared_peer" is empty, then add scope "s" to "rq_scopes" } return rq_scopes } Algorithm 2. Building "requested scopes" for "Data_Copy_Rqst" MeshCtrl When a mesh-enhanced DA receives a "Data_Copy_Rqst" MeshCtrl message, it sends the data of requested scopes to the requesting DA. Each data record is sent as a SrvReg message, with a re-calculated new lifetime computed as old lifetime minus elapsed time. Also, each SrvReg message SHOULD have a "mesh-forwarding" extension to request the receiving DA forward the message to its existing peers (more details are given in Section 6). When all the requested data have been transferred, a "Data_Send_Done" MeshCtrl message MUST be sent to the requesting DA to inform it that its "Data_Copy_Rqst" has been processed and it should have got all the requested data upon receiving this message. After exchanging data in both directions, peer DAs share the same consistent data for their common scopes. Note that a mesh-enhanced DA may not need to download data from all of its peers, or download data of all shared scopes from a peer. Each implementation can decide the criteria to select a DA (or DAs) from a peering DA set to download data, such as using the first one it found, choosing one randomly, using the nearest one or the least loaded one. For example, considering a peering DA set of three DAs: DA1 with scope "a,b", DA2 with scope "a,c" and DA3 with scope "b,c", DA4 with scope "a,b,c" joins this DA set (Figure 16). In order to get data for scope "a,b,c", DA4 can choose scope "a,b" from DA1 and scope "c" from DA2, or scope "b,c" from DA3 and scope "a" from DA2, or other suitable combinations. Zhao, et al. Expires: March 30, 2001 [Page 11] Internet Draft DA Interaction September 30, 2000 +-----------+ +-----------+ | DA1 (a,b) | ------------------------------------- | DA2 (a,c) | +-----------+ +-----------+ | | | | | | +-----------+ | | | +---------------- | DA3 (b,c) | ----------------+ | | +-----------+ | | | | | (a,b) +-------------+ (c) | +------------------> | DA4 (a,b,c) | <------------------+ +-------------+ Figure 16. An Example of Getting Data from a Peering Set 5.1.6 Comments To avoid race conditions in data synchronization among peer DAs, the following rules SHOULD be observed. First, a mesh-enhanced DA can include a DA's URL in its "Peer_DA_Indication" MeshCtrl message ONLY when it has got synchronized with that DA, which can be determined by receiving a "Data_Send_Done" MeshCtrl message from that DA or receiving a "Peer_DA_Indication" MeshCtrl message and deciding that it does not need to download any data from that DA. Second, a mesh- enhanced DA SHOULD synchronize data with one peer at a time. Third, if a "Data_Copy_Rqst" MeshCtrl message is needed to send to a peer, it SHOULD be sent after a "Peer_DA_Indication" MeshCtrl message has been sent to that peer. 5.2. Maintaining a Peer Relationship To maintain a peer relationship, a mesh-enhanced DA SHOULD send a "Peer_Keepalive" MeshCtrl message over the peering connection (Figure 17) every CONFIG_DA_KEEPALIVE seconds (see Section 8). This message serves for three purposes. First, it carries the current stateless boot timestamp of the sending DA. This enables the receiving DA to know whether the sending DA has rebooted or not and take corresponding actions if needed. Second, it keeps a peering connection alive. In SLPv2, idle connections could be closed by DAs after CONFIG_CLOSE_CONN seconds [1]. The closing a peering connection terminates the peer relationship and setting up a peer relationship has overhead, so it is more efficient to keep a peering connection alive between two peer DAs than to establish it on demand. Third, it helps peer DAs to stay synchronized with each other. If no message has been received from a peering connection for too long, there may be a network partition and the two peer DAs may have inconsistent data for shared scopes. In that case, they should tear down the existing peer relationship and set up a new one which enables them to exchange data and get synchronized. Zhao, et al. Expires: March 30, 2001 [Page 12] Internet Draft DA Interaction September 30, 2000 +-----+ +-----+ | | | | | DA1 | ---------------- (TCP) ----------------> | DA2 | | | "Peer_Keepalive" MeshCtrl | | +-----+ +-----+ Figure 17. Peer Keepalive 5.3. 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 it has not received the any message from the peer for more than CONFIG_DA_KEEPALIVE seconds. To tear down a peer relationship, a mesh-enhanced DA removes the peer from its peer list and closes the peering connection. 6. Message Forwarding Control Two types of messages are forwarded by mesh-enhanced DAs: SrvReg/SrvDeReg messages with "mesh-forwarding" extension and DAAdvert messages from non-mesh-enhanced peers. The message forwarding rules are as follows: 6.1. Forwarding SrvReg/SrvDeReg Messages (1) Explicit Forwarding: A mesh-enhanced DA forwards a SrvReg/SrvDeReg message when the message has a mesh-forwarding extension and the Action-ID is "Mesh_Forward_Rqst". A mesh-aware SA needs to use this extension to explicitly specify its mesh-forwarding request for messages that are intended to be forwarded by a mesh- enhanced DA. This explicit forwarding rule avoids unnecessary forwarding and it is fully compatible with SLPv2, where SAs need to register with all existing DAs. In the peer relationship setting up stage, a mesh-enhanced DA needs to send data of "requested scopes" to a peer if it receives a "Data_Copy_Rqst" MeshCtrl message from the peer. The requested data are sent as SrvReg messages, which need to have this mesh-forwarding extension to explicitly request the receiving DA forward the messages to all of its existing peers. (2) One-hop Forwarding: A SrvReg/SrvDeReg message is forwarded only once by a mesh-enhanced DA to all of its peers (both mesh-enhanced and non-mesh-enhanced, not including the source DA if the message is received from a peering connection) in the registration scope. Since the peering DA set is in a fully connected mesh, this one-hop forwarding rule ensures that a message can reach all peer DAs. Figure Zhao, et al. Expires: March 30, 2001 [Page 13] Internet Draft DA Interaction September 30, 2000 18 shows how a SrvReg/SrvDeReg message is forwarded. Before forwarding a message, a mesh-enhanced DA sets the Action-ID in the mesh-forwarding extension to "No_Action". That way, a forwarded message will never be forwarded again. +----+ "Mesh_Forward_Rqst" +-----+ "No_Action" +-----+ | | -- SrvReg/SrvDeReg -> | | --- SrvReg/SrvDeReg --> | | | SA | | DA1 | | DA2 | | | <------ SrvAck ------ | | <------- SrvAck ------- | | +----+ +-----+ +-----+ Figure 18. Forwarding SrvReg/SrvDeReg (3) Handling SrvAck: As a DA always replies with a SrvAck message when it receives a SrvReg/SrvDeReg message, a mesh-enhanced DA SHOULD handle SrvAck messages from other DAs. In Figure 18, DA1 returns a SrvAck message to SA upon receiving and processing a SrvReg/SrvDeReg message. As DA1 also forwards the message to DA2, it SHOULD properly handle the SrvAck message from DA2. 6.2. Forwarding DAAdvert Messages First, a DAAdvert message is forwarded only when it comes from a new or rebooted non-mesh-enhanced peer. Second, a mesh-enhanced DA forwards a DAAdvert message to all of its mesh-enhanced peers that share some scopes with the advertised DA. Third, a forwarded DAAdvert message SHOULD not be forwarded again. It can be identified easily since the sending DA and the advertised DA are different for a forwarded DAAdvert message. Forwarding the DAAdvert message from a new or rebooted non-mesh- enhanced peer can ensure that the DA is known to all of its mesh- enhanced peers even if multicast is not supported or its multicast DAAdvert messages cannot reach all of its mesh-enhanced peers. With the peering procedure described in Section 5.1 and the forwarding rules given in this section, a DA, whether mesh-enhanced or not, known to one mesh-enhanced peer can be known to all of its mesh- enhanced peers. Thus, a mesh-enhanced DA can know all of its peers and forward service registration information to them properly. 7. Design Discussion In this section, we discuss several important design issues. 7.1 Fully-meshed Peering Connections The fully-meshed peering DA architecture is built on top of a set of fully-meshed peering connections. Any message received by a DA only Zhao, et al. Expires: March 30, 2001 [Page 14] Internet Draft DA Interaction September 30, 2000 needs one-hop forwarding to reach all other DAs in the peering DA set. We anticipate that two to four DAs are sufficient to achieve very high reliability; larger peer sets significantly increase maintenance overhead. There is no need to have a separate DA for each scope. A DA can serve multiple scopes, and a single peering connection is used across all shared scopes between each pair of peer DAs. 7.2 Reliability The fully-meshed peering DA architecture 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 registration data from its peering DA set. This is done through DA coordination, without involving SAs. 7.3 Simplifying SA Registrations and Improving Scalability SLPv2 requires that SAs register with all existing DAs in their 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. With mSLP, a mesh-aware SA only needs to register with one mesh-enhanced DA in the registration scope; the registration information will then be propagated automatically within the meshed DA set. The overall SLP system scalability can be improved by using mesh-enhanced DAs and simplified SAs. 7.4 Compatibility mSLP is backward compatible with SLPv2. It defines a new attribute, a new SLP message type and a new SLP extension. The new attribute called "mesh-enhanced" is used in DAAdvert messages to identify mesh-enhanced DAs. The new SLP extension called "mesh-forwarding" is used by SrvReg and SrvDeReg messages to specify the mesh-forwarding request. The new SLP message type called MeshCtrl is used by mesh- enhanced DAs to interact with each other. A mesh-enhanced DA supports these extended operations without affecting its original functions. Moreover, the changes at mesh-enhanced DAs are mostly transparent to UAs and SAs. UAs can be kept unchanged. SAs can simplify their service registrations by using mesh-forwarding. mSLP supports incremental deployment of mesh-enhanced DAs, e.g., they can be deployed one scope at a time. However, since a mesh-aware SA still needs to take care of newly found and rebooted non-mesh- enhanced DAs as these DAs cannot get existing data from other DAs, uniform deployment of mesh-enhanced DAs is much more desirable than partial deployment. Zhao, et al. Expires: March 30, 2001 [Page 15] Internet Draft DA Interaction September 30, 2000 7.5 Summary Below, we summarize the operations for UAs, mesh-aware SAs, non- mesh-aware SAs, mesh-enhanced DAs and non-mesh-enhanced DAs. 7.5.1 UA A UA 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 scope. 7.5.2 Non-mesh-aware SA A non-mesh-aware SA needs to discover all DAs in its scope and register with all of them. It does NOT use the mesh-forwarding extension. 7.5.3 Mesh-aware SA A mesh-aware SA can identify mesh-enhanced DAs from the "mesh- enhanced" attribute in their DAAdvert messages. It only needs to discover one mesh-enhanced DA and register with it using the mesh- forwarding extension with the Action-ID set to "Mesh_Forward_Rqst". If there are no mesh-enhanced DAs in its scope, it operates in the same way as a non-mesh-aware SA [1]. 7.5.4 Non-mesh-enhanced DA A non-mesh-enhanced DA accepts SrvReg/SrvDeReg messages from SAs and mesh-enhanced DAs normally. It does NOT forward them. 7.5.5 Mesh-enhanced DA (1) A mesh-enhanced DA MUST carry the "mesh-enhanced" attribute keyword in its DAAdvert messages (Section 2). (2) A mesh-enhanced DA MUST keep a list of peer DAs (mesh-enhanced and non-mesh-enhanced) and maintain a peering connection to each of them. For each mesh-enhanced peer, a "Peer_Conn_Indication" MeshCtrl message SHOULD be sent OR processed, a "Peer_DA_Indication" MeshCtrl message SHOULD be sent AND processed, a "Data_Copy_Rqst" MeshCtrl message MAY be sent, and a "Data_Send_Done" MeshCtrl message MUST be sent if a "Data_Copy_Rqst" MeshCtrl message is received (Section 5). (3) A mesh-enhanced DA accepts SrvReg/SrvDeReg messages from SAs and mesh-enhanced DAs. It MUST forward the "Mesh_Forward_Rqst" SrvReg/SrvDeReg messages to all of its peers (both mesh-enhanced and non-mesh-enhanced) in the registration scope and process SrvAck Zhao, et al. Expires: March 30, 2001 [Page 16] Internet Draft DA Interaction September 30, 2000 messages from mesh-enhanced DAs (Section 6.1). (4) Upon receiving a DAAdvert message from a new or rebooted non- mesh-enhanced peer, a mesh-enhanced DA MUST forward the message to all of its mesh-enhanced peers that share some scopes with the advertised DA (Section 6.2). 8. Constants Mesh Control (MeshCtrl) Message Type 12 (Section 4) Mesh-forwarding Extension ID 6 (Section 4) CONFIG_DA_KEEPALIVE 290 seconds (Section 5.2) Note: CONFIG_DA_KEEPALIVE < CONFIG_CLOSE_CONN, which has a default value of 300 seconds [1]. 9. Security Considerations 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. mSLP uses standard SLPv2 authentication. 10. References [1] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999. [2] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, July 1998. [4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Zhao, et al. Expires: March 30, 2001 [Page 17] Internet Draft DA Interaction September 30, 2000 11. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Email: Erik.Guttman@sun.com 12. Full Copyright Statement Copyright (C) The Internet Society (2000). 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: March 30, 2001 [Page 18]