INTERNET DRAFT                                            Weibin Zhao
Service Location Group                            Henning Schulzrinne
draft-zhao-slp-da-interaction-06.txt              Columbia University
Expires: December 23, 2000                               Erik Guttman
                                                     Sun Microsystems
                                                        June 23, 2000


             mSLP - Mesh-enhanced Service Location Protocol
                  draft-zhao-slp-da-interaction-06.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 presents mSLP - Mesh-enhanced Service Location
   Protocol, which enhances SLPv2 with a scheme for the interaction of
   Directory Agents (DAs).  mSLP proposes to use a fully meshed peering
   DA architecture.  Peer DAs exchange service registration information,
   and maintain the same consistent data for the shared scopes.  mSLP
   provides a reliable directory service for an SLP system.  It also
   greatly simplifies Service Agent (SA) registrations. mSLP is backward
   compatible with SLPv2, and incremental deployment is supported.

1. Introduction

   In the Service Location Protocol (RFC 2608 [1]), Directory Agents
   (DAs) are introduced for caching service advertisements from Service



Zhao, et al.           Expires: December 23, 2000               [Page 1]

Internet Draft               DA Interaction                June 23, 2000


   Agents (SAs), and answering queries from User Agents (UAs). They
   exist to enhance the performance and scalability of SLP.

   When multiple DAs are present, how should they interact with each
   other? This is an open issue in SLPv2. This document presents mSLP -
   Mesh-enhanced Service Location Protocol, which enhances SLPv2 with a
   scheme for the interaction of DAs.  mSLP proposes that if DAs are
   needed in an SLP system, a fully meshed peering DA architecture
   should be used, i.e., more than one DA should be present for each
   scope, and they should 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 registration information during the entire peering
   period. As a result, they maintain the same consistent data for the
   shared scopes. mSLP provides a reliable directory service for an SLP
   system.  It also greatly simplifies SA registrations The scalability
   of SLP is thereby enhanced. mSLP is backward compatible with SLPv2,
   and incremental deployment is supported.

   The rest of this document is organized as follows:  Section 2 defines
   the terminology. Section 3 reviews the current DA message flows in
   SLPv2.  Section 4 defines the mesh-enhancement extension.  In Section
   5, we describe the DA peer relationship.  In Section 6, we present
   the message forwarding control among DAs. We discuss our design in
   Section 7, list constants in Section 8, and give security
   considerations in Section 9.

2. Terminology

      Peer DAs
                If two DAs have one or more scopes in common within one
                administrative domain, they are peers. Peer DAs
                coordinate with each other and 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.  It provides
                a reliable communication channel for the peer DAs to
                exchange messages. Therefore, a DA implementation is not
                burdened by managing message retransmissions.  Its
                closing 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 service registration information
                to its peers according to the rules given in this



Zhao, et al.           Expires: December 23, 2000               [Page 2]

Internet Draft               DA Interaction                June 23, 2000


                document.  A mesh-enhanced DA MUST carry the "mesh-
                enhanced" attribute keyword 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 registration
   (SrvReg) and deregistration (SrvDeReg) message, a DA replies with a
   service acknowledgment (SrvAck) message.

   +----+                         +----+
   |    | --- SrvReg/SrvDeReg --> |    |
   | SA |                         | DA |
   |    | <------- SrvAck ------- |    |
   +----+                         +----+

         Figure 1. SA Registrations

   Figure 2 shows UA queries with 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



Zhao, et al.           Expires: December 23, 2000               [Page 3]

Internet Draft               DA Interaction                June 23, 2000


   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.

4. Mesh-enhancement Extension

   We define a new SLP extension - "mesh-enhancement extension" for
   specifying the interaction operations of mesh-enhanced DAs.  This
   extension has a five-byte extension header, a one-byte field denoted
   as "Action-ID", and an optional part of DA list.  Figure 5
   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-Enhancement Extension ID |  Next Extension Offset (NEO)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | NEO, contd.   |   Action-ID   |       Number of DA URLs       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of DA URL #1       |           DA URL #1           \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of DA URL #N       |           DA URL #N           \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 5. Mesh-Enhancement Extension

   The Action-ID is used to specify the requested operations from the
   receiving DA or to indicate the status information to the receiving
   DA. Table 1 lists the defined Action-IDs.

           Action-ID       Abbreviation

               0           No_Action
               1           Mesh_Forward_Rqst
               2           Data_Dump_Rqst



Zhao, et al.           Expires: December 23, 2000               [Page 4]

Internet Draft               DA Interaction                June 23, 2000


               3           Peer_Conn_Indication
               4           Peer_DA_Indication
               5           Peer_Conn_Keepalive

       Table 1. Actions in Mesh-Enhancement Extension

   No_Action: null operation. It is used to turn off other operations.

   Mesh_Forward_Rqst: mesh forwarding request. It requests that the
   receiving DA forward the message to all DAs (both mesh-enhanced and
   non-mesh-enhanced) in the registration scope.

   Data_Dump_Rqst: data dump request. It requests that the receiving DA
   dump all the service registration data in the shared scopes to the
   requesting DA.

   Peer_Conn_Indication: peer connection indication. It informs the
   receiving DA that this is a peering TCP connection.

   Peer_DA_Indication: peer DAs indication. It carries the optional DA
   list in the form of URLs. The receiving DA SHOULD peer with all DAs
   in this list.

   Peer_Conn_Keepalive: peer connection keepalive. It indicates that
   this peering TCP connection is alive. The receiving DA SHOULD not
   close it.

5. Peer Relationship

   We use a set of fully meshed peering TCP connections among peer DAs.
   A mesh-enhanced DA maintains a peer list.  Each entry in this peer
   list includes peer URL, shared scopes, boot timestamp, peering TCP
   connection ID, and mesh flag.  The boot timestamp is to identify a
   rebooted peer. The peering TCP connection is used for message
   forwarding.  The mesh flag tells whether the peer is mesh-enhanced or
   not.  A mesh-enhanced DA adds an entry to its peer list whenever it
   discovers a new peer, removes an entry from the peer list when it
   finds the corresponding peer is down, and updates an entry when it
   detects the corresponding peer is rebooted.

   A peer relationship has three stages: setting up, keeping and tearing
   down. We describe each stage in detail next.  We consider the
   situation where mesh-enhanced DAs, non-mesh-enhanced DAs, mesh-aware
   SAs and non-mesh-aware SAs are coexisted.  Our scheme works even if
   multicast is NOT supported or a DA's multicast DAAdvert can not reach
   all of its peer DAs.

5.1. Setting Up a Peer Relationship



Zhao, et al.           Expires: December 23, 2000               [Page 5]

Internet Draft               DA Interaction                June 23, 2000


   In SLP, each DA periodically sends DA Advertisement (DAAdvert)
   messages to the administratively scoped SLP multicast [3] address
   (239.255.255.253 is the default address in the IPv4 local scope). All
   DAs listen to this address.  A DAAdvert message from a mesh-enhanced
   DA MUST carry the "mesh-enhanced" attribute keyword (Figure 6).

   +-----+                                    +-----------+
   |     |                                    |           |
   | DA1 | ------- Multicast DAAdvert ------> | DA2/UA/SA |
   |     |       [attr = mesh-enhanced]       |           |
   +-----+                                    +-----------+

         Figure 6. Mesh-enhanced DA Advertisement

   When a mesh-enhanced DA learns about a new peer (either mesh-enhanced
   or non-mesh-enhanced), it creates a peering TCP connection to the
   peer if such connection does not yet exist. The mesh-enhanced DA uses
   this peering TCP connection to forward messages to the peer. The
   peer, if mesh-enhanced, also uses this peering TCP connection to
   forward messages in the opposite direction.  Therefore, a peering TCP
   connection MAY be set up between two mesh-enhanced DAs or between a
   mesh-enhanced DA and a non-mesh-enhanced DA.  In the latter case, the
   message forwarding only goes in uni-direction from the mesh-enhanced
   DA to the non-mesh-enhanced DA.

   For a non-mesh-enhanced peer, the mesh-enhanced DA just sets up a
   peering TCP connection with it and forwards message to it through the
   peering TCP connection.  But for a mesh-enhanced peer, the mesh-
   enhanced DA MUST take the following additional steps:

   (1) Peering Connection Indication.  After a peering TCP connection is
   established, the DA who initiates the connection sends a
   "Peer_Conn_Indication" DAAdvert message (We mean the message has the
   mesh-enhancement extension with the Action-ID set to
   "Peer_Conn_Indication". Similar notation is used in the rest of this
   document.) through the connection to mark it as the peering TCP
   connection (Figure 7).

             (1) "Peer_Conn_Indication" DAAdvert
   +-----+   (2) "Peer_DA_Indication" DAAdvert        +-----+
   |     | <----------------- (TCP) ----------------- |     |
   | DA1 |                                            | DA2 |
   |     | ------------------ (TCP) ----------------> |     |
   +-----+       "Peer_DA_Indication" DAAdvert        +-----+

      Figure 7. Peering Connection and Peer DAs Indication





Zhao, et al.           Expires: December 23, 2000               [Page 6]

Internet Draft               DA Interaction                June 23, 2000


   (2) Peer DAs Indication.  After sending the "Peer_Conn_Indication"
   DAAdvert message, the mesh-enhanced DA sends a "Peer_DA_Indication"
   DAAdvert message through the peering TCP connection (Figure 7).  This
   message carries a list of DAs that the receiving DA MUST peer with.
   This DA list is constructed based on the sending DA's peer
   information and the receiving DA's service scopes.  More precisely,
   this list includes those DAs in the sending DA's peer list that share
   some scopes with the receiving DA.

   How does a mesh-enhanced DA react when it receives the
   "Peer_Conn_Indication" and "Peer_DA_Indication" DAAdvert messages?

   When a mesh-enhanced DA receives a "Peer_Conn_Indication" DAAdvert
   message, it SHOULD use the TCP connection from which the message is
   received as the peering TCP connection to the sending DA instead of
   establishing another one (There is a small possibility that a pair of
   peering TCP connections might be created between the two peer DAs if
   they try to set up a peering TCP connection to each other almost at
   the same time.), and reply with a "Peer_DA_Indication" DAAdvert
   message (Figure 7).  By exchanging the peer information through
   "Peer_DA_Indication" DAAdvert messages, the mesh-enhanced DAs can
   learn about other DAs in the shared scopes even if multicast is not
   supported (The initial peer relationships can be configured by hand
   or through DHCP [4]).

   The interaction sequence of in Figure 6 and 7 can be summarized as
   follows (assume DA2 is mesh-enhanced):

   DA1 is a mesh-enhanced peer of DA2:
       <1> DA2 discovers DA1.
       <2> DA2 creates peering TCP connection to DA1.
       <3> DA2 sends "Peer_Conn_Indication" DAAdvert to DA1.
       <4> DA2 sends "Peer_DA_Indication" DAAdvert to DA1.
       <5> DA1 sends "Peer_DA_Indication" DAAdvert to DA2.

   DA1 is a non-mesh-enhanced peer of DA2:
       <1> DA2 discovers DA1.
       <2> DA2 creates peering TCP connection to DA1.

   When a mesh-enhanced DA receives a "Peer_DA_Indication" DAAdvert
   message, it checks the DA list in the message. This DA list can be
   empty in which case the number of DA URLs equals 0. If any URL in the
   list is NOT in its peer list, the mesh-enhanced DA unicasts an active
   DA discovery service request (a SrvRqst message with service type =
   "service:directory-agent") to the DA corresponding to the URL, to
   obtain a DAAdvert message from it (Figure 8).  For example, if DA2
   received the URL for DA3 from DA1 in the "Peer_DA_Indication"
   DAAdvert message (Figure 7), and DA3 is NOT in DA2's peer list, DA2



Zhao, et al.           Expires: December 23, 2000               [Page 7]

Internet Draft               DA Interaction                June 23, 2000


   MUST then acquire a DAAdvert message from DA3 (Figure 8).  Upon
   receiving the DAAdvert message from DA3, DA2 can go through the whole
   process to set up a peer relationship with DA3.

   +-----+            Unicast SrvRqst            +-----+
   |     | ----- (service:directory-agent) ----> |     |
   | DA2 |                                       | DA3 |
   |     | <-------- Unicast DAAdvert ---------- |     |
   +-----+                                       +-----+

                    Figure 8. Obtaining DAAdvert

   (3) Getting Data.  After sending the "Peer_DA_Indication" DAAdvert
   message, the mesh-enhanced DA SHOULD decide whether it needs to get
   the data from the new peer. If it needs, it sends a "Data_Dump_Rqst"
   DAAdvert message to the peer (Figure 9).

   +-----+     "Data_Dump_Rqst" DAAdvert      +-----+
   |     | -------------- (TCP) ------------> |     |
   | DA1 |                                    | DA2 |
   |     | <--------- SrvReg (TCP) ---------- |     |
   +-----+       (data of shared scopes)      +-----+

                 Figure 9. Dumping Data

   Please note that a mesh-enhanced DA does not need to download data
   from all of its new peers.  For example, when a newly booted DA joins
   a peering DA set of three DAs, it needs to get a copy of the existing
   registration data from one of these three DAs, but not from all of
   them, which incurs a lot of redundant transmissions. How to choose a
   DA to download the data from the peering DA set is implementation
   dependent. There are a variety of choices for doing this.  The new DA
   can randomly choose one DA from the peering DA set or just use the
   first DA it found. Other criteria can also be used for the selection
   such as the nearest DA or the most lightly loaded DA.  The choice
   only affects performance.

   On the other hand, when a mesh-enhanced DA receives a
   "Data_Dump_Rqst" DAAdvert message, it dumps all the data of the
   shared scopes to the requesting DA. Each data record is sent as a
   SrvReg message, with a re-calculated new lifetime (= old lifetime -
   elapsed time). After exchanging their data in both directions, peer
   DAs have the same consistent data for the shared scopes.

5.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 a peering TCP



Zhao, et al.           Expires: December 23, 2000               [Page 8]

Internet Draft               DA Interaction                June 23, 2000


   connection alive, a mesh-enhanced DA SHOULD send a
   "Peer_Conn_Keepalive" DAAdvert message via the channel every
   CONFIG_DA_KEEPALIVE (see Section 8) seconds (Figure 10).

   +-----+                                          +-----+
   |     |                                          |     |
   | DA1 | ---------------- (TCP) ----------------> | DA2 |
   |     |      "Peer_Conn_Keepalive" DAAdvert      |     |
   +-----+                                          +-----+

                     Figure 10. DA Keepalive

5.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; when it receives
   a multicast DAAdvert message from the peer with a DA stateless boot
   timestamp set to 0 meaning the peer is going to shutdown; 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 service
   registration information to this peer, closes TCP connection with
   this peer, and removes this peer from its peer list.

6. Message Forwarding Control

6.1. Forwarding SrvReg and SrvDeReg Messages

   A mesh-enhanced DA forwards new service registration information from
   mesh-aware SAs.  The forwarding rules are as follows:

   (1) Explicit Forwarding:  A message is forwarded only when it
   explicitely requests to be forwarded.  A mesh-aware SA needs to
   attach the mesh-enhancement extension to a SrvReg or SrvDeReg message
   and set the Action-ID to "Mesh_Forward_Rqst" if it wants the message
   to be forwarded by a mesh-enhanced DA.  This is for the compatibility
   with SLPv2, where SAs need to register with all existing DAs.  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 DA to all of its peers (both mesh-
   enhanced and non-mesh-enhanced) in the registration scope.  Before
   forwarding a message, a mesh-enhanced DA sets the Action-ID in the
   mesh-enhancement extension to "No_Action".  In this way, a forwarded
   message will never be forwarded again.  Since the peering DA set is
   in a fully connected mesh, one-hop forwarding is enough to ensure



Zhao, et al.           Expires: December 23, 2000               [Page 9]

Internet Draft               DA Interaction                June 23, 2000


   that a message can reach all peer DAs. Figure 11 shows how a
   SrvReg/SrvDeReg message is forwarded.

   +----+  "Mesh_Forward_Rqst"  +-----+       "No_Action"       +-----+
   |    | -- SrvReg/SrvDeReg -> |     | --- SrvReg/SrvDeReg --> |     |
   | SA |                       | DA1 |                         | DA2 |
   |    | <------ SrvAck ------ |     | <------- SrvAck ------- |     |
   +----+                       +-----+                         +-----+

                  Figure 11. Forwarding Registration

   (3) Handling SrvAck: A DA always replies with a SrvAck message when
   it receives a SrvReg or SrvDeReg message.  So a mesh-enhanced DA
   SHOULD process SrvAck messages from other DAs.

6.2. Forwarding DAAdvert Messages

   Besides forwarding service registration information from mesh-aware
   SAs, a mesh-enhanced DA also forwards the DAAdvert messages from its
   non-mesh-enhanced peers.  The forwarding rules are as follows:

   (1) A DAAdvert message is forwarded only when it comes from a new or
   rebooted non-mesh-enhanced peer.

   (2) The DAAdvert message is forwarded to all of its mesh-enhanced
   peers that share some scopes with the advertised DA.

   (3) A forwarded DAAdvert message SHOULD not be forwarded again. It
   can be identified easily since the sending DA and advertised DA are
   different for a forwarded DAAdvert message.

   Forwarding the DAAdvert message from a new or rebooted non-mesh-
   enhanced peer can ensure that the DA is known to all of its mesh-
   enhanced peers even if multicast is NOT supported or its multicast
   DAAdvert messages can NOT reach all of its mesh-enhanced peers.  With
   the peer setting up procedure described in Section 5.1 and the
   forwarding rules given in this section, a DA (mesh-enhanced or non-
   mesh-enhanced) known to one mesh-enhanced peer can be known to all of
   its mesh-enhanced peers.  Therefore, a mesh-enhanced DA can know all
   of its peers (mesh-enhanced and non-mesh-enhanced), and forward
   service registration information from mesh-aware SAs to them
   properly.

7. Design Discussion

   In this section, we discuss several important design issues.

7.1 Meshed Peering TCP Connections



Zhao, et al.           Expires: December 23, 2000              [Page 10]

Internet Draft               DA Interaction                June 23, 2000


   The fully meshed peering DA 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 DA only needs one-hop forwarding to reach
   all other DAs in the peering DA set.  We anticipate a small number of
   DAs for each service scope, and 2-4 is the recommended value.  There
   is no 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.

7.2 Reliability

   The fully meshed peering DA architecture provides maximum robustness.
   It ensures that no single failure point exists in the SLP directory
   service. All service registrations are kept by at least two DAs.  If
   one DA is down, at least one other peer DA can continue to provide
   the service information for the scope.  Moreover, the peering DA
   architecture ensures the data consistency among peer DAs
   automatically. It also enables a DA to recover from crash with much
   less effort since a rebooted DA can get the existing data from its
   peering DA set. This is done through DA coordination, no SA
   involvement is needed.

7.3 Simplifying SA Registrations and Scalability

   The fully meshed peering DA architecture greatly simplifies SA
   registrations.  A mesh-aware SA only needs to register with one
   mesh-enhanced DA in the registration scope. The information will be
   propagated automatically within the peering DA set. 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. With mesh-enhanced DAs and simplified SAs, the overall
   SLP system scalability can be enhanced.

7.4 Forwarding UA Queries

   A further extension to 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 that share some scopes with it.  Second, a
   mesh-enhanced DA needs to forward the query to another DA, and it



Zhao, et al.           Expires: December 23, 2000              [Page 11]

Internet Draft               DA Interaction                June 23, 2000


   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 a thin-client UA implementation, it might
   deserve further consideration.

7.5 Compatibility

   mSLP is backward compatible with SLPv2. It only defines a new
   attribute ("mesh-enhanced") for the DAAdvert message and a new SLP
   extension (mesh-enhancement extension) which is used by DAAdvert,
   SrvReg and SrvDeReg messages.  In mSLP, DAs are enhanced with very
   little added complexity, and the changes are almost transparent to
   UAs and SAs. UAs can be kept unchanged. SAs can be greatly simplified
   by using the mesh-forwarding capability for the service
   registrations.

   mSLP supports incremental deployment of mesh-enhanced DAs.  A mesh-
   enhanced DA MUST set up peer relationships with both mesh-enhanced
   DAs and non-mesh-enhanced DAs. A mesh-aware SA only needs to register
   with one mesh-enhanced DA. However, it still needs to take care of
   newly found non-mesh-enhanced DAs and rebooted non-mesh-enhanced DAs
   since these non-mesh-enhanced DAs can not get the existing data from
   other DAs. Therefore, uniformly mesh-enhanced DAs can provide a much
   easier job for mesh-aware SAs.

7.6 Summary

   We summarize the operations for UAs, mesh-aware SAs, non-mesh-aware
   SAs, mesh-enhanced DAs and non-mesh-enhanced DAs as follows:

   UA

       A UA MAY prefer to use a mesh-enhanced DA to a non-mesh-enhanced
       DA since a mesh-enhanced DA is more likely to reliably contain
       the complete set of current service registration data for the
       UA's scope.

   Non-mesh-aware SA

       It needs to discover all DAs in its scope and register with all
       of them. It does NOT use the mesh-enhancement extension.

   Mesh-aware SA

       It identifies mesh-enhanced DAs from the "mesh-enhanced"
       attribute in the DAAdvert messages.  It only needs to discover
       one mesh-enhanced DA and register with it using a mesh-
       enhancement extension with the Action-ID set to



Zhao, et al.           Expires: December 23, 2000              [Page 12]

Internet Draft               DA Interaction                June 23, 2000


       "Mesh_Forward_Rqst".  If there are no mesh-enhanced DAs in its
       scope, it operates in the same way as a non-mesh-aware SA [1].

   Non-mesh-enhanced DA

       It accepts SrvReg and SrvDeReg messages from SAs and mesh-
       enhanced DAs normally. It dose NOT forward them.

   Mesh-enhanced DA

       (1) It MUST carry the "mesh-enhanced" attribute keyword in its
       DAAdvert messages (Section 2).

       (2) It MUST keep a list of peer DAs (mesh-enhanced and non-mesh-
       enhanced) that share some scopes with it, and maintain a peering
       TCP connection to each of them. For each mesh-enhanced peer, a
       "Peer_Conn_Indication" DAAdvert message SHOULD be sent OR
       processed, a "Peer_DA_Indication" DAAdvert message SHOULD be sent
       AND processed, a "Data_Dump_Rqst" DAAdvert message MAY be sent OR
       processed (Section 5).

       (3) It accepts SrvReg and SrvDeReg messages from SAs and mesh-
       enhanced DAs.  It MUST forward the "Mesh_Forward_Rqst" SrvReg and
       SrvDeReg to all peer DAs (both mesh-enhanced and non-mesh-
       enhanced) in the registration scope.  It also processes SrvAck
       messages from mesh-enhanced DAs (Section 6.1).

       (4) When it receives a DAAdvert messages from a new or rebooted
       non-mesh-enhanced peer, it MUST forward the message to all of its
       mesh-enhanced peers that share some scopes with the advertised DA
       (Section 6.2).

8. Constants

   Mesh-enhancement Extension ID   0x0006          (Section 4)

   CONFIG_DA_KEEPALIVE             290 seconds     (Section 5.2)

   Note: CONFIG_DA_KEEPALIVE < CONFIG_CLOSE_CONN, which has a default
   value of 300 seconds [1].

9. Security Considerations

   DA authentication is more important in mSLP, since mesh-aware SAs
   trust the mesh-enhanced DA they are sending the SrvReg and SrvDeReg
   messages to to forward them. DAs SHOULD use standard SLPv2
   authentication to authenticate other DAs in the mesh. DAs SHOULD also
   perform authentication before accepting SrvReg and SrvDeReg messages



Zhao, et al.           Expires: December 23, 2000              [Page 13]

Internet Draft               DA Interaction                June 23, 2000


   to prevent illegitimate modification or elimination of legitimate
   service registrations. mSLP is just as secure as SLPv2.

10. 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.

   [4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.

11. Authors' Addresses

   Weibin Zhao
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003
   Email: zwb@cs.columbia.edu

   Henning Schulzrinne
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003
   Email: hgs@cs.columbia.edu

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany
   Email: Erik.Guttman@sun.com












Zhao, et al.           Expires: December 23, 2000              [Page 14]