mslp - Mesh-enhanced Service Location Protocol Λ

Transcription

1 mslp - Mesh-enhanced Service Location Protocol Λ Weibin Zhao and Henning Schulzrinne Department of Computer Science Columbia University, New York, NY fzwb, hgsg@cs.columbia.edu Abstract The Service Location Protocol (SLP) is a proposed standard from IETF. It provides a flexible and scalable service discovery framework in IP network, and it can work with or without a directory service. This paper presents mslp - Mesh-enhanced Service Location Protocol. mslp proposes to use a fully meshed peering Directory Agent () architecture. Peer s exchange service registration information, and keep the same consistent data for the shared scopes. mslp provides a reliable directory service for an SLP system. It also greatly simplifies SLP service registration leading to a thin-client Service Agent () implementation. mslp is backward compatible with SLPv2, and incremental deployment is supported. Keywords: Service Discovery, Service Location Protocol, User Agent, Service Agent, Directory Agent, Fully Meshed Peer Relationship, Reliability, Scalability 1 Introduction As computing continues to move towards a network-centric model, there is an increasing need to find and make use of the available services, devices, and applications in a variety of networking environments in order to properly complete specified tasks. For example, the mobile technology provides much convenience for a traveling user, it relies upon the support from automated service discovery. As a result, several service discovery protocols are emerging from network computing field to address this issue. The Service Location Protocol (SLP) [4] from IETF is designed to perform service discovery in IP network. Jini [7] from Sun Microsystems is tailored specifically to Java platform. The Universal Plug and Play (UPnP) [9] from Microsoft proposes to use SSDP (Simple Service Discovery Protocol) [2] for service discovery, and it addresses the issue of automatic configuration such as the assignment of IP addresses and DNS names. The Salutation Consortium [8] has announced an open architecture for service discovery. The Bluetooth SIG [5] presents its own SDP (Service Λ Supported by RPA MarketNet project. 1 Discovery Protocol) optimized for the highly dynamic nature of wireless communication using radio link. The Infrared Data Association (Ir) [6] also offers its unique service discovery protocol. Although different service discovery protocols have different features, they use two basic models. In the directorycentric model, there is a centralized directory service which maintains dynamic information about available network services, devices and applications. Each device, service and application must discover this directory service first in order to register with it or use it to look up the information about other devices, services and applications. In the peer-to-peer model, no centralized directory service is needed. Devices, services and applications negotiate oneon-one with each other, announcing their presence, advertising their own capabilities, and finding devices, services or applications that meet their needs. This model fits perfectly in an ad hoc peer-to-peer networking environment. Jini adopts the directory-centric model with a lookup service while Ir uses the peer-to-peer model. SLP and UPnP support both models. No matter what model is used, the underlying principles for service discovery are same. First, an entity (device, service or application) needs to announce its presence to others. This can be done by registering with a directory service, by regularly advertising through a special channel or address, or by listening to a special channel or address and issuing a reply when there is a request. Second, the service discovery is performed by looking up a directory service, by sending a discovery request to a special channel or address, or by listening to a special channel or address for others announcements. Most service discovery protocols utilize multicast (or broadcast) which is needed at least in the initial discovery stage such as discovering a lookup service. In some cases, information is needed if none of above mechanisms exists. Among the current available service discovery protocols, SLP is a proposed standard from IETF. It has received wide industry support. For example, Sun Microsystems has built SLP into its Solaris 2.8 operating system; Novell supports SLP in its NetWare product. SLP can work with or without a directory service. The directory service is introduced for performance and scalability considerations, and it is provided by Directory Agents (s). However, SLP does not

2 define how s should coordinate with each other when multiple s exist. This paper presents mslp - Mesh-enhanced Service Location Protocol, which enhances SLP with an interaction scheme for s. It proposes that if s are needed in an SLP system, a fully meshed peering architecture should be used, i.e., more than one should be present for each scope, and they should maintain a fully meshed peer relationship. Peer s exchange service registration information, and keep the same consistent data for the shared scopes. mslp provides a reliable directory service for an SLP system. It also greatly simplifies SLP service registration leading to a thin-client Service Agent () implementation. Thus, the scalability of an SLP system can also be enhanced. Moreover, mslp is entirely backward compatible with the SLP specification defined in RFC 2608, and incremental deployment is supported. The rest of this paper is organized as follows: first, we provide some background information about SLP in Section 2, then we describe the design of mslp in Section 3, covering design considerations, peer relationship management and message forwarding control. We show an mslp system example in Section 4, and discuss the implementation in Section 5. We list related work in Section 6, and conclude in Section 7. 2 SLP Overview Defined in Request for Comments (RFC) 2608, SLP provides a flexible and scalable framework for service discovery in IP network. Using SLP, a networked service (device, or application) can easily find all available service types, the locations (URLs) where a specific service is provided, and service descriptions. To understand how SLP works, we first review several important concepts SLP used to describe and manage networked services. Service Location Service locations in SLP are given by URLs, which can be any URL conforming to URI standard [1] such as or can be of the service: scheme defined in [3] such as service:lpr://mandolin.cs.columbia.edu. Service Type Each service in SLP has a service type. For example, the service type of is http (web service); the service type of service:lpr://mandolin.cs.columbia.edu is service:lpr (printing service). All services in SLP are categorized by their service types. Service Description Besides service location and service type, each service in SLP has many other properties which can be described by a set of attribute/value pairs. These properties include service capability and configuration parameters. For example, we may specify resolution = 1200 dpi for a printer service. Application SrvTypeRqst/SrvRqst/AttrRqst SrvTypeRply/SrvRply/AttrRply SrvTypeRqst/SrvRqst/AttrRqst SrvReg/SrvDeReg SrvTypeRply/SrvRply/AttrRply SrvAck Figure 1: SLP System Architecture Service Service Scope Each service in SLP has one or more service scopes which specify its service range. The service scope is a logical concept in SLP used to arrange services into groups. A scope could indicate a geographic location (such as London ), a administrative group (such as Law School ), or other category (such as Emergency ). Service scope provides further scalability for SLP in large systems. Service Lifetime Each service registration has a validity period given by its service lifetime (such as 12 hours). A registration needs to be refreshed before its lifetime has expired, otherwise the registration will be removed from the directory service. There are three different entities in an SLP system: User Agents (s), Service Agents (s), and Directory Agents (s). Figure 1 illustrates their relationship. User Agents (s) A initiates service discovery on behalf of one or more applications. It sends queries to all s via multicast or to a via unicast if there is such supporting the query scope. A uses three different types of SLP messages to discover the desired services. First, it issues a service type request (SrvTypeRqst) message to get a list of all available service types in a service type reply (SrvTypeRply) message. Second, it issues an attribute request (AttrRqst) message to get a list of all attributes for a given service type in an attribute reply (AttrRply) message. Third, it issues a service request (SrvRqst) message with an attribute predicate specifying the characteristics of the desired service to get a list of URLs giving the locations of matched services in a service reply (SrvRply) message. Starting from the desired service type, and a set of attributes describing the service, SLP resolves the service addresses (URLs) for the user. Service Agents (s) An works on behalf of one or more services. It responds directly to queries. If s exist, it registers the services with s using service registration (SrvReg) messages. SLP supports incremental service registration in which an can 2

3 Multicast SrvRqst (1) / Unicast Advert (2) / Multicast Advert Unicast SrvRqst Unicast SrvReg Unicast SrvAck Unicast SrvAck Unicast SrvReg Figure 2: Discovery: (1) Active (2) Passive Figure 4: Medium SLP System with s Multicast SrvRqst Multicast SrvRqst Multicast SrvRqst CU Scope NYU Scope Figure 3: Small SLP System without s update attribute values or add new attributes to a previously registered service. The new attributes replace the old values, but do not affect the attributes which were included previously and are not present in the update. Thus, a SrvReg message can be a fresh service registration or an update to a previous registration. An can also deregister the services with s using service deregistration (SrvDeReg) messages before the registered services become expired. Directory Agents (s) A serves as a centralized information repository in an SLP system. It accepts registrations and answers queries. support is optional in an SLP system; it is introduced for performance and scalability considerations. s can be discovered (Figure 2) in two ways: active or passive. In SLP, each periodically sends unsolicited advertisement (Advert) messages to the administratively scoped SLP multicast [10] address ( ). All s, s and s listen to this address to discover the existing s. This is known as passive discovery. s and s can also perform active discovery by issuing a multicast discovery service request message (SrvRqst with a service type of service:directoryagent ) to above address. s answer each discovery request with a unicast advertisement message. Whether s exist or not, an SLP system can provide the same service discovery functionality. However, it works a little bit differently. ffl In a small SLP system without s (Figure 3), s directly send service request (SrvRqst) messages to Figure 5: Large SLP System with Multiple Scoped s all s via multicast, and s respond with unicast service reply (SrvRply) messages. ffl Since it is not very efficient for a to query all s via multicast every time it does service discovery, in a medium-sized SLP system (Figure 4), s are introduced to provide a centralized directory service. s register services with s, and s look up service information from s. All service registrations from s and service queries from s are sent to s via unicast. ffl In a large SLP system (Figure 5), s are arranged into different scopes. For example, services from Columbia University and NYU are assigned to different scopes served by different s. This ensures further scalability of SLP. We can see that SLP achieves scalability by using s and service scopes. However, the centralized directory service provided by s presents a single failure point in an SLP system. To ensure reliability, multiple s are needed for each service scope. When multiple s are present, how should they interact with each other? This is an open issue in SLPv2 (SLP version 2). 3 DesignofmSLP mslp enhances SLP with an interaction scheme for s to provide a reliable directory service. It proposes that if s are needed in an SLP system, a fully meshed peering architecture should be used, i.e., more than one 3

4 1 Multicast Advert [ attr = mesh enhanced ] 2// Figure 6: Mesh-enhanced Advertisement should be present for each scope, and they maintain a fully meshed peer relationship. Peer s 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, peer s maintain the same consistent data for the shared scopes. Our design uses the following terminology: Peer s If two s have one or more scopes in common within one administrative domain, they are peers. Peer s coordinate with each other and store the same consistent data for the shared scopes. Peering TCP Connection - a persistent TCP connection kept by a pair of peer s for the entire peering period. It provides a reliable communication channel for the peer s to exchange messages. Therefore, a implementation is not burdened by managing message retransmissions. Its closing can be an indication of the termination of the peer relationship. Mesh-enhanced - a who maintains a fully meshed peering architecture with other s in an mslp system. It carries the mesh-enhanced attribute in its Advert messages (Figure 6) to distinguish itself from non-mesh-enhanced s. Mesh-aware - an who understands the meshenhanced attribute in a Advert message and uses the mesh-enhanced capability accordingly. In the next three subsections, we first describe our design considerations for mslp, then we discuss two important issues: how to manage the peer relationship and how to control message forwarding among peer s. 3.1 Design Considerations Reliability: The fully meshed peering architecture provides a reliable directory service for an SLP system. It achieves maximum robustness by ensuring that no single failure point exists in the system. All service registrations are kept by at least two s. If one is down, at least one other peer can continue to provide the service information for the scope. More importantly, the peering architecture enables a to recover from crash with much less effort since a rebooted can get the existing data from its peering set. The fully meshed peering architecture is built on top of a set of fully meshed peering TCP connections. We choose to use this set of fully meshed peering TCP connections mainly because it greatly facilitates message forwarding control. Any service registration information received by a only needs one-hop forwarding to reach all other s in the peering set. Since adding too many s to a peering set does not help a lot with the reliability, and it increases the maintenance overhead, we anticipate a small number of s for each service scope, and 2-4 is the recommended value. There is no need to have separate for each scope. A can serve multiple scopes, and a peering TCP connection is used for all shared scopes between each pair of peer s. Scalability: The SLPv2 specification requires that s register with all existing s and re-register when new s are discovered, or old s are found to have rebooted. This places a substantial burden on an implementation. With mslp, this requirement on s can be greatly simplified, i.e., a mesh-aware only needs to register with one mesh-enhanced in the registration scope, and the registration information will be propagated automatically within the meshed set. With mesh-enhanced s and simplified s, the overall system scalability can be enhanced. Compatibility: mslp is fully backward compatible with SLPv2. It does not introduce any new protocol elements. mslp only defines several new attributes for the Advert message and a new SLP extension ( meshforwarding extension ). As we have described in Section 2, each periodically multicasts unsolicited Advert messages, which enable a to be discovered by s, s and other s. A can put new attributes in its Advert messages to signify the information for coordination. Thus, by properly setting the attributes in Advert messages and properly handling these attributes at the other party, peer s can interact with each other to provide the desired functionality. The coordination is added as an enhancement to a, its original functions are not affected. Moreover, the changes are almost transparent to s and s. s can be kept unchanged. s can be greatly simplified if they use the mesh-forwarding capability for their service registrations. To do this, a mesh-aware needs to explicitly specify its mesh-forwarding request by using the mesh-forwarding extension (see Section 3.3 for detail). Deployment: mslp supports incremental deployment of mesh-enhanced s. A mesh-enhanced can set up peer relationships with both mesh-enhanced s and non-mesh-enhanced s. In the latter case, the message forwarding only goes in uni-direction from the meshenhanced to a non-mesh-enhanced. When meshenhanced s coexist with non-mesh-enhanced s in a system, a mesh-aware should take care of newly found non-mesh-enhanced s and rebooted non-meshenhanced s since these non-mesh-enhanced s can not get existing data from other s. Therefore, uniformly mesh-enhanced s can provide a much easier job for mesh-aware s. 4

5 1 Advert (TCP) [ attr = peering connection indication ] 2 1 Advert (TCP) [ attr = keepalive ] 2 1 Figure 7: Peering Connection Indication Advert (TCP) [ attr = data copy request ] SrvReg (TCP) (data of shared scopes) Figure 8: Dumping Data 3.2 Peer Relationship Management 2 A peer relationship has three stages: setting up, keeping, and tearing down. In mslp, a mesh-enhanced 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 peer list should include peer URL, shared scopes, boot timestamp, and peering TCP connection ID. The boot timestamp is used to identify a rebooted peer. The peering TCP connection is used for message forwarding. When a mesh-enhanced learns about a new peer, it creates a peering TCP connection to the peer (at port 427) if such connection does not yet exist. Then it sends a Advert message with the peering-connection-indication attribute through this channel to notify the peer that this is a peering TCP connection (Figure 7). Thus, the peer can also use this channel to send messages in opposite direction. After the peering TCP connection is established or identified, peer s begin to forward new service registration information to each other via this channel. At the same time, a mesh-enhanced should decide whether it needs to download the data from its new peers. For example, when a newly booted joins a peering set of three s, it needs to get a copy of the existing registration data from any one of these three s (the choice can be made randomly), but not from all of them which incurs a lot of redundant transmissions. To do this, it sends a Advert message with the data-copy-request attribute to the chosen peer (Figure 8). On the other end, when a meshenhanced receives the data-copy-request in a Advert message, it dumps all the data of the shared scopes to the requesting. Each data record is sent as a SrvReg message, with a re-calculated new lifetime (= old lifetime elapsed time). After exchanging the data in both directions, peer s have the same consistent data for the shared scopes. According to SLPv2, a could close a TCP connection if it has been idle for too long. To keep a peering TCP connection alive, a mesh-enhanced sends a Advert message with the keepalive attribute (Figure 9) to the Figure 9: Keepalive peer if no other messages have been sent via the channel for a long period (predefined). A mesh-enhanced should tear down a peer relationship when it finds that the peer has closed the peering TCP connection; when it receives a multicast Advert message from the peer with a stateless boot timestamp set to 0 meaning the peer is going to shutdown; or when it has not received any message from the peer via the peering channel for a long period (predefined). In the last case, there may be a network partition and peer states get inconsistent. To tear down a peer relationship, a stops forwarding any service registration information to this peer, closes peering TCP connection with this peer, and removes this peer from its peer list. 3.3 Message Forwarding Control During the peering period, peer s forward new service registration information from s 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. The message forwarding rules are as follows: 1. Explicit Forwarding: A message is forwarded only when it explicitely requests to be forwarded. A meshaware needs to attach the mesh-forwarding extension to a SrvReg or SrvDeReg message and set the Action field to TO BE FORWARDED if it wants the message to be forwarded by a mesh-enhanced. This is for the compatibility with SLPv2, where s need to register with all existing s. To avoid unnecessary forwarding, the explicit forwarding rule is used. 2. One-hop Forwarding: A SrvReg or SrvDeReg message is forwarded only once by a mesh-enhanced to all its peers in the registration scope. Before forwarding a message, a mesh-enhanced sets the Action field to HAS BEEN FORWARDED. In this way, a forwarded message will never be forwarded again. Since the peering set is in a fully connected mesh, one-hop forwarding is enough to ensure that the service registration information from an can reach all peer s. Figure 10 shows how a service registration message is forwarded. 3. Handling SrvAck: A always replies with a ser- 5

6 (TO_BE_FORWARDED) SrvReg / SrvDeReg SrvAck 1 (HAS_BEEN_FORWARDED) SrvReg / SrvDeReg SrvAck 2 1 (Busi., Engi.) Figure 10: Forwarding Registration Peering Connection / (Busi., Engi., Law) Peering Connection vice acknowledgment (SrvAck) message when it receives a SrvReg or SrvDeReg message. So a mesh-enhanced should process SrvAck messages from other s. 4 Example Let s go through an example to see how mslp works. Considering that we want to deploy an mslp system in Columbia University main campus, and we would like to assign the services in Law School (L-School), Business School (B-School) and Engineering School (E-School) to three different scopes. Instead of using a separate for each school, mslp uses three s in a fully meshed peering architecture. Each serves two scopes and each school is served by two s (Figure 11). For example, 1 serves both B-School and E-School, and L-School is served by 2 and 3. We can run this example on four computers: one for the /, and three for the s. Each machine can host only one since a needs to bind to the SLP reserved port 427. An mslp system can be in one of the three stages: 1. Normal stage: This is a stable stage featuring automatic registration information distribution. Assume that the mesh-aware does service registrations with the mesh-forwarding extension, say it registers services in B- School with 1, services in E-School with 2, and services in L-School with 3, then this mslp system will distributethe service registration information automatically among peer s for the shared scopes. Now let the query service information in L-School with 2, it will get the same data as what the has registered with Under partial crash: This is an unstable stage needs to be taken care of. Assume one of the three s crashes, say 1 (we can simulate its crash by removing its network connection and then turning it off), this mslp system can still function well unless more s crash. Although the data of B-School and E-School are not available from 1, they can be retrieved from 3 and 2, respectively. 3. Recovery from crash: When a crashed comes up, say 1 (we reconnect 1 machine to the network and reboot it), it sets up peer relationship with other s again. Since now 1 carries a new boot timestamp, 2 and 3 knows that it is rebooted and coordinates with it. 1 retrieves B-School data from 3 and E-School data from 2, then this peering set is back to normal. Thanks to the fully meshed peering architecture, the recovery of 1 from crash is done automatically through 2 (Engi., Law) Peering Connection Figure 11: an mslp System Example coordination, no involvement is needed. 5 Implementation 3 (Law, Busi.) We have done a prototype implementation of mslp. It is available at zwb/project/slp. A little more effort is needed for an mslp implementation which requires a peer relationship management and service registration forwarding control. However, an mslp implementation is greatly simplified since it no longer needs to implement the complicated algorithm to register with all existing s and to re-register when new s are discovered, or old s are found to have rebooted. So the overall implementation cost of mslp is about the same as SLPv2 if it is not reduced. 6 Related Work Our early work on mslp was presented as an Internet Draft in Interaction of SLP Directory Agents for Reliability and Scalability [14]. The fully meshed peer relationship is used in IBGP [13]. Redundancy is a basic method to ensure reliability, the DNS [11, 12] primary and secondary server architecture is a good example of this. 7 Conclusion In this paper we presented mslp - Mesh-enhanced Service Location Protocol. It enhances SLP with a fully meshed peering architecture. mslp can provide a reliable directory service for an SLP system. It can also greatly simplify service registration which can lead to a thin-client implementation. mslp is fully compatible with SLPv2, and it supports incremental deployment. A further extension to the interaction of mslp s is to forward queries besides registrations. It works as follows: When a mesh-enhanced receives a query which is not in its scope, it forwards the query to another which supports the scope. This can simplify implementation since s do not need to keep track of 6

7 scopes. A can send its queries to any mesh-enhanced. However, this adds much complexity to the meshenhanced implementation. First, a mesh-enhanced needs to keep track of all s of all scopes, not only the s that share some scopes with it. Second, a meshenhanced needs to forward the query to another, and it also needs to forward the reply from another back to the. mslp does not include this extension mainly due to its complexity. However, for a thin-client implementation, it might deserve further considerations. [13] Y. Rekhter and T. Li. A border gateway protocol 4 (BGP-4). Request for Comments 1771, Internet Engineering Task Force, March [14] W. Zhao and H. Schulzrinne. Interaction of SLP directory agents for reliability and scalability. Internet Draft, Internet Engineering Task Force, April Work in progress. Acknowledgments: Erik Guttman provided valuable comments and suggestions for our work on mslp. References [1] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform resource identifiers (URI): generic syntax. Request for Comments 2396, Internet Engineering Task Force, August [2] Y. Goland, T. Cai, P. Leach, Y. Gu, and S. Albright. Simple service discovery Protocol/1.0 operationg without an arbiter. Internet Draft, Internet Engineering Task Force, November Work in progress. [3] E. Guttman, C. Perkins, and J. Kempf. Service templates and service: Schemes. Request for Comments 2609, Internet Engineering Task Force, June [4] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service location protocol, version 2. Request for Comments 2608, Internet Engineering Task Force, June [5] Bluetooth home page. [6] Ir home page. [7] Jini home page. [8] Salutation home page. [9] UPnP home page. [10] D. Meyer. Administratively scoped IP multicast. Request for Comments 2365, Internet Engineering Task Force, July [11] P. V. Mockapetris. Domain names - concepts and facilities. Request for Comments 1034, Internet Engineering Task Force, November [12] P. V. Mockapetris. Domain names - implementation and specification. Request for Comments 1035, Internet Engineering Task Force, November