Subject: [Rserpool] Issues with Rserpool and SLP

From: Qiaobing Xie <[email-masked]>
Date: Wed, 12 Sep 2001 17:52:24 -0500

Hi, all,

Here are some issues I've collected concerning the use of SLP to do
ENRP's job. As Maureen mentioned in her earlier email, we will go
through this list at tomorrow's discussion. If you have additional
issues concerning using SLP, please feel free to add.

-Qiaobing

=============
Architectural issues:

  1. In SLP, the presence of DAs is optional and UAs can direct get
service location information from SAs. This seems not good for Rserpool
since if we want to support this DA-less operation mode, The SAs in the
target pool will have to implement all name service functions in
themselves... this could mean a lot of complications. Therefore, for
Rserpool SLP deployment, DA support should be made mandatory.

  2. Create and define a "rserpool" scope string? and assign this scope
to
all Rserpool PUs, PEs, and DAs. This seems to be the way to separate
Rserpool operations from other SLP usage.

  3. For Rserpool SLP, SAs (i.e, PEs) must not accept multicast or
unicast service requests from UAs (i.e., PUs). This is for the same
reason as issue 1 above.

  4. Randy pointed out there is not namespace data auditing defined in
mSLP, nor namespace recovery procedure defined in case the name space
service cloud is broken into pieces and then re-attached.

Message format issues:

  5. Need major extension to the "Service Location" definition. No
longer URLs. But a list of IP addresses and ports and other attributes
such as load-sharing policy/factor, etc.

  6. Need Rserpool-specific definitions for "Service attributes" (is
ASCII format ok?)

  7. What to do with the Language tag?

  8. SLP messages use binary/ASCII hybrid format. Header is in binary
while payload is mostly in ASCII. This may be because what SLP messages
carry are normally URLs. But with Rserpool this is no longer true,
Rserpool messages mostly dealing with IP addresses. What can be done?

Transport issues:

  9. SLP defines UDP, TCP, multicast as its transport. We will need to
define SLP over SCTP plus multicast.

_______________________________________________
rserpool mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/rserpool

---

From: erik guttman <[email-masked]>
Date: Thu, 13 Sep 2001 14:03:19 +0200

> issues concerning using SLP, please feel free to add.

A couple things I would like to add are:

E1. Confidentiality for name service & discovery requests and replies?

    Do requests and replies in RSERPOOL have to be confidential?
    SLP per se does not allow this.  It could be supported by a 
    lower layer (ie. transport or network layer security).

E2. What are the functions to provide?

    This is the core question we have to answer first.  Looking at
    ENRP, there seem to be the following request/replies

	ENRP message		Function		SLP equivalent (?)
	SERVER_HUNT		ENRP server discovery	DA or SA discovery
	SERVER_HUNT_RESPONSE	ENRP server reply	DAAdvert, SAAdvert
	PEER_PRESENSE		ASAP maintenance?	Reregistration?
							SLP Notification	
 
                                   +---------------+
	TAKEOVER_INITIATE	   |server 2 server|    SLP mesh enhancements
	TAKEOVER_INITIATE_RESPONSE |state synch -  |    (WG last call 2 soon)
	TAKEOVER_PEER_SERVER       |one approach   |
	SERVER_DUMP                |               |
	SERVER_DUMP_RESPONSE       |               |
	PEER_LIST_REQUEST          |               |
	PEER_LIST_RESPONSE         |               |
 	PEER_NAME_TABLE_REQUEST    |               |
	PEER_NAME_TABLE_RESPONSE   |               |
	PEER_NAME_TABLE_UPDATE     |               |
	PEER_NAME_UPDATE           |               |
                                   +---------------+

	REGISTRATION         	Register PE		SrvReg
	REGISTRATION_RESPONSE	Ack			SrvAck
	DEREGISTRATION		Deregister PE		SrvDereg
	DEREGISTRATION_RESPONSE	Ack			SrvAck
	NAME_REQUEST		Poolhandle->PE handle	SrvRqst
	NAME_INFORMATION	Poolhandle->PE handle	SrvRply
	UPDATE_POLICY_VALUE     ASAP PU->ENRP           None (why not as query
value)?
	ENDPOINT_KEEP_ALIVE	ASAP maintenance?	None	
	ENDPOINT_UNREACHABLE	Eager namespace maint.	Proxy deregister?

  Let's make it clear that there are 5 distinct functions:

   1) Bootstrapping (finding servers to resolve names and register PEs)
   2) Resolve service description to pool handle (this is not currently
      discussed in any rserpool doc)
   3) Resolve pool handle to pool element handles (actual locations)
      Allow PUs to get this information efficiently. Keep it up to date.
      Allow PUs to find out changing attributes and availability of PEs.
   4) Register availability of PEs and their current status.
      Deregister PEs when not available.
   5) Maintain distributed state of PE location, load & availability
      between name servers over time.

Specifically which name service functions?  That is what I'm trying to
get at above.
 
If the name service functions are all simple applications of SLP
functions,
why can't SAs perform them as well as DAs?

> to all Rserpool PUs, PEs, and DAs. This seems to be the way to separate

Scopes are for administrative grouping.  That can also be functional
(ie.
by pool function).  The point is that this parameter is used by SLP to
group support functions (like DAs) together with agents (SAs and UAs).
One can assign scopes to DAs for other purposes (like geographically or 
organizationally grouped services of different functions).  In this case
you would need an attribute like 'pool-handle' to group them.

Summary:  Pool handle as
Scope => administrative grouping of SLP agents
Attribute => application grouping of app layer elements

> unicast service requests from UAs (i.e., PUs). This is for the same

Why not?  This is a graceful degredation of service.  Sure, for better
performance, you want a DA.   But if it fails, why can't the system
still function.
 
> service cloud is broken into pieces and then re-attached.

Sure - there is the ability to merge two clouds.  They will update each
other.  The shared state will be the sum of both.  For those that 
conflict (for the same database entry) there will be one authoritative 
version chosen.

But in essense this is one of the biggest challenges:  Determine if
mesh enhancements to SLP are sufficient and beef it up if not.

> such as load-sharing policy/factor, etc.

I agree.  I have been advocating this for a long time on the SVRLOC
list.
SLP should be able to (and its syntax already supports) advertising
services
by persistent unique service ID (URI) instead of by location (URL).

SLP can support any URI.  WE could define the rserpool-pool-handle:
scheme,
for example.  

>   6. Need Rserpool-specific definitions for "Service attributes" (is

Yes!
 
>   7. What to do with the Language tag?

If these are only machine readable attributes (ie. for ASAP
implementations)
then we just define it in English.  If there are human readable strings
in
in the attributes, these may be translated.  This is done in the
templates
registered for SLP.  ASAP would have to have its own way of tagging
strings
it sends.

> Rserpool messages mostly dealing with IP addresses. What can be done?

You can represent IP addresses in URLs (IPv4 and IPv6).  It is also
possible
to represent addresses as hex encodings, or whatever.  Data presentation
is 
not an issue (debate about it is futile since its all the same thing
once its
been decoded.)

> define SLP over SCTP plus multicast.

I totally agree.  

The thing is whatever reliability issues, confidentiality requirements,
etc. we have can potentially be solved by doing SLP over ASAP over
SCTP...

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: [email-masked]
Sr Staff Engineer, Sun Microsystems       Email: [email-masked]
Altrotstrasse 31, D-69190 Walldorf Germany   Mobile: +49 172 865 5497