INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-03.txt Columbia University Expires: November 5, 2000 May 5, 2000 Interaction of SLP Directory Agents for Reliability and Scalability draft-zhao-slp-da-interaction-03.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 presents a scheme for the interaction of Directory Agents (DAs) in SLPv2 (Service Location Protocol, Version 2). It proposes to use a fully meshed peering DA architecture. Peer DAs exchange service registration information, and maintain the same consistent data for the shared scopes. This scheme provides a reliable directory service for an SLP system. It also greatly simplifies SLP service registration leading to a thin-client Service Agent (SA) implementation. It is backward compatible with SLPv2, and incremental deployment is supported. 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 W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 1]
Internet Draft DA Interaction May 5, 2000 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 a scheme for the interaction of SLP DAs to provide a reliable directory service. We propose 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 the 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 the shared scopes. This scheme also greatly simplifies SLP service registration leading to a thin- client Service Agent (SA) implementation. Therefore, the scalability of an SLP system can also be enhanced. It is entirely backward compatible with SLPv2, and incremental deployment is supported. The remainder of this document is organized as follows: Section 2 defines the terminology. Section 3 reviews the current DA message flows in SLPv2. In Section 4, we describe the DA peer relationship. In Section 5, we present the message forwarding control among DAs. We discuss our design in Section 6, and give security considerations in Section 7. 2. Terminology Peer DAs If two DAs have one or more scopes in common within one administrative domain, they are peers. Peer DAs coordinate with each other and store the same consistent data for the shared scopes. Peering TCP connection A persistent TCP connection that is kept between 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. Its closing can be an indication of the termination of the peer relationship. Mesh-enhanced DA A DA who maintains a peering TCP connection to each of its peers and forwards service registration information to its peers according to the rules given in this document. A mesh-enhanced DA MUST carry the "mesh- enhanced" attribute in its DAAdvert messages. W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 2]
Internet Draft DA Interaction May 5, 2000 Mesh-aware SA An SA who understands the "mesh-enhanced" attribute in a DAAdvert message and uses the mesh-enhanced DA capability accordingly. 3. DA Message Flows in SLPv2 This section reviews the current DA message flows 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 Figure 4 shows DA advertisements which are multicast periodically. W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 3]
Internet Draft DA Interaction May 5, 2000 +----+ +-------+ | | | | | 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 for the interaction of DAs and refine above flows in the following sections. 4. Peer Relationship We use a set of fully meshed TCP connections among peer DAs. A peer relationship has three stages: setting up, keeping and tearing down. We describe each stage in detail next. 4.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). All DAs listen to this address. Figure 5 illustrates the DAAdvert messages from mesh-enhanced DAs. +-----+ +-----------+ | | | | | DA1 | ------- Multicast DAAdvert ------> | DA2/UA/SA | | | [attr = mesh-enhanced] | | +-----+ +-----------+ Figure 5. Mesh-enhanced DA Advertisement A mesh-enhanced DA MUST maintain 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 peer list SHOULD include peer URL, shared scopes, boot timestamp, and peering TCP connection ID. The boot timestamp is to identify a rebooted peer. The peering TCP connection is used for message forwarding. When a mesh-enhanced DA learns about a new peer, it MUST create a peering TCP connection to the peer at the SLP reserved port 427 if such connection does not yet exist. Then it sends a DAAdvert message with the "peering-connection-indication" attribute through this channel to notify the peer that this is a peering TCP connection (Figure 6). Thus, the peer can also use this channel to forward messages in opposite direction. W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 4]
Internet Draft DA Interaction May 5, 2000 +-----+ +-----+ | | [attr = peering-connection-indication] | | | DA1 | <------------ DAAdvert (TCP) ------------- | DA2 | | | | | +-----+ +-----+ Figure 6. Peering Connection Indication After the peering TCP connection is established or identified, peer DAs begin to forward new service registration information to each other via this channel. At the same time, a mesh-enhanced DA SHOULD decide whether it needs to get the data from its new peers. For example, when a newly booted DA joins a peering DA set of three DAs, it needs to get a copy of the existing registration data from one of the three DAs, but not from all of them, which incurs a lot of redundant transmissions. To do this, it sends a DAAdvert message with the "data-copy-request" attribute to the chosen peer (Figure 7). On the other end, when a mesh-enhanced DA receives the "data-copy- request" in a DAAdvert message, it dumps all the data of the shared scopes to the requesting DA. Each data record is sent as a SrvReg message, with a re-calculated new lifetime (= old lifetime - elapsed time). After exchanging their data in both directions, peer DAs have the same consistent data for the shared scopes. +-----+ [attr = data-copy-request] +-----+ | | --------- DAAdvert (TCP) --------> | | | DA1 | | DA2 | | | <--------- SrvReg (TCP) ---------- | | +-----+ (data of shared scopes) +-----+ Figure 7. Dumping Data 4.2. Keeping a Peer Relationship In 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 mesh-enhanced DA SHOULD send a DAAdvert message with the "keepalive" attribute via the channel every CONFIG_DA_KEEPALIVE (< CONFIG_CLOSE_CONN) seconds (Figure 8). +-----+ +-----+ | | | | | DA1 | ------------ DAAdvert (TCP) ------------> | DA2 | | | [attr = keepalive] | | +-----+ +-----+ Figure 8. DA Keepalive W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 5]
Internet Draft DA Interaction May 5, 2000 4.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 TCP 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 keepalive DAAdvert message from the peer for more than CONFIG_DA_KEEPALIVE seconds. In the last case, there may be a network partition and peer DA states get inconsistent. To tear down a peer relationship, a DA stops forwarding any service registration information to this peer, closes TCP connection with this peer, and removes this peer from its peer list. 5. Message Forwarding Control During the peering period, peer DAs forward new service registration information from SAs to each other. We define a new SLP extension - "mesh-forwarding extension" for the message forwarding purpose. This extension is always six bytes long: five-byte extension header and one-byte extension data denoted as "Action" field. The "Action" field is used to specify forwarding actions: TO_BE_FORWARDED marks the message needs to be forwarded; HAS_BEEN_FORWARDED means the message has already been forwarded, and there is no need to be forwarded again. Figure 9 illustrates its format. The message forwarding rules are as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Mesh-Forwarding Extension (1) Explicit Forwarding: A message is forwarded only when it explicitely requests to be forwarded. A mesh-aware SA needs to attach the mesh-forwarding extension to a Srv(De)Reg message and set the "Action" field to TO_BE_FORWARDED if it wants the message to be forwarded by a mesh-enhanced DA. This is for the compatibility with SLPv2, where SAs need to register with all existing DAs. To avoid unnecessary forwarding, the explicit forwarding rule is used. (2) One-hop Forwarding: A Srv(De)Reg message is forwarded only once by a mesh-enhanced DA to all its peers in the registration scope. W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 6]
Internet Draft DA Interaction May 5, 2000 Before forwarding a message, a mesh-enhanced DA sets the "Action" field in the mesh-forwarding extension to HAS_BEEN_FORWARDED. In this way, a forwarded message will never be forwarded again. Since the peering DA set is in a fully connected mesh, one-hop forwarding is enough to ensure that a message can reach all peer DAs. Figure 10 shows how a Srv(De)Reg message is forwarded. +----+ (TO_BE_FORWARDED) +-----+ (HAS_BEEN_FORWARDED) +-----+ | | -- SrvReg/SrvDeReg -> | | -- SrvReg/SrvDeReg -> | | | SA | | DA1 | | DA2 | | | <------ SrvAck ------ | | <------ SrvAck ------ | | +----+ +-----+ +-----+ Figure 10. Forwarding Registration (3) Handling SrvAck: A DA always replies with a SrvAck message when it receives a Srv(De)Reg message. So a mesh-enhanced DA SHOULD process SrvAck messages from other DAs. 6. Design Discussion In this section, we discuss several important design issues, i.e., identifying forwarded messages, simplifying SA registrations, and forwarding UA queries. We also give comments on reliability, scalability, compatibility, and deployment for our design. 6.1 Identifying Forwarded Messages Since a forwarded message has the mesh-forwarding extension and its "Action" field is HAS_BEEN_FORWARDED, it can be easily identified. A forwarded Srv(De)Reg message SHOULD not be forwarded again. 6.2 Simplifying SA Registrations A mesh-aware SA only needs to register with one mesh-enhanced DA in the registration scope. The information will be propagated automatically within the peering DA set. Thus, a mesh-aware SA does not need to implement the complicated algorithm to register with all existing DAs and to re-register when new mesh-enhanced DAs are discovered, or old mesh-enhanced DAs are found to have rebooted. 6.3 Forwarding UA Queries A further extension to the interaction of SLP DAs is to forward UA queries besides SA registrations. It works as follows: When a mesh- enhanced DA receives a UA query which is not in its scope, it forwards the query to another DA which supports the scope. This can simplify UA implementation since UAs do not need to keep track of DA W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 7]
Internet Draft DA Interaction May 5, 2000 scopes. A UA can send its queries to any mesh-enhanced DA. However, this adds much complexity to the mesh-enhanced DA implementation. First, a mesh-enhanced DA needs to keep track of all DAs of all scopes, not only the DAs that share some scopes with it. Second, a mesh-enhanced DA needs to forward the query to another DA, and it also needs to forward the reply from another DA back to the UA. We did not include this extension in our scheme mainly due to its complexity. However, for a thin-client UA implementation, it might deserve further considerations. 6.4 Reliability The fully meshed peering DA architecture provides maximum robustness. It ensures that no single failure point exists in the SLP directory service. All service registrations are kept by at least two DAs. If one DA is down, at least one other peer DA can continue to provide the service information for the scope. Moreover, the peering DA architecture ensures the data consistency among peer DAs automatically. It also enables a DA to recover from crash with much less effort since a rebooted DA can get the existing data from its peering DA set. This is done through DA coordination, no SA involvement is needed. 6.5 Scalability With mesh-enhanced DAs and simplified SAs, the overall SLP system scalability can be enhanced. However, since we use a set of fully meshed TCP connections among peer DAs, 2-4 is the recommended number of DAs for each scope. There is no 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. 6.6 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. SAs can be simplified as described in Section 6.2. 6.7 Deployment Our design supports incremental deployment of mesh-enhanced DAs. A mesh-enhanced DA can set up peer relationships with both mesh- enhanced DAs and non-mesh-enhanced DAs. In the latter case, the message forwarding only goes in uni-direction from the mesh-enhanced DA to a non-mesh-enhanced DA. As we indicate in Section 6.2, a mesh-aware SA only needs to register with one mesh-enhanced DA by W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 8]
Internet Draft DA Interaction May 5, 2000 using the mesh-forwarding extension. However, a mesh-aware SA SHOULD take care of newly found non-mesh-enhanced DAs and rebooted non- mesh-enhanced DAs since these non-mesh-enhanced DAs can not get the existing data from other DAs. Therefore, uniformly mesh-enhanced DAs can provide a much easier job for mesh-aware SAs. 7 Security Considerations The DA authentication is more important in this scheme, since SAs will have to trust the DA they are sending the Srv(De)Reg messages to forward them. DAs can use standard SLPv2 DA authentication to authenticate other DAs in the mesh. 8. 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 9. Acknowledgments Erik Guttman provided valuable comments and suggestions for this draft. 10. Authors' Addresses Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 email: zwb@cs.columbia.edu Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 email: hgs@cs.columbia.edu W. Zhao, H. Schulzrinne Expires: November 5, 2000 [Page 9]