Mesh-enhanced Service Location Protocol (mSLP)
RFC 3528

 
Document Type RFC - Experimental (May 2003; No errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3528 (Experimental)
Telechat date
Responsible AD Thomas Narten
IESG note 2003-05-01: RFC 3528 appears
Send notices to <schulzrinne@cs.columbia.edu>, <erik.guttman@sun.com>, <zwb@cs.columbia.edu>
Network Working Group                                            W. Zhao
Request for Comments: 3528                                H. Schulzrinne
Category: Experimental                               Columbia University
                                                              E. Guttman
                                                        Sun Microsystems
                                                              April 2003

             Mesh-enhanced Service Location Protocol (mSLP)

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes the Mesh-enhanced Service Location Protocol
   (mSLP).  mSLP enhances the Service Location Protocol (SLP) with a
   scope-based fully-meshed peering Directory Agent (DA) architecture.
   Peer DAs exchange new service registrations in shared scopes via
   anti-entropy and direct forwarding.  mSLP improves the reliability
   and consistency of SLP DA services, and simplifies Service Agent (SA)
   registrations in systems with multiple DAs.  mSLP is backward
   compatible with SLPv2 and can be deployed incrementally.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Notation Conventions . . . . . . . . . . . . . . . . . .  2
       1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Compatibility  . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope-based Fully-meshed Peering DA Architecture . . . . . . .  4
   3.  Peer Relationship Management . . . . . . . . . . . . . . . . .  6
       3.1.  Learning about New Peers . . . . . . . . . . . . . . . .  6
       3.2.  Establishing a Peering Connection  . . . . . . . . . . .  6
       3.3.  Exchanging Information about Existing Peers  . . . . . .  6
       3.4.  Maintaining a Peer Relationship  . . . . . . . . . . . .  7
       3.5.  Tearing Down a Peer Relationship . . . . . . . . . . . .  7
   4.  Registration Propagation Control . . . . . . . . . . . . . . .  7
       4.1.  Accept ID and Propagation Order  . . . . . . . . . . . .  7
       4.2.  Version Timestamp and Registration Version Resolution  .  8

Zhao, et al.                  Experimental                      [Page 1]
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 [RFC2608]), 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 [RFC1771]).  Peer DAs exchange new
   service registrations in shared scopes via anti-entropy [EPID-
   ALGO,UPDA-PROP] and direct forwarding.  mSLP improves the reliability
Show full document text