INTERNET DRAFT Weibin Zhao Service Location Group Henning Schulzrinne draft-zhao-slp-da-interaction-01.txt Columbia University Expires: September 10, 2000 March 10, 2000 Interaction of SLP Directory Agents for Reliability and Scalability draft-zhao-slp-da-interaction-01.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: September 10, 2000 [Page 1]
Internet Draft DA Interaction March 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: September 10, 2000 [Page 2]
Internet Draft DA Interaction March 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: September 10, 2000 [Page 3]
Internet Draft DA Interaction March 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 When a mesh-enhanced DA (for example, DA2 in Figure 6) learns about a new peer from a multicast DAAdvert message, it SHOULD wait a random interval between 0 to 3 seconds and then replies with a unicast DAAdvert message to indicate itself to the new peer. +-----+ +-----+ | | ---- Multicast DAAdvert (UDP) ---> | | | DA1 | | DA2 | | | <---- Unicast DAAdvert (UDP) ----- | | +-----+ (if DA1 is a new peer) +-----+ Figure 6. Peer Indication The random delay introduced here is to ensure that all the DAs of the same scope don't send their unicast replies at the same time. If they did, the implosion of replies could potentially exceed the sending DA's capacity to process incoming datagrams. To reply with a unicast DAAdvert message when a new peer is discovered from a multicast DAAdvert message can help peer DAs to know each other quickly, and synchronize accordingly. Each 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 list W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 4]
Internet Draft DA Interaction March 10, 2000 includes peer URL, boot timestamp, shared scopes, and peering TCP connection id. The boot timestamp is to identify a rebooted peer whose URL is already in the peer list, but its DAAdvert message carries a boot timestamp that differs from its previous one. A rebooted peer should be treated as a new peer, its old entry in the peer list should be replaced with the new entry. The peering TCP connection id is initialized as NULL and will be filled in after the peering TCP connection is established. After replying with a unicast DAAdvert message to a new peer, a mesh-enhanced DA creates a peering TCP connection to the peer at the SLP reserved port 427. Then it sends a DAAdvert message with a "peering-connection-indication" attribute through the TCP channel to tell the peer that this is a peering connection (Figure 7) 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 7. Peering Connection Indication 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 8). 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 8. Dumping Data W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 5]
Internet Draft DA Interaction March 10, 2000 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 9). +-----+ +-----+ | | | | | DA1 | ------------ DAAdvert (TCP) ------------> | DA2 | | | [attr = keepalive] | | +-----+ +-----+ Figure 9. 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 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) Only Srv(De)Reg messages with a "Mesh Forward Extension" (MF- extension) trailer are forwarded by mesh-enhanced DAs. The MF- extension includes no Extension Data; it is always five bytes long. Figure 10 illustrates 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mesh Forward Extension = TBD | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, continued| +-+-+-+-+-+-+-+-+ Figure 10. Mesh Forward Extension W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 6]
Internet Draft DA Interaction March 10, 2000 (2) A Srv(De)Reg message is forwarded from a mesh-enhanced DA to all its peers in the registration scope. The MF-extension is removed from the forwarded message; and all the affected Next Extension Offsets in the message MUST be adjusted. A message can only be forwarded once since a forwarded message does not have an MF- extension. 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 11 shows how a Srv(De)Reg message is forwarded. +----+ (with MF-extension) +-----+ (no MF-extension) +-----+ | | -- SrvReg/SrvDeReg -> | | -- SrvReg/SrvDeReg -> | | | SA | | DA1 | | DA2 | | | <------ SrvAck ------ | | <------ SrvAck ------ | | +----+ +-----+ +-----+ Figure 11. 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. 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. W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 7]
Internet Draft DA Interaction March 10, 2000 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 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 W. Zhao, H. Schulzrinne Expires: September 10, 2000 [Page 8]
Internet Draft DA Interaction March 10, 2000 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)", 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 the 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: September 10, 2000 [Page 9]