RFC 3528 (rfc3528) - Page 2 of 15

Mesh-enhanced Service Location Protocol (mSLP)

Alternative Format: Original Text Document

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003


       4.3.  Mesh Forwarding Extension  . . . . . . . . . . . . . . .  8
       4.4.  Summary Vector . . . . . . . . . . . . . . . . . . . . .  9
       4.5.  Service Deregistration . . . . . . . . . . . . . . . . . 10
       4.6.  Anti-entropy Request Message . . . . . . . . . . . . . . 10
       4.7.  Anti-entropy . . . . . . . . . . . . . . . . . . . . . . 11
       4.8.  Direct Forwarding  . . . . . . . . . . . . . . . . . . . 11
       4.9.  SrvAck Message . . . . . . . . . . . . . . . . . . . . . 12
       4.10. Control Information  . . . . . . . . . . . . . . . . . . 12
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       10.1. Normative References . . . . . . . . . . . . . . . . . . 13
       10.2. Informative References . . . . . . . . . . . . . . . . . 14
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15

1. Introduction

   In the Service Location Protocol (SLPv2 [RFC 2608]), Directory Agents
   (DAs) accept service registrations from Service Agents (SAs) and
   answer queries from User Agents (UAs); they enhance the performance
   and scalability of SLPv2.  The use of scopes in SLPv2 further
   improves its scalability.  In general, a DA can serve multiple
   scopes, and a scope can be served by multiple DAs.  When multiple DAs
   are present for a scope, how should they interact with each other?
   This document describes the Mesh-enhanced Service Location Protocol
   (mSLP), addressing this open issue in SLPv2.

   mSLP defines a scope-based fully-meshed peering DA architecture: for
   each scope, all DAs serving the scope form a fully-meshed peer
   relationship (similar to IBGP [RFC 1771]).  Peer DAs exchange new
   service registrations in shared scopes via anti-entropy [EPID-
   ALGO,UPDA-PROP] and direct forwarding.  mSLP improves the reliability
   and consistency of SLP DA services, and simplifies SA registrations
   in systems with multiple DAs.

1.1. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC 2119].






Zhao, et al.                  Experimental
< Previous
Next >