Subject: Re: [IPTEL] TRIP for gateways

From: James Kempf <[email-masked]>
Date: Tue, 21 Nov 2000 09:22:13 -0800 (PST)

Jonathan,

I'm not on this list, so please cc me in any correspondence. Somebody
forwarded me your comments on using SLP for intradomain gateway
discovery, and I would like to correct a couple of misimpressions.

Specifically:

>Another issue raised was that SLP appeared more appropriate than TRIP, as
>this was a service advertisement issue (specifically, the gateway would send
>out SLP service advertisement messages to the LS). 

No agent in SLP "sends out" unsolicited service advertisements, with
the exception of the Directory Agent (DA). In a properly configured
network, there are very few DAs and a DA should only send unsolicited 
advertisements with a periodicity on the order of hours, if not days. An 
application that wants a service solicits the advertisements in one of two ways:

1) If there are no DAs, the application multicasts, and the services answer with 
their service URL using unicast.

2) If there is a DA, the application unicasts the request to the DA,
which then replies by unicast.

So there is no SLP traffic (and thus no network load) unless an application is 
looking for a service.

>I don't think SLP is
>really quite right here. For example, in SLP, service advertisements need to
>be refreshed by resending the service template. This would mean that a
>gateway would need to periodically resend its entire routing table. 

This is completely false. The service template is never sent anywhere,
it is like the LDAP schema, it merely describes the form of a service
advertisement for a particular service type. A DA can use service templates to 
check whether a service advertisement registered by a service matches, and 
reject it if not. In practice, service templates are not now used by any SLPv2 
implementations with which I am familar. Their exact use is somewhat 
underspecified. This was actually by design, since we did not know exactly 
whether strong type checking (such as LDAP uses) was desirable or not.
In retrospect, from most of the applications we've seen to date, weak
type checking seems like a better solution, so the service type
template is nothing more than a convention (but an important one).

>Seems
>inefficient compared to the much smaller keepalive in TRIP. The smaller
>keepalive means that it can be sent more often, resulting in a much more
>rapid failure detection.
>

Actually, it's MORE efficient. There is absolutely NO keepalive in SLP.
It is only when a query is made that a response is given.

I'm not entirely familiar with your application, but, on the surface,
it sounds to me that SLP would be an entirely appropriate way of
discovering a gateway on an intradomain basis. The kinds of applications
in which it is not the right solution generally involve interdomain
discovery (in which traffic over the Internet is involved) or when
the attributes of a service change rapidly or don't lend themselves
well to being encoded as a finite list of attribute value pairs. In
addition, if there is any service-specific negotation involved in
selecting the service, then a service-specific discovery protocol
may be a better solution.

		jak

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 01:53:29 -0500

James,

I apologize for my errors in describing the application of SLP to this
problem. My description was sloppy. That aside, the usage of it is different
than you are talking about below. So, let me first describe the usage.

We are interested in  a PUSH protocol that pushes gateway reachability
information, along with attributes from a specific type of server (a PSTN
gateway), to an entity called a location server (LS). Note that there are
never queries for this service. Calls arrive at this location server, and
the data learned from the gateway is used to route the call. Mapping this to
SLP, the gateway is a service agent (SA). The LS is a directory agent (DA).
However, its a "lame duck" directory agent, in that there are never any
service queries from  any SLP user agents. Rather, a SIP INVITE arrives at
the DA, and the cached service registrations are searched to find the best
one for the call. The criteria for the search are not specified in the SIP
INVITE, but rather through local policy.

Now, we have a requirement here that these service registrations are always
very fresh. If the gateway dies, within seconds we want the cached
information in the LS (aka DA) to be expired. This requires a lifetime in
the service registration on the order of seconds. With TRIP, all thats sent
is a small keepalive. I don't think that there is an equivalent here in SLP;
I believe that the SA needs to re-register before the expiration. What I'm
not sure about is whether you can use incremental service registrations to
avoid resending all your service attributes. 

The second issue is that representation of the data that characterizes a
gateway using SLP seems non-trivial. A gateway has many telephone number
prefixes (each of which is called a route) it can route calls to, and
associated with each prefix is a set of attributes, like preference, cost,
or whatever. Now, you can go two ways with an SLP mapping. You can map each
route as a service in its own right, or the set of routes becomes an
attribute of the gateway service. In the former case, changes to the
availability of specific routes is easy, but the efficiency of having to
re-register each route is bad. In the latter case, the re-registrations are
more efficient, but modification of the route set (like removing a route) is
hard, even using the incremental registration feature in SLPv2.

Hopefully this makes more sense now.

Thoughts?

-Jonathan R.

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 12:22 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [IPTEL] TRIP for gateways
> 
> 
> Jonathan,
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: James Kempf <[email-masked]>
Date: Wed, 22 Nov 2000 10:57:21 -0800 (PST)

Hi Jonathan,

>than you are talking about below. So, let me first describe the usage.

No problem.

>INVITE, but rather through local policy.

I'm curious why you need to have the gateway push the reachability info
to the location server. Why can't the location server pull it from the
gateway?

In this scenario, the location server acts as a user agent and the
gateway acts as the service agent. The service advertisement consists
of the PSTN gateway's attributes and reachability info (as I understand
it from below, telephone prefixes). The location server periodically
performs an SLP SrvRqst for gateway service URLs, then performs an
SLP AttrRqst for the attributes. Alternatively, the location server
can include the SLP attribute list extension (see 
draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
delivered along with the service URL.

>information in the LS (aka DA) to be expired. This requires a lifetime in

The minimum granularity of the SLP advertisement lifetimes is one second.

>I believe that the SA needs to re-register before the expiration. 

Yes, but by the scenario above, the location server would need to query
when the lifetime of its gateway advertisements ran out. The gateway
would also need to reregister periodically when the registration ran out,
if a DA was present. If no DA was present, there would be no need
for reregistration.

>What I'm

Yes, you can do incremental SrvReg. This would allow the gateway to 
just send its service URL to refresh the registration. A SrvReg is only needed, 
however, if a DA is present. The location server would also need to periodically
resend a SrvRqst when the advertisment's lifetime ran out. 

Not having a DA would eliminate the requirement for a SrvReg. In this
case, the location server locates the gateway initially using multicast SrvRqst,
then afterwards sends the SrvRqst directly to the gateway using unicast.
If the gateway fails to respond, the location server knows it has gone down.
That would reduce the amount of messaging for the keepalive to one
SrvRqst and one SrvRply. The gateway maintains its own attributes and
doesn't need to send them to the DA.

>route as a service in its own right, 

This would proliferate the number of service URLs, and therefore the number
of potential network connections, so probably not a good idea.

>or the set of routes becomes an

I think SLPv2 incremental registration and deregistration could handle
updating the route set.

What I think would be more of a concern is how to set up the attributes
so that particular sets of routes are associated with particular sets
of attributes. There are a number of ways I can think of to do this,
some of them involve having attribute tags that vary according to
the route type. We'd need to talk in more detail about this, particularly
about the kinds of queries that could be expected, to come up with
a definitive design. It's essentially a data modelling problem.

>Hopefully this makes more sense now.

Yes, thanx!

>Thoughts?

Overall, I think your application is not something that can be easily handled
by SLP, but with careful design work, it could probably be handled. There are 
still open questions about push v.s. pull and about the data model for the 
attributes. If you or anyone else in the IPTEL
group wants to pursue this, I'll be happy to talk with you in
San Diego or exchange further email. The real question is whether
the group is interested in trying to reuse an existing protocol,
with perhaps some design challenges, or whether there is more interest
in pursuing a custom protocol for this specific application.
At least, that's how I see it. 

		jak

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Nov 2000 02:20:15 -0500

> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 1:57 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IPTEL] TRIP for gateways
> 
> 

Indeed, the fundamental question is push vs. pull.

I think gateway routing needs to be push primarily for performance reasons.
Calls arrive at a proxy server at potentially very high rates; if each call
needs to generate an independent query for service, you end up (1) adding
latency to each call setup for the query/response, (2) introducing a serious
processing burden for all devices, (3) add a lot of network traffic for the
queries and responses. By pushing the information as it changes, we
eliminate the additional call setup latency, reduce the processing load, and
reduce the messaging load. 

-Jonathan R.
---

---

From: Reinaldo Penno Filho <[email-masked]>
Date: Thu, 30 Nov 2000 07:11:59 -0800

I would have to agree that trying to decide push or pull at this time is
kind of premature. Probably in the end of the day we would have to specify
both methods and operational experience will prove which one is better and
in what conditions. What we could do to guarantee interoperability is say
one is MUST and the other SHOULD. 

Reinaldo Penno
NortelNetworks
[email-masked]

-----Original Message-----
From: Matt Holdrege
To: Jonathan Rosenberg
Cc: 'James Kempf'; [email-masked]; [email-masked]
Sent: 11/30/00 6:52 AM
Subject: RE: [IPTEL] TRIP for gateways

>reduce the messaging load.

You forgot to add the management aspect of push which could be a 
significant barrier in large and/or complex networks. I think we have to
be 
able to pull and it is really the decision of the carrier architect. 
Hopefully we can somehow allow both methods for flexibility. I know that
is 
not generally good for interoperability though.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Nov 2000 10:24:29 -0500

Could you expand on this Matt?  I don't get it.

I thought the discussion here was for gateway location WITHIN a network.
TRIP as is does the internetworking stuff.  In that environment,
what are the management reasons?  Seems to me that the BGP-like
push approach is exactly what you want for a large complex network.

Brian

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 9:53 AM
> To: Jonathan Rosenberg
> significant barrier in large and/or complex networks. I think 
> we have to be 
> Hopefully we can somehow allow both methods for flexibility. 
> I know that is

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 30 Nov 2000 12:35:54 -0800

All of Jonathan's reasons for push are quite valid. But in large complex 
networks when you push, the pusher doesn't always know about all the 
roadbumps and policy variations in the field. Indeed when ISP's started 
using BGP they went through hell dealing with these issues. Some still do 
today. And some prefer to have manual control of the process which is 
essentially the same as pulling.

I'm sure if we think about it we can advocate the push method while 
allowing for some to pull in the information. But I don't know what bearing 
this has on SLP which is what we were originally talking about in this thread.

---

From: Sharath Rajasekar <[email-masked]>
Date: Thu, 30 Nov 2000 12:30:41 -0800

Hi,

I agree that a pull model for this *may* be feasible considering the load
balancing and so on but this solution as I see it will only be effective
within a single (dns) domain. Wouldnt a question of scalability arise if the
pull model were to be extended to LSs spanning multiple domains ? That is,
to solve the problem of publishing reachibility information of all gateways
serviced by say
a service provider atwww.foo.com domain. What happens when a service
provider is servicing several domains and subdomains, and has to keep track
of how many gateways etc are around in each domain ?

Is it not possible to have a system of pull within a domain wherein a LS can
pull all necessary gateway reachibility information from within a domain and

push between/among domains ?

Sharath Rajasekar

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, November 30, 2000 11:09 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [IPTEL] TRIP for gateways

Jonathan,

>reduce the messaging load. 

In a pull model, I don't think that each call needs to necessarily cause
an independent query for services.

If each service advertisment contains a lease or timeout, then the
proxy server only needs to redo its query when the advertisement expires.
The granularity will determine what the messaging load and processing
load is, and needs to be set so that it reflects a realistic apprasial
of how often the external reachability information will change.

Of course the probability of getting stale information is higher with a pull

model if the lifetimes are set too long,  so the tendency in situations
where 
the service information changes dynamically is to decrease the lifetime,
upping 
the processing load. 

If what you are trying to do is distribute routing information, then
something like a routing protocol that does push seems like it might
be the better approach, since any failure of freshness pretty much
invalidates the information. However, if what you are trying to
do is locate suitable gateway servers based on where they
can get you to, then perhaps a service discovery approach based on pull
seems 
like it would be more appropriate if the gateway servers' reachability
service 
doesn't change often.

		jak
		
PS: Incidently, we have been working on a push protocol for SLP, to
allow a service client to subscribe to notifications of changes
in particular services. We are slowly moving the draft to Experimental.
The specification is in draft-kempf-srvloc-notify-04.txt. The design
pays particular attention to scalability issues, since we wanted
to avoid problems with network overload such as occured with 
Netware 4.0 SAP and at least one implementation of SLPv1 that was not
in compliance with RFC 2165.