INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-02.txt Columbia University Expires: October 10, 2000 April 10, 2000 Interaction of SLP Directory Agents for Reliability and Scalability draft-zhao-slp-da-interaction-02.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 service (de)registration messages, and keep the same consistent data for each scope. This scheme can simplify Service Agent (SA) registrations, and it is entirely backward compatible with SLPv2. 1. Introduction In the Service Location Protocol (RFC 2608 [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: October 10, 2000 [Page 1] Internet Draft DA Interaction April 10, 2000 When multiple DAs present, how should they interact with each other? This is an open issue in SLPv2. To enhance the reliability and scalability of SLP DAs while keeping compatible with SLPv2, we propose that DAs within one administrative domain 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 (de)registration (Srv(De)Reg) messages during the entire peering period. 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 our message forwarding rules among DAs. We discuss our design in Section 6. And finally, we 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 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. The closing of it 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 Srv(De)Reg messages to its peers according to the rules given in this document. A mesh- enhanced DA MUST carry a "mesh-enhanced" attribute in its DAAdvert messages. 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 (de)registration (Srv(De)Reg) message, a DA replies with a service acknowledge (SrvAck) message. W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 2] Internet Draft DA Interaction April 10, 2000 +----+ +----+ | | --- SrvReg/SrvDeReg --> | | | SA | | DA | | | <------- SrvAck ------- | | +----+ +----+ Figure 1. SA Registrations Figure 2 shows UA queries to 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. +----+ +-------+ | | | | | 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. W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 3] Internet Draft DA Interaction April 10, 2000 4. Peer Relationship We use a set of fully meshed TCP connections among peer DAs. These peering TCP connections provide reliable communication channels for peer DAs to exchange messages. Therefore, a DA implementation is not burdened by managing message retransmissions. A peer relationship includes three stages: setting up, keeping and tearing down. We describe each stage in details 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 of 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. And 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 exist yet. Then it sends a DAAdvert message with a "peering-connection-indication" attribute through the TCP channel to notify the peer that this is a peering connection (Figure 6). So that the peer, if it is also mesh-enhanced, can use this peering connection to forward messages in opposite direction. +-----+ +-----+ | | [attr = peering-connection-indication] | | | DA1 | ------------- DAAdvert (TCP) ------------> | DA2 | | | | | +-----+ +-----+ Figure 6. Peering Connection Indication W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 4] Internet Draft DA Interaction April 10, 2000 After peering TCP connection is established or identified, peer DAs begin to forward new Srv(De)Reg messages to each other. At the same time, a mesh-enhanced DA SHOULD decide whether it needs to get old registration data from its peers. For example, when a newly booted DA joins a mirrored DA set of five DAs, it needs to get a copy of the existing registration data from one of the five DAs. However, it does not need to download the old registration data from all five DAs, which will bring a lot of redundant transmissions. To download the shared data from a peer (must be mesh-enhanced), a mesh-enhanced DA sends a DAAdvert message with a "data-copy-request" attribute to the peer (Figure 7). The peer dumps the data of shared scopes as SrvReg messages, with a re-calculated new lifetime (= old lifetime - elapsed time). After they exchange their data in both directions, these two peers 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 the peering TCP connections alive, a mesh-enhanced DA SHOULD send a DAAdvert message with a "keepalive" attribute to each of its peers via the peering channel every CONFIG_DA_KEEPALIVE (< CONFIG_CLOSE_CONN) seconds (Figure 8). +-----+ +-----+ | | | | | DA1 | ------------ DAAdvert (TCP) ------------> | DA2 | | | [attr = keepalive] | | +-----+ +-----+ Figure 8. DA Keepalive 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; or when it receives a multicast DAAdvert message from the peer with a DA Stateless Boot Timestamp set to 0; 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 W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 5] Internet Draft DA Interaction April 10, 2000 partition and peer DA states get inconsistent. To tear down a peer relationship, a DA stops forwarding any Srv(De)Reg messages to this peer, closes TCP connection with this peer, and removes this peer from its peer list. 5. Message Forwarding Rules (1) A Srv(De)Reg message MUST have a "Mesh Forward Extension" (MF- extension) if it is aimed to be forwarded by a mesh-enhanced DA. The MF-extension is always six bytes long. The one-byte Extension Data 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, no need to be forwarded again. Figure 9 illustrates its format. So, only when a Srv(De)Reg has an MF- extension and its Action field is TO_BE_FORWARDED, it SHOULD be forwarded. 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 Forward Extension = TBD | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, contd. | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Mesh Forward Extension (2) A Srv(De)Reg message is forwarded from a mesh-enhanced DA to all the peers in the registration scope. Before a message is forwarded, its Action field in the MF-extension is changed from TO_BE_FORWARDED to HAS_BEEN_FORWARDED. In this way, a message can only be forwarded once. As the mirrored DAs are 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) 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. W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 6] Internet Draft DA Interaction April 10, 2000 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 A forwarded message can be identified easily since it is received via a peering TCP channel whose connection id is in the DA's peer list. A forwarded Srv(De)Reg message MUST not be forwarded again. 6.2 Simplifying SA Registrations A mesh-aware SA only needs to send its Srv(De)Reg messages to one mesh-enhanced DA in the registration scope. The information will be propagated automatically within the domain. 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. A mesh-aware SA MUST include an MF-extension in its Srv(De)DeReg messages in order for the messages to be forwarded by a mesh-enhanced DA. The added MF-extension ensures that the Srv(De)Reg messages from non-mesh-aware SAs are not forwarded by mesh-enhanced DAs. 6.3 Forwarding UA Queries A further extension for 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 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 share some scopes with it. Second, 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. We did not include this extension in our scheme mainly due to its complexity. However, for thin-client UA implementation, it might deserve further consideration. 6.4 Reliability Adding more DAs increases reliability. For example, if you had more W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 7] Internet Draft DA Interaction April 10, 2000 than one DA in each scope, when one DA is down, at least one other DA can continue to provide the service for the scope. Mesh-enhanced DAs ensure the data consistency among peer DAs automatically. 6.5 Scalability With mesh-enhanced DAs and simplified SAs, the overall SLP system scalability can be enhanced. However, since we use fully meshed TCP connections among DAs, 2-4 DAs is the recommended value for each scope. It does 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. 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 can only register with one mesh-enhanced DA by adding an MF-extension to the messages. 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 old data from other DAs. So uniformly mesh-enhanced DAs can provide a much easy 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 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)", W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 8] Internet Draft DA Interaction April 10, 2000 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 Columbia University Department of Computer Science 1214 Amsterdam Ave. New York, NY 10027-7003 email: zwb@cs.columbia.edu Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Ave. New York, NY 10027-7003 email: hgs@cs.columbia.edu W. Zhao, H. Schulzrinne Expires: October 10, 2000 [Page 9]