Introduction to mSLP

Introduction to mSLP

1. Introduction

The Mesh-enhanced Service Location Protocol (mSLP) enhances SLP with a fully-meshed peering DA architecture. Peer DAs exchange service registration states when they set up a peer relationship and continue to exchange new service registration updates during the entire peering period so as to maintain the same consistent data for shared scopes. mSLP improves the reliability and consistency of SLP directory services. It also simplifies SA registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.

2. Design

Figure 1. mSLP System Architecture

Figure 1 shows the mSLP architecture. In general, mSLP is a lightweight protocol for dynamic directory replication. It has the following main components:

Peer Relationship Management: there is a peering connection between each pair of peers. A DA learns about its peers in several ways, such as exchanging peer information via DAAdverts.
Registration Update Propagation: mSLP uses direct forwarding (push model) and anti-entropy (pull model) to propagate registration updates and new states (via SrvRegs and SrvDeRegs).
Version Resolution: mSLP uses the Version Timestamp from Service Agents (SAs) to resolve the different versions of the same registration.
Handling Deleted States: a deleted registration is not removed right away, instead, a deletion flag is set. A registration is purged (whether deleted or not) when it expires.
Failure Detection: mSLP uses the heat-beat mechanism (keepalive) to detect peer DA failures and network partitions.

mSLP defined two new SLP message types: (1) Data Request (DataRqst), which is used to request new registration states that have an Accept ID greater the specified Accept ID; (2) Data Reply Complete (DataRplyCmpl), which is used by a mesh-enhanced DA to notify a peer that the replies (via SrvReg/SrvDeReg messages) to a corresponding DataRqst from the peer have been completed. A DataRplyCmpl and its corresponding DataRqst carry the same Accept ID.

mSLP also defined a new SLP extension: Mesh Forwarding (MeshFwd), which is used to carry the Version Timestamp and the Accept ID of a registration update. Two Forwarding IDs (FwdIDs) are defined: RqstFwd and Fwded.

3. Implementation

We implemented mSLP in Java 1.3. It is fully compatible with SLPv2, but with added mesh-enhancement functions. Our implementation has the following features:

It is delivered as two separate programs: one for server (DA), one for client (a combination of UA/SA). As we focus on DA interactions, we do not provide a separate SA program to work as a server.
Both client and server have an easy to use Java GUI.
A DA uses an internal database to store service registrations for simplicity and efficiency.
A DA can work as a mesh-enhanced or non-mesh-enhanced DA. The default is mesh-enhanced.
A DA can be configured to (or not to) multicast DAAdvert messages. The default is to multicast.

The following SLP standard functions are supported:

All SLP messages except SAAdvert (as an SA in our system works as a client to DAs, not a server for UAs): SrvReg, SrvDeReg, SrvAck, SrvRqst, SrvRply, SrvTypeRqst, SrvTypeRply, AttrRqst, AttrRply, DAAdvert.
Both fresh and incremental service registrations (SrvReg).
De-registration of individual attributes (handling the tag list in SrvDeReg messages) and removal of a whole service registration.
The use of different languages in service registrations, requests, and replies. The same service URL can be registered in two different languages (this leads to two different entries in the database). The language tag is enforced in all matches.
The use of naming authority in service registrations and service type requests. Note that if the length of the naming authority string (in SrvTypeRqst messages) is -1 (0xFFFF), it indicates a 'wildcard' service type request (over all naming authorities).
Obtaining attributes for service type as well as for URLs. The tag list in AttrRqst messages is supported.
For service request (SrvRqst), only simple predicates are supported, such as (a=1) and (&(a=1)(b=2)). This conforms to slpv2bis. Complex predicates are not supported.
A UA/SA can choose UDP or TCP to communicate with a DA.
All string comparisons are case insensitive, except for URLs.
A UA/SA uses the response timeout from a DA to handle the DA failure and network partition.

Added mesh-enhancement functions:

Peer relationship management:
- exchange peer information via DAAdverts,
- use the heat-beat mechanism (keepalive) to handle peer failures and network partitions.
Registration propagation:
- Direct Forwarding: forward SrvReg and SrvDeReg messages that have the MeshFwd extension (FwdID = RqstFwd).
- Anti-Entropy: use the DataRqst message to pull new registration states, and use the DataRplyCmpl message to notify the end of replies to a corresponding DataRqst.