Subject: Re: draft-zhao-slp-da-interaction-05.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 16 Jun 2000 13:38:29 +0200 (MET DST)

Weibin,

Note to those on the mailing list - the draft has not yet appeared in
the i-d directories, so I am attaching it to this email.

There are some subtleties I think we need to work out.  How does the
exchange of Peer_DA_Indication work?  How can subsequent discovered
DAs (by one DA on the mesh) be discovered by others on the mesh?  If
the newly discovered DA is mesh-enhanced, it will find out about the
others, when it exchanges DAAdverts with the 'already-meshed' DA.  But
if the new DA is not mesh-enhanced, the other DAs need to know about
it.  

I present two solutions - one based on your idea, one going a little
further.  Note that my second solution solves a lot of other potential
problems:
 
  What if a DA reboots with a different scope list?
  What if a DA reboots after being upgraded to have mesh-enhancements?
  What if a DA reboots statelessly?

>      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   |    <DA-1 IP> ... <DA-N IP>    \
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Upon receiving a "Peer_DA_Indication" DAAdvert
>   message, a mesh-enhanced DA checks the DA list in the message. This
>   DA list can be empty. The number of IP addresses in the list can be
>   determined by (Extension_Length - 6)/4 for IPv4.  

There are problems here.  

 - IPv6 DA addresses can't be transmitted
 - (Extension_Length - 6)/4 won't work, since 0 addresses = 1.5 (1)
   3 addresses would be length 18 bytes/4 = 4.5 = 4, etc.  You have
   to count the fact there are 6 bytes before the DA address list.

I suggest you do have the following 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           /      
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Advantages:

 - If Number of DA URLs is 0, you can stop parsing.
 - DA URLs are the normal way of passing DA locations around
 - DA URLs can represent DAs with IPv4 or IPv6 addresses or domain 
   names.
 - The format is consistent with the way SLP passes strings, etc.
   around.
 - Lengths are explicit for each field, as per normal SLP messages.
   (Much less chance of non-interoperable calculations of length).

Disadvantages:

 - This is a longer format.  This shouldn't matter since the extension
   will be sent on the end of a DAAdvert *using TCP* so there is no
   worry that it will blow the path MTU (1400 bytes) and overflow.
 - This could be considered more complicated to parse.  This is not
   much worse and it leverages DAAdvert parsing/processing code which
   already exists.
 
---------------------------------------------------------------------------

>   If a new peer is
>   found in the list, the mesh-enhanced DA will set up a peer
>   relationship with it.

I think this must be said stronger and clearer:

  When a mesh enhanced DA recieves a Peer_DA_Indication's DA list, it MUST
  check all DA URLs.  If there are any which are not yet known, the mesh
  enhanced DA MUST unicast an active DA discovery service request to the 
  listed DA, to obtain a DAAdvert from it.  If the new DA is mesh enhanced, 
  the mesh enhanced DA MUST establish a peering TCP connection with it.

  Example:  

  Initially mesh enhanced DAs A and B have peering connections, as do D 
  and E.  A also knows about C (not mesh enhanced) and D knows about F 
  (also not mesh enhanced).

       [DA 'A']                                           [DA 'D']
          |                                                  |
       [DA 'B']                                           [DA 'E']

       [DA 'C']                                           [DA 'F']

  DA 'A' discovers DA 'D' and sends a Peer_Conn_Indication to it.  They
  then exchange Peer_DA_Indication messages.

       [DA 'A']                                           [DA 'D']
                   [Action-ID = Peer-Conn-Indication]
                --------------DAAdvert (TCP)------------>

                  [Action-ID = Peer-DA-Indication=E,F]
                <--------------DAAdvert (TCP)------------

                  [Action-ID = Peer-DA-Indication=B,C]
                --------------DAAdvert (TCP)------------>

  DA 'A' determines that it does not know about DAs 'E' and 'F'.  It 
  sends DA discovery requests to those DAs.

                (Service Type = "service:directory-agent")
        [DA 'A'] --------------SrvRqst (UDP)------------> [DA 'E']
                 
                 <-------------DAAdvert (UDP)------------
                           [attr = mesh-enhanced]

                (Service Type = "service:directory-agent")
                 --------------SrvRqst (UDP)------------> [DA 'F']

                 <-------------DAAdvert (UDP)------------

  DA 'A' now knows that DA 'E' is mesh-enhanced and DA 'F' is not.
  DA 'A' establishes a peer connection with 'E' and puts DA 'F' on
  its forwarding list.  

  Similarly, DA 'D' will discover that DA 'B' is mesh-enhanced, 
  and establish a peer connection with it.  

                              [DA 'A'] --- [DA 'D']
                                 |   \\  //  |
                                 |    \\//   |
                                 |     XX    |
                                 |    //\\   |
                                 |   //  \\  |
                              [DA 'B']    [DA 'E']

  Now DA pairs 'A'-'E', and 'B'-'D' will exchange DA URL lists.
  'B' will discover 'E' and 'E' will discover 'B.'  DAs 'E' and 
  'B' will send SrvRqst messages and obtain each other's DAAdverts.
  They will then proceed to form a peer connection.

  The final state will be as follows:
         
                              [DA 'A'] --- [DA 'D']
                                 |   \    /  |
                                 |    \  /   |
                                 |     XX    |
                                 |    /  \   |
                                 |   /    \  |
                              [DA 'B'] --- [DA 'E']

  In addition, each DA knows that DAs 'C' and 'F' are non-mesh-enhanced
  DAs which they have to forward SrvReg and SrvDeReg messages to.

  In the future, a new DA may be discovered by any DA on the mesh.  In
  that case there are two possibilities.  

    (1) The new DA is mesh-enhanced.  

        In this case, the already meshed DA simply exchanges DAAdverts 
        as described above and the new DA will discover all DAs on the 
        mesh and establish peer connections with them.  

    (2) The new DA is not mesh-enhanced.

        The mesh-enhanced DA (call it mDA) must propogate information 
        through the mesh concerning the location of the new DA (call it
        new-non-mesh-DA).  mDA sends a DAAdvert with a Mesh-Enhancement
        Extension with the Action-ID = Peer_DA_Indication to all other
        DAs on the mesh.  All mesh enhanced DAs MUST be prepared to
        receive such a message at any time.  If they do receive it, and
        do not yet know about all DAs in the Peer_DA_Indication, they
        MUST send SrvRqst messages to solicit DAAdverts from the DAs
        they have not yet discovered.

---------------------------------------------------------------------------

Another issue, which we have not discussed or considered, but its very
important, is rebooting DAs either on the mesh or outside it.

Consider the following:

       DA 'a' ... DA 'b' ---- DA 'c'

 1. DA b and c are meshed.  DA 'a' is not mesh-enhanced.  

 2. Only DA 'b' can hear the multicast adverts from 'a.'  
    'a' comes up and advertises.
    'b' sends 'c' the location of 'a'

 3. 'c' solicits its DAAdvert.

 4. Now 'c' knows to forward SrvReg and SrvDeReg messages to 'a'.  

 5. 'a' reboots and comes up without state.  

 6. 'b' recognizes this (by noting the 'a's DAAdvert timestamp 
    indicates a reboot.)
 
 7. 'b' should inform 'c' that 'a' is *new* but it can't since
    'c' already *knows about* 'a'!

There is no mechanism by which 'b' can inform 'c' that it has to 
obtain a new DAAdvert from 'a'.

One way we could fix this, and simplify the entire protocol is to 
include not DA locations in the Mesh-Enhancement Extension, but
rather DAAdverts in their entirety.  The advantages to this are:

 1. DAs already have code to process DAAdverts
 2. DAAdverts can contain authentication, so they can be forwarded
    'securely' just like service registrations & deregistrations
 3. no further communication is required
    one can immediately examine the other DA's
       scope list (has it -gulp- changed?)
       boot time (has it rebooted?)
       attribute list (does it have mesh enhancement?)
 4. It is *really* easy to store DAAdvert messages (in their entirety)
    and forward them.  No message parsing (out) is required.

This makes everything a lot simpler!

      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 DAAdverts      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           DAAdvert #1                         /      
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   . . .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           DAAdvert #N                         /      
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The text suggested above can now read:

  When a mesh enhanced DA recieves a Peer_DA_Indication's DA list, it MUST
  check all DAAdverts.  (1) Does the DA support the same scopes as the
  receiving DA?  (2) Is the new DA mesh enhanced? (check the DAAdvert
  attribute list.  (3) Has the DA rebooted without state? (Consult the
  DAAdvert's "DA Stateless Boot Timestamp" field.)  If it has, and the
  new DA is not mesh-enhanced, service registrations MUST be forwarded
  to it in the scopes of the new DA.

  If there are any DAAdvertss included in the Mesh-Enhancement Extension
  which are for DAs which are not yet known, the mesh-enhanced DA MUST 
  establish a peering TCP connection with it.

  Example:  

  Initially mesh-enhanced DAs A and B have peering connections, as do D 
  and E.  A also knows about C (not mesh-enhanced) and D knows about F 
  (also not mesh-enhanced).

       [DA 'A']                                           [DA 'D']
          |                                                  |
       [DA 'B']                                           [DA 'E']

       [DA 'C']                                           [DA 'F']

  DA 'A' discovers DA 'D' and sends a DAAdvert with a Mesh Enhancement
  Extension whose Action-Id is set to Peer_Conn_Indication to it.
  'A' and 'D' then exchange DAAdverts with Peer_DA_Indication messages.

       [DA 'A']                                           [DA 'D']
                   [Action-ID = Peer-Conn-Indication]
                --------------DAAdvert (TCP)------------>

            [Action-ID = Peer-DA-Indication=DAAdverts for E,F]
                <--------------DAAdvert (TCP)------------

            [Action-ID = Peer-DA-Indication=DAAdverts for B,C]
                --------------DAAdvert (TCP)------------>

  DA 'A' now knows that DA 'E' is mesh-enhanced and DA 'F' is not.
  DA 'A' establishes a peer connection with 'E' and puts DA 'F' on
  its forwarding list.  

  Similarly, DA 'D' will discover that DA 'B' is mesh-enhanced, 
  and establish a peer connection with it.  

                              [DA 'A'] --- [DA 'D']
                                 |   \\  //  |
                                 |    \\//   |
                                 |     XX    |
                                 |    //\\   |
                                 |   //  \\  |
                              [DA 'B']    [DA 'E']

  Now DA pairs 'A'-'E', and 'B'-'D' will exchange DAAdvert lists.
  'B' will discover 'E' and 'E' will discover 'B.'  They will then
  proceed to form a peer connection.

  The final state will be as follows:
         
                              [DA 'A'] --- [DA 'D']
                                 |   \    /  |
                                 |    \  /   |
                                 |     XX    |
                                 |    /  \   |
                                 |   /    \  |
                              [DA 'B'] --- [DA 'E']

  In addition, each DA knows that DAs 'C' and 'F' are non-mesh-enhanced
  DAs which they have to forward SrvReg and SrvDeReg messages to.

  In the future, a new DA may be discovered by any DA on the mesh.  In
  that case there are two possibilities.  

    (1) The new DA is mesh-enhanced.  

        In this case, the already meshed DA simply exchanges DAAdverts 
        as described above and the new DA will discover all DAs on the 
        mesh and establish peer connections with them.  

    (2) The new DA is not mesh-enhanced.

        The mesh-enhanced DA (call it mDA) must propogate information 
        through the mesh concerning the location of the new DA (call it
        new-non-mesh-DA).  mDA sends a DAAdvert with a Mesh-Enhancement
        Extension with the Action-ID = Peer_DA_Indication to all other
        DAs on the mesh.  All mesh enhanced DAs MUST be prepared to
        receive such a message at any time.  If they do receive it, and
        do not yet know about all DAs in the Peer_DA_Indication, they
        MUST send SrvRqst messages to solicit DAAdverts from the DAs
        they have not yet discovered.  

---------------------------------------------------------------------------

This spec is starting to get longer (as they often do :-)  
It might help for clarity and focus to present a list of requirements
at the end.

  Requirements for UAs:

    A UA MAY prefer to use a DA which advertises that it is mesh-
    enhanced to a DA which is not mesh-enhanced since it is more likely
    to reliably contain the complete set of current service registrations
    for the UA's scope.

  Requirements for SAs:

    A SA MAY send a Mesh Enhancement Extension with the Action-ID
    set to 'Mesh_Forward_Rqst' with SrvReg and SrvDeReg messages.
    (Section ).

    If a SA detects a mesh-enhanced DA in any scope, it MAY register
    with that DA (and that DA alone) instead of with *all* DAs in that
    scope.  (Section ).

  Requirements for DAs:

    A DA MAY be mesh enhanced. If it is, the following requirements apply:

      1.  DAAdverts MUST include the 'mesh-enhanced' keyword in their
          attribute lists. (Section )

      2.  A list of mesh-enhanced DAs sharing any of the DA's scopes 
          must be kept.  Peer connections to  all of them must be 
          established (Section 5.1) and maintained (Section  5.2).

      3.  A list of non-mesh-enhanced DAs sharing any of the DA's scopes
          must be kept. (Section 5.1).

      4.  When a new DA is discovered, a DA MUST send a DAAdvert with a
          Mesh Enhancement Extension whose Action-ID is set to 
          Peer-Conn-Indication, and contains all DAAdverts known,
          to all other DAs on the mesh.  Mesh-enhanced DAs MUST be
          prepared to receive such messages at any time.  (Section <new>).

      5.  When a mesh enhanced DA receives a SrvReg or SrvDeReg with
          a Mesh Enhancement Extension whose Action-ID is set to 
          Mesh_Forward_Rqst, it must forward the de/registration.  
          The message is sent to all DAs on the mesh and to all DAs 
          in the non-mesh-enhanced forwarding list whose scope list 
          matches any of the scopes in the Srv(De)Reg message.  (Section 6).

Erik

INTERNET DRAFT                                            Weibin Zhao
Service Location Group                            Henning Schulzrinne
draft-zhao-slp-da-interaction-05.txt              Columbia University
Expires: December 19, 2000                              June 19, 2000

             mSLP - Mesh-enhanced Service Location Protocol
                  draft-zhao-slp-da-interaction-05.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
   Agents (SAs), and answering queries from User Agents (UAs). They
   exist to enhance the performance and scalability of SLP.

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 1]

Internet Draft               DA Interaction                June 19, 2000

   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 the implementation of service
   registration for a thin-client SA. 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
                document.  A mesh-enhanced DA MUST carry the "mesh-
                enhanced" attribute in its DAAdvert messages.

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 2]

Internet Draft               DA Interaction                June 19, 2000

      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

   Figure 4 shows DA advertisements which are multicast periodically.

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 3]

Internet Draft               DA Interaction                June 19, 2000

   +----+                              +-------+
   |    |                              |       |
   | 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 DA list in the form of IP addresses.
   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   |    <DA-1 IP> ... <DA-N IP>    \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 4]

Internet Draft               DA Interaction                June 19, 2000

   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 a DA list that
   the receiving DA SHOULD peer with.

   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 peer relationship has three stages: setting up, keeping and tearing
   down. We describe each stage in detail next.

5.1. Setting Up a Peer Relationship

   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.  Figure 6 illustrates the DAAdvert
   messages from mesh-enhanced DAs.

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

         Figure 6. Mesh-enhanced DA Advertisement

   A mesh-enhanced DA MUST maintain a peer list.  It adds an entry to
   the list whenever it discovers a new peer, and removes an entry when
   it finds the corresponding peer is down.  Each entry in this peer
   list SHOULD include peer URL, shared scopes, boot timestamp, and
   peering TCP connection ID.  The boot timestamp is to identify a
   rebooted peer. The peering TCP connection is used for message
   forwarding.

   When a mesh-enhanced DA learns about a new peer, it MUST create a

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 5]

Internet Draft               DA Interaction                June 19, 2000

   peering TCP connection to the peer at the port 427 if such connection
   does not yet exist. Then it sends a "Peer_Conn_Indication" DAAdvert
   message (We mean the message has the mesh-enhancement extension with
   Action-ID = Peer_Conn_Indication. Similar notation is used in the
   rest of this document.) through this channel to inform the receiving
   DA that this is a peering TCP connection (Figure 7). Thus, the
   receiving DA can also use this channel to forward messages in the
   opposite direction.

   +-----+                                            +-----+
   |     |     [Action-ID = Peer_Conn_Indication]     |     |
   | DA1 | <------------ DAAdvert (TCP) ------------- | DA2 |
   |     |                                            |     |
   +-----+                                            +-----+

            Figure 7. Peering Connection Indication

   When a mesh-enhanced DA receives a "Peer_Conn_Indication" DAAdvert
   message, it sends a "Peer_DA_Indication" DAAdvert message carrying a
   DA list that the receiving DA SHOULD peer with (Figure 8). 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 the DAs in the sending DA's peer list that share some
   service scopes with the receiving DA.  Similarly, when a mesh-
   enhanced DA receives a "Peer_DA_Indication" DAAdvert message, it
   replies with a "Peer_DA_Indication" DAAdvert message if it has NOT
   sent this type of message to this peer.  In other words, a mesh-
   enhanced DA sends a "Peer_DA_Indication" DAAdvert message to each of
   its peers once and only once.  By exchanging the peer information
   through "Peer_DA_Indication" DAAdvert messages, 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).  Upon receiving a "Peer_DA_Indication" DAAdvert
   message, a mesh-enhanced DA checks the DA list in the message. This
   DA list can be empty. The number of IP addresses in the list can be
   determined by (Extension_Length - 6)/4 for IPv4.  If a new peer is
   found in the list, the mesh-enhanced DA will set up a peer
   relationship with it.

   +-----+     [Action-ID = Peer_DA_Indication]       +-----+
   |     | ------------- DAAdvert (TCP) ------------> |     |
   | DA1 |                                            | DA2 |
   |     | <------------ DAAdvert (TCP) ------------- |     |
   +-----+     [Action-ID = Peer_DA_Indication]       +-----+

            Figure 8. Exchanging Peer DA Information

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 6]

Internet Draft               DA Interaction                June 19, 2000

   After the peering TCP connection is established or identified, peer
   DAs begin to forward new service registration information to each
   other via this channel. At the same time, a mesh-enhanced DA SHOULD
   decide whether it needs to get the data from 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
   the three DAs, but not from all of them, which incurs a lot of
   redundant transmissions. (Note: How to choose a DA 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.)  To obtain
   the existing data, the new DA sends a "Data_Dump_Rqst" DAAdvert
   message to the chosen peer (Figure 9).  At the other end, 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.

   +-----+    [Action-ID = Data_Dump_Rqst]    +-----+
   |     | --------- DAAdvert (TCP) --------> |     |
   | DA1 |                                    | DA2 |
   |     | <--------- SrvReg (TCP) ---------- |     |
   +-----+       (data of shared scopes)      +-----+

                 Figure 9. Dumping Data

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
   connection alive, a mesh-enhanced DA SHOULD send a
   "Peer_Conn_Keepalive" DAAdvert message via the channel every
   CONFIG_DA_KEEPALIVE (see Section 9) seconds (Figure 10).

   +-----+                                           +-----+
   |     |                                           |     |
   | DA1 | ------------ DAAdvert (TCP) ------------> | DA2 |
   |     |    [Action-ID = Peer_Conn_Keepalive]      |     |
   +-----+                                           +-----+

                     Figure 10. DA Keepalive

5.3. Tearing Down a Peer Relationship

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 7]

Internet Draft               DA Interaction                June 19, 2000

   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

   During the peering period, peer DAs forward new service registration
   information from SAs to each other. The message 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 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 that a
   message can reach all peer DAs. Figure 11 shows how a SrvReg/SrvDeReg
   message is forwarded.

              [Action-ID =
   +----+   Mesh_Forward_Rqst]  +-----+ [Action-ID = 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.

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 8]

Internet Draft               DA Interaction                June 19, 2000

7. Design Discussion

   In this section, we discuss several important design issues.

7.1 Meshed Peering TCP Connections

   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

W. Zhao, H. Schulzrinne      Expires: December 19, 2000         [Page 9]

Internet Draft               DA Interaction                June 19, 2000

   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
   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 can set up peer relationships with both mesh-enhanced DAs
   and non-mesh-enhanced DAs. In the latter case, the message forwarding
   only goes in uni-direction from the mesh-enhanced DA to a non-mesh-
   enhanced DA.  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.

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

   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 the mesh-
       enhancement extension (Action-ID = 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.

W. Zhao, H. Schulzrinne      Expires: December 19, 2000        [Page 10]

Internet Draft               DA Interaction                June 19, 2000

   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
       It carries the "mesh-enhanced" attribute in its DAAdvert
       messages.  It accepts SrvReg and SrvDeReg messages from SAs and
       mesh-enhanced DAs.  It forwards the messages from mesh-aware SAs
       to all peer DAs (both mesh-enhanced and non-mesh-enhanced) in the
       registration scope.  It also processes SrvAck messages from
       mesh-enhanced DAs.

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

   The DA authentication is more important in mSLP, since mesh-aware SAs
   will have to trust the mesh-enhanced DA they are sending the SrvReg
   and SrvDeReg messages 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
   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

11. Acknowledgments

   Erik Guttman provided valuable comments and suggestions for this
   draft.

12. Authors' Addresses

W. Zhao, H. Schulzrinne      Expires: December 19, 2000        [Page 11]

Internet Draft               DA Interaction                June 19, 2000

   Weibin Zhao
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003
   email: [email-masked]

   Henning Schulzrinne
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027-7003
   email: [email-masked]

W. Zhao, H. Schulzrinne      Expires: December 19, 2000        [Page 12]

---

From: Weibin Zhao <[email-masked]>
Date: Fri, 16 Jun 2000 09:37:31 -0400 (EDT)

Hi Erik,

The 6 bytes before the DA address list has been considered. That is
why the formular is (Extension_Lenght - 6)/4. More precisely, the 
Extension_Lenght refers to the lenght of mesh-enhancement extension.
Therefore, for 0 address, the Extension_Lenght is 6, (6-6)/4 = 0;
for 3 addresses, the Extension_Lenght is 18, (18-6)/4 = 3.

I agree that using URL for DA list is good for both IPv4 and IPv6. Another
choice is to add a flag before the DA list to label IPv4 or IPv6 address.

I will get to your other questions later. Thanks.

-Weibin