Subject: wg last call results for mSLP

From: Erik Guttman <[email-masked]>
Date: Tue, 29 Aug 2000 18:31:31 +0200 (MET DST)

Weibin, Henning,

We got through the WG last call with only 3 comments.  One's trivial,
another is hard and the last is easy, but requires a pretty significant
change to the spec.  None of these effectively change the protocol at 
all - except the wire format.

I include suggestions for how to respond each of the last call issues.

Let's make the change and then go back to WG last call.

Jim - since you requested the changes, can you look over my suggestions
to see if they satisfy your concerns?

Thanks,

Erik

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

(1) Spelling

   Non-mesh-enhanced DA

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

dose -> does

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

(2) UA request forwarding

Jim Kempf <[email-masked]> wrote:

>> 10) The discussion of using a mesh-enhanced DA to allow a DA to manage
>> access to other DAs is confusing. We actually do this in the Solaris
>> slpd, so I understand what you are talking about, but I think this
>> discussion should either be included as part of the standard or removed
>> from the paper. 
>

I don't have a copy of the ID with me, but there is a discussion at
the end of the paper about UAs using a DA to get access to the
URLs of other DAs that are not in the scope of the DA. I think either
this should be incorporated into the standard or dropped from the paper.

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

What Jim means by his comment, I take it, is that we don't explain how
this would work.  Why would a UA send a request to a DA which isn't in
its scope in the first place?  

Here is the problem.  The UA requests a DA in scope X using multicast
discovery.  A mesh-enhanced DA (with scope not-X) receives the request.
This DA has discovered (or has been configured with) another DA which
supports scope X.  Should the mesh-enhanced DA respond to the DA discovery
request from the client?  This is problematic since it would be better
if the UA used DA configured with scope Y rather than sending its request
through the mesh-enhanced DA.  The only time that it is best for the UA 
to use the mesh-enhanced DA is when it can't discover the DA with scope X.
In this case, it can get to that DA through the mesh-enhanced DA - which
is better than multicast requests to SAs.

I'm not sure how to proceed here.  Alternatives are:

 1. drop 7.4
 2. require UAs to be staticly or DHCP configured with mesh enhanced DAs 
    to do forwarding of requests
 3. include mesh-enhancement extension in the UA request be sent to a DA
    of *any scope*.  That DA will then either forward to a DA on behalf
    of the UA (with the scope of the request) or MULTICAST the request on
    behalf of the UA in case there are no DAs in that scope. This is actually
    a really useful feature for nodes using mobile IP.  In this case, the host
    can use multicast discovery without originating the multicast itself!
    In some networks, a host will be on a remote link which doesn't support
    multicast routing and still want to discover services in another part of
    the network which may not have a fully deployed set of DAs for every
    scope.

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

(3) Eliminate the use of mesh enhancement extensions to DAAdverts for the 
    purpose of mesh control.

This was suggested to me by Jim Kempf and it is a really good idea.  Since
mSLP will go standards track now, we can modify the base protocol and we
should add the function correctly.  I include all the changes needed in the
mSLP in order to support this function.

All I've really done is replace the DAAdvert mesh control messages with
a new message type 'MeshCtl.'  I made sure all the text refers to this
correctly.

'<-' means remove this text
'>' means keep this text - taken directly from draft-07
unquoted text is new and should be added

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

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

We define a new SLP extension - "mesh-enhancement extension" for
SLP agents specifying extended operations with mesh-enhanced DAs.
This extension has a five-byte extension header, and a one-byte field
denoted as "Action-ID".  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           \
<     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   The Action-ID is used to specify the requested operations from the
   receiving DA.

>           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
>   receiving DA forward the message to all DAs (both mesh-enhanced and
>   non-mesh-enhanced) in the registration scope.

Mesh-enhanced DA support the new message type:  Mesh Control (MeshCtl)
whose Function-ID is 12.  The format of this message is given in Figure
6.

      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 = MeshCtl = 12)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Action ID   |        Number of DA URLs      |Len of DA URL#1|        
  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            DA URL #1                          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   . . . 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Length of DA URL # N     |           DA URL # N          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Action IDs defined for this message are defined in Table 2:

           Action-ID       Abbreviation

               0           No_Action
               2           Data_Dump_Rqst
               3           Peer_Conn_Indication
               4           Peer_DA_Indication
               5           Peer_Conn_Keepalive

         Table 2. Actions in Mesh-Control Message

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

>   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_DA_Indication: peer DAs indication. It carries the DA list in the 
form of URLs. The receiving DA SHOULD peer with all DAs in this list.
The DA who sends this URL MUST at least include its own URL in the 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 indicates 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

SAs and non-mesh-aware SAs coexist.  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
>
>   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 can 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 (it has a mesh-enhancement
<-  extension with the Action-ID set to "Peer_Conn_Indication"; similar
<-  notations are used in the rest of this document) through the
<-  connection to mark it as the peering TCP connection (Figure 7).

"Peer_Conn_Indication" MeshCtl message (the Action-ID of the MeshCtl
message is set to "Peer_Conn_Indication"; this notation is used in
the rest of the document).  This marks this connection as a peering
TCP connection (Figure 7).

>   (2) Peer DAs Indication: After sending the "Peer_Conn_Indication"
<-  DAAdvert message, the mesh-enhanced DA sends a "Peer_DA_Indication"

MeshCtl message, the mesh-enhanced DA sends a "Peer_DA_Indication"

<-  DAAdvert message through the peering TCP connection (Figure 7). This

MeshCtl message over 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.

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

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

      Figure 7. Peering Connection and Peer DAs Indication

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

"Peer_Conn_Indication" and "Peer_DA_Indication" MeshCtl messages?

<-  When a mesh-enhanced DA receives a "Peer_Conn_Indication" DAAdvert

When a mesh-enhanced DA receives a "Peer_Conn_Indication" MeshCtl

>   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

the same time), and reply with a "Peer_DA_Indication" MeshCtl

>   message (Figure 7). By exchanging the peer information through
<-  "Peer_DA_Indication" DAAdvert messages, the mesh-enhanced DAs can

"Peer_DA_Indication" MeshCtl 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 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.

      <3> DA2 sends "Peer_Conn_Indication" MeshCtl message to DA1.
      <4> DA2 sends "Peer_DA_Indication" MeshCtl message to DA1.
      <5> DA1 sends "Peer_DA_Indication" MeshCtl message 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

   When a mesh-enhanced DA receives a "Peer_DA_Indication" MeshCtl

>   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

at minimum 1 (the DA MUST include its own URL).  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

MeshCtl message (Figure 7), and DA3 is NOT in DA2's peer list, DA2

>   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

(3) Getting Data: After sending the "Peer_DA_Indication" MeshCtl

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

MeshCtl message to the peer (Figure 9).

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

   +-----+     "Data_Dump_Rqst" MeshCtl       +-----+
   |     | -------------- (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, such as the nearest DA or the most
>   lightly loaded DA, can also be used for the selection. 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

"Data_Dump_Rqst" MeshCtl 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
>   connection alive, a mesh-enhanced DA SHOULD send a
<-  "Peer_Conn_Keepalive" DAAdvert message via the channel every

"Peer_Conn_Keepalive" MeshCtl message via the channel every

>   CONFIG_DA_KEEPALIVE (see Section 8) seconds (Figure 10).
>
<-   +-----+                                          +-----+
<-   |     |                                          |     |
<-   | DA1 | ---------------- (TCP) ----------------> | DA2 |
<-   |     |      "Peer_Conn_Keepalive" DAAdvert      |     |
<-   +-----+                                          +-----+

   +-----+                                          +-----+
   |     |                                          |     |
   | DA1 | ---------------- (TCP) ----------------> | DA2 |
   |     |      "Peer_Conn_Keepalive" MeshCtl       |     |
   +-----+                                          +-----+
>                     Figure 10. DA Keepalive