Subject: [Rserpool] Updates needed to ASAP/ENRP

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Jul 2001 09:08:01 -0500

Dear All:

Ok, I am now just beginning to get the list of items
we have discussed doing over the past year or so to
ASAP/ENRP... Here is what I have so far:

1) Message reformats. We wanted to move to a TLVish type
   structure for both ASAP and ENRP.

2) We need to define the inter-check/summing  methods that
   ENRP servers use to valadiate there cache. This is an
   item Q and I have done before but we did not document.

3) We may need to clearify the ENRP reload procedures when
   we have a sum/mis-match between two servers.

4) We need to expand beyond the current multicast only and
   have the document better incorperate DNS and manual
   configuration. We may need to work on integrating SLP
   here... I want to talk a bit more to Erik on this in
   London.

5) We need to expand the server pooling policies

6) We need to add security into the protocol a number of things
   come to mind:

  a) There are three basic levels of security.
     - Completely open, I don't care who comes and goes.
     - Open for query but you must authenticate/encrypt for
registration/de-reg
     - All access subject to encryption/authentication.

  b) We can use HIP and or TLS as easy methods for inserting
     encrypted security between the transport and ASAP/ENRP.

7) Origininally we had in ASAP a "business card" concept. Where when
   I talk to a PE, there is a "first" message that comes ahead of
   any application message that identifies the failover preference... a
   sort of "death wish list" .. if I die contact these peers in this
   order. We also used it to send when I first start talking to a PE
   from the PU any name the sending PU may be registered under. This
allows
   the receiver i.e. the PE to send back to a pool element handle as
well.
  
   The trick with this is you must have a way to tell that it is
   an ASAP message. Normally the exchange between a PE and PU is just
   whatever the application wants it to be. There is no framing or
   message wrapping. The receiving ASAP layer would have to check
   the first 8 bytes of the inbound message to see if it recognizes
   the 'ENRP endpoint message identifier'. Based on this it can figure
   out if it is a business card..  or just a user message it can
   safely pass up. This makes ASAP in a PE<->PU sense extremely 
   lightweight. But it does provide for some overhead when a message
   arrives and is not from your ENRP server... 

   Question: Do we think this is a valuable feature.. or should
   we just drop it?

8) Do we want to add a auto-deregistration time. I.e. have the
   ability to specify a time in say seconds where you will
   automatically be de-registered. Now we do have the current
   ASAP layer sending a periodic registration. This helps with
   overload situations and provides a method to do load deflection.
   i.e. enough PU's report a PE has unreachable due to timeout. It
   is deregistered.. but it is really just real real busy and can't
   respond. The reporter deflects to another server... later when
   our busy server gets un-busy it registers allowing more traffic
   to use it... 
 
   I am not convinced that an auto-de-reg is that useful but I
   am not against it totally. As long as we recognize we do want
   to have the ability to get out of the registered name space but
   still continue serving requests from clients that had transactions
   running with us. This allows a graceful shutdown.

9) Does the WG feel we need to have ENRP servers be able to balance
   out there load? Currently you end up with a home ENRP server
somewhere.
   Do we need to provide a method to balance this out a bit? allowing
   say an ENRP server to tell a registering peer, ok, but use this guy
   over there has your home... or for that matter.. re-vector the
   guy to his new home aka register over here please.

10) Transport protocols. Right now ASAP/ENRP uses only SCTP by design.
This
    is not hard to change since we use IP addresses and ports... UDP or
TCP
    could also easily be used... UDP may prove a bit more intersting ...
does
    the WG want this???

Well thats all I can think of off the top of my head... I will go
read HIP while I see if the WG is silent or responds at all :)

I think the first order of business is to do <1> and reshape the
messages.
We need to get these stable before we get in to some of the other
issues.
I will start working on this (based on feedback) after I get through
HIP... 

I have -01 started now with Maureens and Karl's comments... any
preference by the WG as to if they want a clean -01 with M/K's comments
and then a -02 to have the restructure of the messages or should
I just put the new message formats into -01??

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: [email-masked]
Date: Sun, 29 Jul 2001 23:02:29 +0300

Hi Randy,

>     This is not hard to change since we use IP addresses and 
>     ports... UDP or TCP could also easily be used... UDP may prove a bit 
>     more intersting ... does the WG want this???

As I understand, usage of UDP is now being de-emphasized, especially for 
signaling, within the Transport Area.  I think it has to do with 
no congestion control within UDP.  I'd suggest we stick with SCTP
for now - and contemplate if TCP needs to be supported for
legacy issues.

best regards,
John