[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 3528

INTERNET DRAFT                                            Weibin Zhao
Service Location Group                            Henning Schulzrinne
draft-zhao-slp-da-interaction-12.txt              Columbia University
July 12, 2001                                            Erik Guttman
Expires: January 12, 2002                            Sun Microsystems


             mSLP - Mesh-enhanced Service Location Protocol


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.

Copyright Notice

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

Abstract

   This document presents the Mesh-enhanced Service Location Protocol
   (mSLP). mSLP enhances SLP with a fully-meshed peering Directory Agent
   (DA) architecture. Peer DAs exchange service registration information
   and maintain the same consistent data for shared scopes. mSLP
   improves the reliability and consistency of SLP directory services.
   It also simplifies Service Agent (SA) registrations in systems with
   multiple DAs. mSLP is backward compatible with SLPv2 and can be
   deployed incrementally.






Zhao, et al.            Expires: January 12, 2002               [Page 1]


Internet Draft               DA Interaction                July 12, 2001


1. Introduction

   In the Service Location Protocol (SLPv2 [1]), Directory Agents (DAs)
   accept service registrations from Service Agents (SAs) and answer
   queries from User Agents (UAs). They enhance the performance and
   scalability of SLP. However, when multiple DAs are present, how
   should they interact with each other? To address this open issue in
   SLPv2, we present the Mesh-enhanced Service Location Protocol (mSLP).

   mSLP proposes that if DAs are needed in an SLP deployment, 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 service registration states for shared scopes when they set up
   a peer relationship and continue to exchange new service registration
   updates during the entire peering period. As a result, they 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.

   Currently, there are three types of DA message flows in SLPv2 [1]:
   acknowledging SA registrations, answering UA queries and enabling DA
   discovery. SLPv2 does not explicitly define message flows among DAs -
   the only message that a DA may receive from other DAs is DAAdvert. We
   will define a set of message flows for DA interactions in this
   document.

2. Terminology

   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 RFC 2119 [3].

      Peer DAs
            DAs that have one or more scopes in common are peers. Peer
            DAs coordinate with each other and maintain the same
            consistent data for shared scopes.

      Peering Connection
            A peering connection is a persistent TCP connection between
            two peer DAs for reliable FIFO message exchange. The closing
            of it terminates the peer relationship.

      Mesh-enhanced DA
            A mesh-enhanced DA MUST carry the "mesh-enhanced" attribute
            keyword in its DAAdvert, maintain peering connections to all
            peers and properly interact with peers.



Zhao, et al.            Expires: January 12, 2002               [Page 2]


Internet Draft               DA Interaction                July 12, 2001


      Mesh-aware SA
            A mesh-aware SA understands the "mesh-enhanced" attribute
            keyword in the DAAdvert and uses the Mesh Forwarding
            extension in its SrvReg/SrvDeReg messages.

      Registration Update
            A registration update refers to a SrvReg/SrvDeReg message.

      Registration State
            A registration state refers to an entry in the registration
            database.

      Accept DA
            For each registration update from mesh-aware SAs, the first
            mesh-enhanced DA that accepts the update is the Accept DA
            for the update. Normally, a registration update is
            propagated from its Accept DA to other DAs in the
            registration scopes.

      Accept Timestamp
            The Accept Timestamp of a registration update is the
            millisecond-accuracy system clock value at its Accept DA
            when the update is accepted. Any two updates accepted by the
            same DA MUST have different Accept Timestamps.

      Version Timestamp
            A mesh-aware SA MUST provide a Version Timestamp in the Mesh
            Forwarding extension for each SrvReg/SrvDeReg message sent
            to a mesh-enhanced DA. This Version Timestamp is the
            millisecond-accuracy system clock value at the SA when it
            issues the message. Any two SrvReg/SrvDeReg messages from
            the same SA MUST have different Version Timestamps.

3. Fully-meshed Peering DA Architecture

   In SLPv2, there is a many-to-many relationship between DAs and
   service scopes, i.e., a DA can serve multiple scopes and a scope can
   be served by multiple DAs. To enhance SLP DA services and simplify SA
   registrations, mSLP defined a fully-meshed peering DA architecture
   based on service scopes.

   The first part of this architecture is on DA peer relationship
   management. DAs that share service scopes are peers. Peer DAs may
   have exactly the same service scopes or only one scope in common.
   Each pair of peer DAs maintain a single persistent peering connection
   which provides a reliable FIFO channel for their message exchange. In
   other words, there is a set of fully-meshed peering connections among
   peer DAs.



Zhao, et al.            Expires: January 12, 2002               [Page 3]


Internet Draft               DA Interaction                July 12, 2001


   In Figure 1, as DA3 shares service scopes with DA1, DA2 and DA4, it
   maintains peering connections to them and exchanges registration
   updates with them in scope y, y and z, respectively. DA1 and DA2 have
   exactly the same service scopes, they exchange registration updates
   in scope x and y using a single peering connection.

                            +-----------+
                            |  DA4 (z)  |
                            +-----------+
                                  | (z)
   +-----------+     (y)    +-----------+     (y)    +-----------+
   | DA1 (x,y) | ---------- | DA3 (y,z) | ---------- | DA2 (x,y) |
   +-----------+            +-----------+            +-----------+
         |                      (x,y)                      |
         +-------------------------------------------------+

       Figure 1. Fully-meshed Peering Relationships among DAs

   The second part of this architecture is on registration update
   propagation control. Registration updates received by one DA are
   properly propagated to its peers, thus peer DAs maintain the same
   consistent registration states for their common scopes.

   This architecture improves SLP DA services. It avoids a single point
   of failure by replicating data among at least two peer DAs,
   automatically synchronizing data among these DAs. The full mesh
   topology provides maximum robustness. We anticipate that a small
   number of DAs for each service scope is sufficient to achieve high
   reliability; peer sets that are too large are not desirable as they
   significantly increase management overhead. This architecture also
   enables a DA to recover from a crash with much less effort since a
   rebooted DA can get the existing registrations from its peering DA
   set purely through DA coordination, without involving SAs.

   Furthermore, this architecture simplifies SA registrations. In SLPv2,
   an SA needs to register with all existing DAs in its scopes and re-
   register when new DAs are discovered or old DAs are found to have
   rebooted. This places a substantial burden on an SA implementation.
   mSLP provides an alternate and more efficient way for distributing
   registrations, which moves the burden from many SAs to a few DAs. In
   mSLP, a mesh-aware SA only needs to register with sufficient number
   of mesh-enhanced DAs such that the union of their service scopes
   covers its scopes. The registrations will then be propagated
   automatically to other DAs in their scopes.

   In Figure 2, SA1 may choose to register with DA2 only or to register
   with both DA1 and DA3. For compatibility reason, mSLP supports two
   registration models: the original SLPv2 model in which an SA



Zhao, et al.            Expires: January 12, 2002               [Page 4]


Internet Draft               DA Interaction                July 12, 2001


   registers with all DAs and the new model in which a mesh-aware SA
   uses the Mesh Forwarding extension to request that mesh-enhanced DAs
   distribute its registrations. By simplifying SAs, the overall SLP
   system scalability can be improved.

             (x)           +-----------+           (y)
        +----------------- | SA1 (x,y) | -----------------+
        | (option2)        +-----------+        (option2) |
        |                  (x,y) | (option1)              |
   +---------+     (x)     +-----------+     (y)     +---------+
   | DA1 (x) | ----------- | DA2 (x,y) | ----------- | DA3 (y) |
   +---------+             +-----------+             +---------+

      Figure 2. Options for Registration with Mesh-enhanced DAs

   For easy of presentation, we first focus discussion only on mesh-
   enhanced DAs and mesh-aware SAs (Section 4, 5), then address the
   mixed deployment of mesh-enhanced DAs, non-mesh-enhanced DAs, mesh-
   aware SAs and non-mesh-aware SAs, and mSLP compatibility with SLPv2
   (Section 6).

4. Registration Update Propagation Control

   mSLP defined a new SLP message - Data Request, and a new SLP
   extension - Mesh Forwarding for registration update propagation
   control. A mesh-enhanced DA MUST support the Data Request message and
   the Mesh Forwarding extension.

4.1. Accept ID and Propagation Order

   An Accept ID has two components: Accept DA and Accept Timestamp. Each
   registration update has a unique Accept ID, and a registration state
   has the same Accept ID as that of the latest update applied to it.
   The Accept ID is used in the Mesh Forwarding extension and the Data
   Request message. Figure 3 shows 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Accept Timestamp                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Accept Timestamp, cont'd.              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length of Accept DA URL    |         Accept DA URL         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 3. Accept ID




Zhao, et al.            Expires: January 12, 2002               [Page 5]


Internet Draft               DA Interaction                July 12, 2001


   Accept IDs define a total order for all updates accepted by the same
   DA and a partial order for all updates in the system. Thus, Accept
   IDs can be used to propagate registration updates in order.

   In mSLP, a mesh-enhanced DA MUST propagate registration updates in
   the increasing order of their Accept IDs, which means that all
   updates accepted by the same DA MUST be propagated in the increasing
   order of their Accept Timestamps, and updates accepted by different
   DAs MAY be propagated in any orders.

   The ordering propagation enables a receiving DA to represent its
   received registration updates using a State Summary, i.e., up to what
   points (in term of Accept Timestamps) the receiving DA has received
   updates accepted by DAs in its peer set. A State Summary at a DA
   includes all the latest Accept IDs it has received. For example, if
   DAi has a State Summary of ((DA1, T1), (DA2, T2), ..., (DAn, Tn)),
   then it means that DAi has received all registration updates prior to
   timestamp Tj accepted by DAj, where 1<=i,j<=n.

   A direct consequence of the ordering propagation is that when a
   mesh-enhanced DA receives an update propagated from a peer DA, the
   Accept ID of this update MUST be bigger than the corresponding entry
   in its State Summary - if there is no corresponding entry in its
   State Summary, the receiving DA needs to add an entry for this Accept
   DA. If a received update has a smaller Accept ID (this indicates an
   error), the receiving DA SHOULD discard the update.

   The ordering propagation ensures that no update is missed for
   propagation. By using the State Summary, each pair of peer DAs can
   easily determine the difference of their received updates, and
   exchange only new updates, not the whole database, to synchronize
   their registration states whenever they need to catch up registration
   updates with each other (after failure, boot, or reboot).

4.2. Version Timestamp and Registration Version Resolution

   When registrations are propagated among DAs, their arrival timestamps
   at DAs cannot be used for version resolution. For example, assume SA1
   sends a registration (R1) to DA1 first and a new version of the same
   registration (R2) to DA2 later. When R1 and R2 are propagated, the
   arrival timestamp of R1 at DA2 is later than that of R2, but R1
   SHOULD NOT overwrite R2 at DA2 as R2 is a newer version.

   In mSLP, a mesh-enhanced DA MUST use the Version Timestamp for
   registration version resolution. mSLP assumes that each registration
   is updated only by one SA, thus a mesh-enhanced DA doesn't need to
   compare Version Timestamps from two different SAs.




Zhao, et al.            Expires: January 12, 2002               [Page 6]


Internet Draft               DA Interaction                July 12, 2001


   A mesh-enhanced DA installs a registration update if and only if the
   update has a newer Version Timestamp (from a mesh-aware SA) or it
   doesn't have the Mesh Forwarding extension (from a non-mesh-aware
   SA). As incremental registrations and partial deregistrations may
   result in incomplete registration states, especially when updates are
   propagated, a mesh-aware SA MUST use the Mesh Forwarding extension
   with a fresh SrvReg and a complete SrvDeReg only.

4.3. Mesh Forwarding Extension

   The Mesh Forwarding (MeshFwd) extension is used in the
   SrvReg/SrvDeReg message. It carries a Version Timestamp and an Accept
   ID. Its extension ID is 6. Figure 4 shows its format and two defined
   Forward IDs (Fwd-IDs).

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   MeshFwd Extension ID = 6    |  Next Extension Offset (NEO)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | NEO, cont'd.  |     Fwd-ID    |       Version Timestamp       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Version Timestamp                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Version Timestamp, cont'd.  |          Accept ID            \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Fwd-ID         Abbreviation
                       1              RqstFwd
                       2              Fwded

                Figure 4. MeshFwd Extension and its Fwd-IDs

   A mesh-aware SA uses the RqstFwd Mesh Forwarding extension (Fwd-ID =
   RqstFwd, Accept Timestamp = 0) in a SrvReg/SrvDeReg to explicitly
   request a mesh-enhanced DA (the Accept DA) forward the message. In
   other words, a mesh-enhanced DA propagates a registration update from
   an SA if and only if the update has the RqstFwd Mesh Forwarding
   extension.

   A mesh-enhanced DA uses the Fwded Mesh Forwarding extension (Fwd-ID =
   Fwded, Accept Timestamp != 0) in a forwarded SrvReg/SrvDeReg message
   sent from it to another DA.

4.4. Data Request Message

   The Data Request (DataRqst) message carries an Accept ID. Its
   Function-ID is 12. Figure 5 shows its format.



Zhao, et al.            Expires: January 12, 2002               [Page 7]


Internet Draft               DA Interaction                July 12, 2001


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = DataRqst = 12)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Accept ID                           \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 5. DataRqst Message

   The DataRqst message is used by a mesh-enhanced DA to request new
   registration states from a peer. The requested new registration
   states have the same Accept DA as the specified Accept DA in the
   DataRqst message, but have a bigger Accept Timestamp. Note that one
   DataRqst message pulls new registration states of one Accept DA at a
   time; pulling new registration states of all Accept DAs needs to use
   multiple DataRqst messages with different Accept DAs.

   When a mesh-enhanced DA receives a DataRqst from a peer, it SHOULD
   check its State Summary and send the requested new registration
   states it has to the peer in the increasing order of their Accept
   Timestamps (Figure 6). A new registration state is sent as a fresh
   SrvReg with a re-calculated new lifetime computed as its old lifetime
   minus the elapsed time. A newly deleted registration state is
   propagated as a SrvDeReg.

       +-----+                  DataRqst                    +-----+
       |     | -------------------------------------------> |     |
       | DA1 |            (Peering Connection)              | DA2 |
       |     | <------------------------------------------- |     |
       +-----+   New Registration States via Srv(De)Reg(s)  +-----+

         Figure 6. Pulling New Registration States via a DataRqst

   As mSLP uses the fully-meshed peering DA architecture, normally a
   mesh-enhanced DA only needs to pull new registration states directly
   from their Accept DAs. Only when failures occur, it needs to pull new
   registration states indirectly.

   For example, DA1 with scope x and y, DA2 with scope x, and DA3 with
   scope y have already set up peer relationships. Now DA1 crashes, then
   DA4 with scope x and y joins, and DA4 wants to get all existing
   registrations accepted by DA1, DA2, and DA3. DA4 pulls DA2 and DA3
   accepted registrations directly from DA2 and DA3, respectively, but
   pulls DA1 accepted registrations indirectly from DA2 for scope x and
   from DA3 for scope y (Figure 7).





Zhao, et al.            Expires: January 12, 2002               [Page 8]


Internet Draft               DA Interaction                July 12, 2001


                   DA4 ---- DataRqst (DA2, 0) ---> DA2
                   DA4 ---- DataRqst (DA3, 0) ---> DA3
                   DA4 ---- DataRqst (DA1, 0) ---> DA2
                   DA4 ---- DataRqst (DA1, 0) ---> DA3

     Figure 7. Pulling New Registration States Directly and Indirectly

   The DataRqst message is used in the initial population exchange among
   peer DAs. It is also used after failures (DA crashes and network
   partitions) to enable peer DAs to catch up the difference of their
   observed registration updates.

   The DataRqst message enables a lightweight anti-entropy [5, 6] among
   peer DAs. In the traditional anti-entropy, a DA pulls updates of all
   Accept DAs in one round (in this case the DataRqst should carry a
   list of Accept IDs - the State Summary of the sending DA, not only
   one Accept ID), but the DA needs to pull updates from one peer at a
   time, otherwise it will get repeated updates. In mSLP, a DA pulls
   updates of one Accept DA at a time from a peer, thus a newly joined
   (rebooted, or reconnected) DA can directly pull updates from all
   existing peer DAs at the same time without getting repeated updates.
   This data pulling scheme is simple for use, efficient in the normal
   case (no failures) and flexible to support different requirements.

4.5. Propagation Model

   Once a mesh-enhanced DA has sent all new registration updates
   accepted by itself to a peer in answering the peer's DataRqst, it
   starts to direct forward newly received updates from mesh-aware SAs
   to the peer in a push fashion. If any failure occurs in the direct
   forwarding, a mesh-enhanced DA MUST stop the direct forwarding to the
   peer.

   The typical update propagation model from DA1 to DA2 is a loop of the
   following four steps.

     (1) DA1 receives a DataRqst (DA1, TSx) from DA2.
     (2) DA1 sends new states to DA2 in answering DA2's DataRqst.
     (3) DA1 direct forwards DA1 accepted updates to DA2.
     (4) DA1 stops direct forwarding to DA2 if any failure occurs.

4.6. Direct Forwarding

   In Figure 8, when DA1 directly forwards an update from SA1 to DA2, it
   sets the message's Fwd-ID to Fwded and changes the message's Accept
   Timestamp to its arrival timestamp. A direct forwarding is performed
   asynchronously, DA1 can send a SrvAck to SA1 before it gets the
   SrvAck from DA2.



Zhao, et al.            Expires: January 12, 2002               [Page 9]


Internet Draft               DA Interaction                July 12, 2001


   +-----+   RqstFwd Srv(De)Reg   +-----+   Fwded Srv(De)Reg     +-----+
   |     | ---------------------> |     | ---------------------> |     |
   | SA1 |  (Peering Connection)  | DA1 |  (Peering Connection)  | DA2 |
   |     | <--------------------- |     | <--------------------- |     |
   +-----+         SrvAck         +-----+         SrvAck         +-----+

               Figure 8. Direct Forwarding of a SrvReg/SrvDeReg

   Note that the direct forwarding of a registration update only goes
   one-hop from its Accept DA to other DAs in the registration scopes.
   As peer DAs are in a fully connected mesh, the one-hop forwarding is
   sufficient to distribute registration updates rapidly among peer DAs
   when there is no failure.

4.7. SrvDeReg Messages

   When a SrvDeReg arrives, a mesh-enhanced DA needs to mark the
   corresponding service entry in the database as deleted so that the
   entry will not appear in any query reply. However, no matter a
   deregistered service entry exists or not, a mesh-enhanced DA needs to
   retain the SrvDeReg information properly to prevent earlier SrvReg
   messages from mistakenly causing this service entry to reappear in
   the database. A registration state (whether deregistered or not) will
   be purged from the database when it expires.

4.8. SrvAck Messages

   A mesh-enhanced DA MUST properly reply with a SrvAck to a
   SrvReg/SrvDeReg no matter the message is received from an SA or from
   a peer DA. Also, a mesh-enhanced DA MUST properly handle SrvAck
   messages from its peer DAs.

4.9. Control Information for Each Registration URL

   For each registration URL from mesh-aware SAs, a mesh-enhanced DA
   needs to maintain the following control information: the latest
   update (SrvReg or SrvDeReg), Accept ID (for update propagation), and
   Version Timestamp (for registration version resolution - rejecting
   previous updates).

4.10. State Summary for All Received Registrations

   A mesh-enhanced DA needs to maintain a State Summary to reflect its
   received registrations so far. When a SrvReg/SrvDeReg is received
   from an SA or from its Accept DA, a mesh-enhanced DA updates its
   State Summary directly, otherwise, the DA needs to update its State
   Summary on scope basis. Consider the example in Figure 7, when DA4
   receives DA1 accepted registrations from DA2, it updates DA1 latest



Zhao, et al.            Expires: January 12, 2002              [Page 10]


Internet Draft               DA Interaction                July 12, 2001


   Accept Timestamp for scope x, similarly, when DA4 receives DA1
   accepted registrations from DA3, it updates DA1 latest Accept
   Timestamp for scope y. Thus, when pulling new registration states
   form a peer indirectly via a DataRqst, a mesh-enhanced DA needs to
   use a scope-based Accept ID.

5. Peer Relationship Management

   A mesh-enhanced DA maintains a peer table. For each peer, the DA
   needs to keep the peer DAAdvert and a reference to the peering
   connection.

5.1. Learning about a New Peer

   A mesh-enhanced DA can learn about a new peer via static
   configuration, DHCP [4], DAAdvert multicast, solicited DAAdvert
   unicast [1], and unsolicited DAAdvert unicast (Section 5.2, 5.3). In
   any case, a mesh-enhanced DA MUST obtain a DAAdvert from a new peer
   before establishing the peer relationship to it.

5.2. Establishing a Peering Connection

   After a mesh-enhanced DA gets a DAAdvert from a new peer, if there
   does not exist a peering connection to the peer, then it MUST create
   such a connection and send its DAAdvert via the connection (Figure
   9). A mesh-enhanced DA can identify a peering connection initiated by
   a peer by receiving the peer's DAAdvert from the connection.

       +-----+    (1) DA2 DAAdvert  |                   +-----+
       |     | <--------------------+                   |     |
       | DA1 |    (2) Create a Peering Connection       | DA2 |
       |     | ---------------------------------------> |     |
       +-----+    (3) DA1 DAAdvert                      +-----+

             Figure 9. Establishing a Peering Connection

   Normally, only a single peering connection SHOULD be set up between
   two peers. However, there is a small possibility that a pair of such
   connections might be created if two peers try to initiate a
   connection to each other almost at the same time. That is
   inefficient, but it does not affect the correctness.

5.3. Forwarding DAAdvert Messages

   After establishing a new peering connection, a mesh-enhanced DA
   forwards the new peer DAAdvert to its existing peers, and sends a
   DAAdvert for each of its existing peers and the Accept DAs in its
   State Summary to the new peer (Figure 10). The DAAdvert forwarding



Zhao, et al.            Expires: January 12, 2002              [Page 11]


Internet Draft               DA Interaction                July 12, 2001


   enables a DA to learn peers incrementally from its known peers, and
   to know the Accept DA set of the new peer.

       +-----+        DAAdvert(s) of DA1's Peers        +-----+
       |     | ---------------------------------------> |     |
       | DA1 |            (Peering Connection)          | DA2 |
       |     | <--------------------------------------- |     |
       +-----+        DAAdvert(s) of DA2's Peers        +-----+
          |                                                |
          V DA2 DAAdvert                      DA1 DAAdvert V
       +----------------------+        +----------------------+
       | DA1's Existing Peers |        | DA2's Existing Peers |
       +----------------------+        +----------------------+

               Figure 10. Forwarding DAAdvert Messages

5.4. Maintaining a Peer Relationship

   To detect failures (network partitions and peer crashes), mSLP uses a
   heat-beat mechanism. A mesh-enhanced DA SHOULD send its DAAdvert to
   peers (Figure 11) every CONFIG_DA_KEEPALIVE seconds. The timeout
   value for this message is CONFIG_DA_TIMEOUT seconds (Section 8).

       +-----+              DA1 DAAdvert                +-----+
       |     | ---------------------------------------> |     |
       | DA1 |           (Peering Connection)           | DA2 |
       |     | <--------------------------------------- |     |
       +-----+              DA2 DAAdvert                +-----+

             Figure 11. Maintaining a Peer Relationship

5.5. 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 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
   the peer DAAdvert is timeout. To tear down a peer relationship, a
   mesh-enhanced DA removes the peer from its peer table and closes the
   peering connection.

6. Compatibility and Incremental Deployment

   mSLP is fully backward compatible with SLPv2. It defines a new
   attribute ("mesh-enhanced"), a new message type (DataRqst) and a new
   extension (MeshFwd). A mesh-enhanced DA supports extended operations
   without affecting its original functions. Moreover, the changes at
   mesh-enhanced DAs are mostly transparent to UAs and SAs. UAs can be



Zhao, et al.            Expires: January 12, 2002              [Page 12]


Internet Draft               DA Interaction                July 12, 2001


   kept unchanged. SAs can simplify their service registrations by using
   the RqstFwd Mesh Forwarding extension.

   mSLP supports incremental deployment of mesh-enhanced DAs and mesh-
   aware SAs. In a mixed deployment of mesh-enhanced DAs, non-mesh-
   enhanced DAs, mesh-aware SAs and non-mesh-aware SAs, there are six
   types of interactions among DAs and SAs.

      Mesh-enhanced DAs vs. Mesh-enhanced DAs
            A mesh-enhanced DA interacts with other mesh-enhanced DAs as
            described in Section 4 and 5 of this document.

      Mesh-enhanced DAs vs. Mesh-aware SAs
            A mesh-enhanced DA interacts with mesh-aware SAs as
            described in Section 4 of this document.

      Mesh-enhanced DAs vs. Non-mesh-enhanced DAs
            A mesh-enhanced DA MUST establish a TCP connection with
            non-mesh-enhanced DAs in its scopes, and forward newly
            received SrvReg/SrvDeReg messages on behalf of mesh-aware
            SAs to non-mesh-enhanced peers (registrations from non-
            mesh-aware SAs SHOULD not be forwarded). A mesh-enhanced DA
            MUST be prepared for a non-mesh-enhanced peer to drop the
            connection. In this case, the mesh-enhanced DA reopens a TCP
            connection. Note that a mesh-enhanced DA doesn't send the
            DataRqst message, nor DAAdvert messages of other DAs to a
            non-mesh-enhanced peer.

      Mesh-enhanced DAs vs. Non-mesh-aware SAs
            A mesh-enhanced DA operates in the same way as a non-mesh-
            enhanced DA [1] for all non-mesh-aware SAs.

      Mesh-aware SAs vs. Non-mesh-enhanced DAs
            If there are no mesh-enhanced DAs cover its scopes, for
            uncovered scopes, a mesh-aware SA operates in the same way
            as a non-mesh-aware SA [1] to interact with non-mesh-
            enhanced DAs.

      Non-mesh-aware SAs vs. Non-mesh-enhanced DAs
            They operate as described in [1].

   In a mixed deployment of mesh-enhanced DAs and non-mesh-enhanced DAs,
   a mesh-aware SA still needs to take care of newly found and rebooted
   non-mesh-enhanced DAs as these DAs cannot get existing registrations
   from other DAs, therefore, uniform deployment of mesh-enhanced DAs is
   much more desirable than partial deployment.





Zhao, et al.            Expires: January 12, 2002              [Page 13]


Internet Draft               DA Interaction                July 12, 2001


7. Summary

      UA
            It 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 scopes.

      Non-mesh-aware SA
            It needs to discover and register with all DAs in its
            scopes. It does not use the Mesh Forwarding extension.

      Non-mesh-enhanced DA
            It accepts SrvReg/SrvDeReg messages from SAs and mesh-
            enhanced DAs normally. It does not forward them.

      Mesh-aware SA
            It only needs to discover sufficient number of mesh-enhanced
            DAs that cover its scopes. It MUST register with mesh-
            enhanced DAs via the fresh SrvReg and complete SrvDeReg
            messages using the RqstFwd Mesh Forwarding extension.

      Mesh-enhanced DA
            It MUST carry the "mesh-enhanced" attribute keyword in its
            DAAdvert, maintain a peer table, and have peering
            connections to all peers. For each mesh-enhanced peer, the
            DataRqst message MUST be sent AND processed. Also, it
            accepts registrations from SAs and mesh-enhanced DAs,
            propagates registrations in order and processes SrvAck
            messages from mesh-enhanced DAs. Furthermore, it SHOULD
            forward the DAAdvert message from a new peer to its existing
            peers and vice versa.

8. Constants

   Mesh Forwarding Extension ID     6           (Section 4.3)
   Data Request Message Type       12           (Section 4.4)
   CONFIG_DA_KEEPALIVE            200 seconds   (Section 5.4)
   CONFIG_DA_TIMEOUT              300 seconds   (Section 5.4)

9. Security Considerations

   mSLP uses standard SLPv2 authentication. However, the DA and SA
   authentications are more important in mSLP than in original SLP.
   First, a mesh-enhanced DA SHOULD authenticate other DAs before
   setting up a peer relationship with them to prevent any malicious DA
   from joining the meshed DA set. Second, a successful attack at a
   mesh-enhanced DA may affect all DAs in the meshed DA set, a mesh-



Zhao, et al.            Expires: January 12, 2002              [Page 14]


Internet Draft               DA Interaction                July 12, 2001


   enhanced DA SHOULD authenticate SAs before accepting and forwarding
   their SrvReg/SrvDeReg messages to prevent illegitimate modification
   or elimination of service registrations. On the other hand, as a
   mesh-aware SA depends on the mesh-enhanced DA it registers with to
   forward its SrvReg/SrvDeReg messages, it SHOULD authenticate the DA
   to avoid using a malicious mesh-enhanced DA.

10. References

   [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location
       protocol, version 2", RFC 2608, June 1999.

   [2] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)",
       RFC 1771, March 1995.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.

   [4] C. Perkins and E. Guttman, "DHCP options for service location
       protocol", RFC 2610, June, 1999.

   [5] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker,
       H. Sturgis, D. Swinehart and D. Terry, "Epidemic algorithms for
       replicated database maintenance", the sixth ACM symposium on
       principles of distributed computing, Vancouver, Canada, 1987.

   [6] K. Petersen, M. Spreizer, D. Terry, M. Theimer and A. Demers,
       "Flexible update propagation for weakly consistent replication",
       the sixteenth ACM symposium on operating systems principles,
       Saint Malo, France, 1997.

11. Authors' Addresses

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

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




Zhao, et al.            Expires: January 12, 2002              [Page 15]


Internet Draft               DA Interaction                July 12, 2001


12. Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Zhao, et al.            Expires: January 12, 2002              [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/