INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-00.txt Columbia University Expires: May 15, 2000 November 15, 1999 Interaction of SLP Directory Agents for Reliability and Scalability draft-zhao-slp-da-interaction-00.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. Abstract This document proposes a scheme for the interaction of Directory Agents (DA) in SLPv2 (Service Location Protocol, Version 2). It aims to provide a reliable and scalable directory service by maintaining a peer relationship among a fully meshed DA set. Peer DAs exchange SLP update messages (SrvReg and SrvDeReg), and keep the same consistent data for each scope. This scheme is entirely backward compatible with SLPv2. It simplifies Service Agent (SA) registrations and supports User Agent (UA) query load balancing. 1. Introduction In the Service Location Protocol (RFC 2068 [1]), Directory Agents (DA) are introduced for caching service advertisements from Service Agents (SA), and answering queries from User Agents (UA). They exist to enhance the performance and scalability of SLP. W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 1]
Internet Draft DA Interaction November 15, 1999 When multiple DAs present, how should they interact with each other? This is an open issue in SLPv2. With the goals of reliability, scalability and compatibility with SLPv2, we propose that DAs within one administrative domain maintain a fully meshed peer relationship similar to IBGP [3]. Peer DAs exchange their data for the shared scopes when they set up a peer relationship, and continue to exchange new SLP update messages (SrvReg and SrvDeReg) during the entire peering period. In Section 2, we define the peer relationship for DAs, and describe the steps for setting up, keeping and tearing down it. A persistent TCP connection is used for this purpose between each pair of peers. In Section 3, we present a simple data forwarding scheme among DAs by using the REQUEST MCAST (R) bit in the flag field of the SLPv2 message header. In Section 4, we analyze our design for its reliability, scalability and compatibility. We give recommendations for implementation and deployment in Section 5. We outline and compare other alternative designs in Section 6. Finally, we give security considerations in Section 7. 2. Peer Relationship We define the SLP DA peer relationship as follows: If two DAs have one or more scopes in common within one administrative domain, they are peers. Peer DAs store the same consistent data for the shared scopes. We use a set of fully meshed TCP connections among peer DAs. These peering TCP connections are introduced for two reasons: (1) They provide a reliable communication channel for each pair of peer DAs to exchange messages. Therefore, a DA implementation is not burdened by managing message retransmissions. (2) A peering TCP connection is kept for the entire peering period (persistent). The closing of it can be an indication of the peer being down. We call a DA is mesh-enhanced if it is in a mirrored DA set for each of its scopes and maintains a persistent TCP connection to each of its peers. A mesh-enhanced DA SHOULD add a "mesh-enhanced" keyword to the attribute list in its DAAdvert messages. A peer relationship includes three stages: setting up, keeping and tearing down. We discuss each stage in detail next. 2.1. Setting Up a Peer Relationship W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 2]
Internet Draft DA Interaction November 15, 1999 In SLP, each DA periodically sends DA Advertisement messages (DAAdvert) to the Administratively Scoped SLP Multicast [2] address 239.255.255.253. All DAs listen to this address. When a DA receives a DAAdvert message from another DA, it checks the <scope list> field in the message. If it shares some scopes with the sender DA, they are peers. A DA treats a new peer and an old peer differently. (1) For a new peer, a DA needs to forward all its data for the shared scopes to the peer. (2) For an old peer, A DA only needs to forward the new SrvReg and SrvDeReg messages to the peer. Each DA maintains a peer list. It adds an entry to the list whenever it discovers a new peer, and removes an entry when it finds the corresponding peer is down. Each entry in this list includes peer URL, boot timestamp, shared scopes, and peering TCP connection id. A rebooted peer is treated as a new peer. If its URL is already in the peer list, it should carry a boot timestamp that differs from its previous one, so the DA needs to update its boot timestamp and close the previous TCP connection to it. When a DA learns about a new peer from a multicast DAAdvert message, it replies with a unicast DAAdvert message to the sender DA immediately. In this way, the first DA may know the second DA quickly, and synchronize accordingly. The first DA may not need to wait for the next multicast DAAdvert message from the second DA which may delay a long period. For a new peer, the DA creates a TCP connection to the peer at the SLP reserved port 427, and sends a copy of its data belonging to the shared scopes to the peer. Each data record is transferred as a SrvReg message, with a re-calculated new lifetime: new lifetime = old lifetime - elapsed time. For each SrvReg message, the DA sets the (R) flag bit in the message header. The reason for doing this is given in Section 3. After they exchange their data in both directions, these two peers have the same consistent data for the shared scopes. 2.2. Keeping a Peer Relationship According to SLPv2, a DA could close an idle TCP connection after CONFIG_CLOSE_CONN seconds (5 minutes at least). To keep a peering TCP connection alive, a DA sends a SrvReg message for itself every W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 3]
Internet Draft DA Interaction November 15, 1999 CONFIG_CLOSE_CONN - 10 seconds. We propose to define a new service type called service:da. Under this service type, each DA sends its own SrvReg message (the (R) flag bit in the message header needs to be set, see Section 3 for details) to all its peers as well as put this information to its own database. As an additional benefit of this, a UA can get a URL list of all DAs by a SrvRqst message with service:da as service type. To maintain a consistent data among the mirrored DA set for a scope, a DA should forward each SLP update message (SrvReg or SrvDeReg) it received from an SA to each of its peers in the registration scope. For each forwarded message, the DA sets the (R) flag bit in the message header. More details are given in Section 3. 2.3. Tearing Down a Peer Relationship A DA should tear down a peer relationship when it receives an EOF from this peer along the peering TCP connection, or when it gets an exception while it tries to forward messages to this peer. To tear down a peer relationship, a DA stops forwarding any SLP update messages to this peer, closes TCP connection with this peer, and removes this peer from its peer list. 3. Message Forwarding When a DA receives an SLP update message (SrvReg or SrvDeReg) from an SA, it forwards the message to all its peers, and replies with a SrvAck message to the SA. However, when a DA receives a forwarded message, it neither forwards nor replies the message. There is no need to reply since the message is forwarded via TCP, a reliable communication channel. The forwarded message does not need to be further forwarded because the mirrored DAs are in a fully connected mesh. To decide that an SLP update message (SrvReg or SrvDeReg) is forwarded or not, a DA works as follows: (1) The sending DA sets the REQUEST MCAST (R) flag bit in the message head when it forwards an SLP update message to a peer. (2) The receiving DA checks the (R) flag bit in the message header whenever it receives an SLP update message. If this bit is set, the message is forwarded from a peer DA, otherwise it is from an SA. W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 4]
Internet Draft DA Interaction November 15, 1999 Since in SLPv2, a SrvReg or SrvDeReg message is always unicasted from an SA to a DA, the (R) flag bit in the message head is never used. So a DA can use this bit for the message forwarding purpose. This bit is only manipulated by DAs. SAs and UAs do not need to know about it. However, an SA can intentionally set this bit to prevent message forwarding among DAs if it wants to register to each DA separately. Only SrvReg and SrvDeReg messages from SAs are forwarded by DAs. The query messages from UAs are NOT forwarded. Figure 1 summarizes the message exchanging and forwarding: +----+ SrvDeReg +-----+ | | --- Unicast SrvReg --> | | SrvDeReg +-----+ | SA | | DA1 | -- Forward SrvReg --> | DA2 | | | <-- Unicast SrvAck --- | | +-----+ +----+ +-----+ | SrvDeReg +-----+ +------ Forward SrvReg --> | DA3 | +-----+ +----+ +----+ | | --- Unicast SrvRqst/SrvTypeRqst/AttrRqst --> | | | UA | | DA | | | <-- Unicast SrvRply/SrvTypeRply/AttrRply --- | | +----+ +----+ Figure 1. Message Exchanging and Forwarding 4. Analysis In this section, we demonstrate how our design can achieve reliability, scalability, and compatibility with SLPv2. 4.1 Reliability We propose that in each administration domain, at least two DAs should be present for each scope to store the same consistent data of SA advertisements. This is mainly for reliability, i.e., when one DA is down, at least one other DA can continue to provide directory service for the scope. 4.2 Scalability The mesh-enhanced DAs also simplify SA registrations and support UA load balancing, and thus improve the system performance and scalability. (1) An SA only needs to register its advertisements with one mesh- W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 5]
Internet Draft DA Interaction November 15, 1999 enhanced DA in the registration scope. The information will be propagated automatically within the mirrored DA set. An SA does not need to implement the complicated algorithm for registrations with all existing DAs and re-registrations when new DAs are discovered, or old DAs are found to have rebooted. (2) A UA can get the same query results from any DA in the query scope. When there are a lot of UAs in the system, multiple mesh-enhanced DAs support query load balancing for UAs. Since we use fully meshed TCP connections among DAs, 2-3 DAs is the recommended value for each scope. As an example, 3 TCP connections are needed for a mirrored set of 3 DAs. This should not be a problem. You do not need to have separate DA for each scope. A DA can serve multiple scopes. And a peering TCP connection is used for all shared scopes between each pair of peer DAs. 4.3 Compatibility The scheme is fully backward compatible with SLPv2, It does not introduce any new protocol elements. Only DAs are modified with the mesh-enhanced function, and the changes are almost transparent to UAs and SAs. UAs can be kept unchanged, or can be enhanced with load balancing function as to which DA to query. SAs can be simplified as described in Section 4.2. 5. Implementation and Deployment A mesh-enhanced DA needs to implement the following functions: (1) The functions to set up, keep, and tear down a peer relationship with a peer DA. It needs to maintain a peer list for each scope the DA supports. (2) The mechanism to distinguish the forwarded messages from the messages from SAs, and forward messages whenever needed. (3) Adding "mesh-enhanced" keyword to the attribute list in DAAdvert message to indicate the mesh-enhanced capability. An SA SHOULD understand the "mesh-enhanced" attribute keyword in the DAAdvert message, and ONLY register with one mesh-enhanced DA in the registration scope. A UA MAY understand the "mesh-enhanced" attribute keyword in the DAAdvert message. It can get a URL list of all DAs by sending a W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 6]
Internet Draft DA Interaction November 15, 1999 SrvRqst message with service:da as service type, and use this information to select a desired DA from the list. For the deployment of mesh-enhanced DAs, we recommend that either ALL or NONE DAs should be mesh-enhanced for a scope within one administrative domain. Uniformly mesh-enhanced DAs provide a much easy job for SAs and UAs. 6. Alternative Designs We outline two alternative designs for the interaction of DAs here, and discuss why we did not adopt them. 6.1 Inference-Message Forwarding Intuitively, it seems we may not need a flag bit in the SLPv2 message header for the message forwarding purpose since a DA can infer that an SLP update message source is an SA or a DA. The inference works like this: each time a DA receives an SLP update message, it checks the source address of the message. If the source address is in its peer list, the message is from a DA, otherwise, the message is from an SA. There are two problems with this design: (1) If an SA and a DA are in the same host, the source-address-based distinction fails. (2) It might cause unnecessary copying if the DA sending the forwarded message is not known to the DA receiving the message. For example: DA1 receives a SrvReg message from an SA and forwards it to DA2. DA2 does not know about DA1, so it forwards the message to all the DAs in its peer list. This leads to duplication since these DAs have already received the same forwarded message from DA1. Comparison: The unnecessary copying does not happen in our scheme using a forwarding flag bit, i.e., REQUEST MCAST (R) bit in SLPv2 message header. A DA only forwards a message when the forwarding flag bit in the message header is not set, and the DA set this bit before forwarding the message. 6.2 Forwarding UA Queries A further extension for the interaction of SLP DAs is to forward UA queries as well as SA registrations. It works as follows: When a DA receives a UA query which is not in its scope, it forwards the query to another (appropriate) DA which supports the scope. W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 7]
Internet Draft DA Interaction November 15, 1999 This scheme can simplify UA implementation since UAs do not need to keep track of DA scopes. A UA can send its queries to any mesh- enhanced DA. But it adds much complexity to DA implementation: (1) A mesh-enhanced DA needs to keep track of all DAs of all scopes, not only the DAs share some scopes with it. (2) A mesh-enhanced DA not only needs to forward the query to another DA, but also needs to forward the reply from another DA back to the UA. Remarks: We did not adopt this extension due to its complexity. However, if we want to have a thin-client implementation for UA, it might deserve further consideration. 7. Security Considerations We emphasis that it needs authentication for DAs to set up peer relationship. SLPv2 already provides mechanism for doing this through <SLP SPI List> and authentication blocks in the DAAdvert message. 8. References [1] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999. [2] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, July 1998 [3] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995 9. Acknowledgments Erik Guttman provided valuable comments and suggestions for this draft. Jonathan Lennox helped with the presentation. 10. Authors' Addresses Weibin Zhao Columbia University Department of Computer Science 1214 Amsterdam Ave. New York, NY 10027-7003 email: zwb@cs.columbia.edu Henning Schulzrinne Columbia University W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 8]
Internet Draft DA Interaction November 15, 1999 Department of Computer Science 1214 Amsterdam Ave. New York, NY 10027-7003 email: hgs@cs.columbia.edu W. Zhao, H. Schulzrinne Expires: May 15, 2000 [Page 9]