Subject: RE: [Sipping] Loose Routing Proposal

From: "Stephen Terrill (ERA)" <[email-masked]>
Date: Tue, 11 Sep 2001 15:06:02 +0200

Hi Brian,

One aspect to keep in mind here - is that it might be multi-vender between the "entry proxy" (I-CSCF) and the working proxy (S-CSCF) - hence the need for a standardised interface there (albiet it is within one operators network ....).

There is a tradeoff between the network dynamics created upon "per-session" type of handling - e.g. the load on the network to update the subscribers data etc onto the "working proxy" may be greater than the actual load of processing the SIP signalling - and I guess the moving semistatic would work in a reasonable manner.

It is assumed that the local information remains valid for the lifetime of the registration - or in the case of failure, a re-registration can occur.

Two logical conclusions conclusion come to my mind.  Either the entry proxy performs a database lookup (of which some of the data can be cached) to the entity in 3GPP termined the HSS, which informs the entry proxy to address of the working proxy, or the loose routing vectors are transported to the outgoing proxy by some means.

It was viewed as an advantage to reduce the number of hits to the HSS, hence the solution which moves the loose routing vectors (path) was selected.

Maybe (or hopefully) there is another solution again .... or other points of view?

..//Steve

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, September 10, 2001 5:54 PM
To: 'Juha Heinanen'; Sean Olson (EUS)
Cc: Drage, Keith (Keith); Miguel A. Garcia; 'Cullen Jennings';
[email-masked]
Subject: RE: [Sipping] Loose Routing Proposal

I guess this is the root of my confusion also.
Juha is describing the only way I know to make a
truly scalable/reliable entity - you have
a redundant pair of processors that are the
"entry proxy".  Their ONLY job is to hand off the
work to one processor in a pool of worker processors.
We know that such systems work quite well, and 
specifically, we know that they work with millions
of (http for example) transactions.  The limit to 
scalability is the limit of the entry processor 
to do the dispatch, and the overhead of the extra level 
of indirection.  I can't conceive of any way you could
argue that for 3GPP an entry processor would not
scale far enough.  

It isn't clear to me that the worker processors
have to be official SIP proxy servers -- that is,
the interface between the entry processor and the
worker processor could be proprietary, or it could
be standard SIP; implementation choice.  

3GPP appears to be trying to use a mechanism that
people who think they have discovered a "better way"
to do this often try - they want to distribute the load
semi-dynamically, by assigning worker processors
to UAs at registration.  In my experience, this
rarely works well:
	The reliability model is much less robust
	Load is not usually balanced (in this case
		it is because the number of calls per
		worker processor is not directly
		related to the number of registrations
		because call frequency varies a lot)
	There is too much network knowledge spread
		in the net
Ever bookmark something like: 
"ww6.loser.com/interesting/page.htm"
only to discover that it failed when you came back to it?
Same idea.  

Brian

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 11:33 AM
> To: Sean Olson (EUS)
> Cc: Drage, Keith (Keith); Miguel A. Garcia; Rosen, Brian; 'Cullen
> Jennings'; [email-masked]
> Subject: RE: [Sipping] Loose Routing Proposal
> 
> 
> Sean Olson (EUS) writes:
> 
>  > Because the SRV record for a given domain
>  > tells you almost nothing about the
>  > capabilities for that SIP server, other
>  > than a desired priority and the transport
>  > protocol (UDP, TCP, etc.). The selection
>  > of the home proxy in the 3GPP network may
>  > be based on more complex criteria that are
>  > not easily expressed by a SRV record. The problem
>  > is more similar to the one addressed by SLP.
> 
> right and once the call gets to the home "entry" proxy as 
> identified by
> the srv record, then that "entry" proxy routes the call further to the
> right service proxy based on the information it knows about the
> subcriber that is stored in its subscriber database.  the 
> visited proxy
> doesn't need to and should not know any internal stuff related to the
> organization of the home network.
> 
>  > Furthermore,
>  > the local outbound proxy in this case can
>  > belong to another operator and is not in the
>  > position to make the determination about
>  > which home proxy should be used.  
> 
> right, it just selects the "entry" proxy based on dns srv records.
> 
> -- juha
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Sep 2001 10:13:47 -0400

Steve

I don't really understand the point of separating the entry processor from
the worker processor (separate vendors).  It seems to me that these are
much more appropriately combined into a single logical entity (the
visited network incoming and outgoing proxies and the home network
incoming and outgoing proxies).  You can call them anything you wish.
You would like to be able to use the HA mechanisms available and
coming from a number of vendors that offer just this type of
architecture.  Making a new one is not a good idea.  It's not clear,
for example, that a network connection between the entry processor
and the worker processors is most appropriate.  It might be for
some implementations, it might not for others.  

Standard techniques exist to make sure that the same worker processor
receives all messages for a single transaction.  It doesn't seem to me
that a database lookup per transaction is a large load.  We could make it
per call if it really mattered.  If it was per message, I might be worried. 
The database folks are quite used to supporting HA architectures with
load balancers.  They manage to deal with millions of database lookups
for those systems, I just don't see a performance problem here.
Is there evidence that these architecturs won't work for 3GPP? 

The entry processor would not do any real "database" lookups.  
The point of the entry proxy is to do as little work as possible - it's 
only task is to identify which worker proxy gets the message.
You want to keep as little state in this function as possible, because
you want to share it with its redundant partner.  The database
processors cache the data and supply it to the worker processor.

Brian

> From: Stephen Terrill (ERA) [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2001 9:06 AM
> To: 'Rosen, Brian'; 'Juha Heinanen'
> Cc: Drage, Keith (Keith); 'Cullen Jennings'; [email-masked]
> One aspect to keep in mind here - is that it might be 
> multi-vender between the "entry proxy" (I-CSCF) and the 
> working proxy (S-CSCF) - hence the need for a standardised 
> interface there (albiet it is within one operators network ....).
> 
> There is a tradeoff between the network dynamics created upon 
> "per-session" type of handling - e.g. the load on the network 
> to update the subscribers data etc onto the "working proxy" 
> may be greater than the actual load of processing the SIP 
> signalling - and I guess the moving semistatic would work in 
> a reasonable manner.
> 
> It is assumed that the local information remains valid for 
> the lifetime of the registration - or in the case of failure, 
> a re-registration can occur.
> 
> Two logical conclusions conclusion come to my mind.  Either 
> the entry proxy performs a database lookup (of which some of 
> the data can be cached) to the entity in 3GPP termined the 
> HSS, which informs the entry proxy to address of the working 
> proxy, or the loose routing vectors are transported to the 
> outgoing proxy by some means.
> 
> It was viewed as an advantage to reduce the number of hits to 
> the HSS, hence the solution which moves the loose routing 
> vectors (path) was selected.
>

---

From: "Stephen Terrill (ERA)" <[email-masked]>
Date: Wed, 12 Sep 2001 18:00:47 +0200

Hi Brian,

On the issue of why standardise the interface between the entry processor and the worker processor is that I see a number of entry processors distributed around the entry points to the operators network - and they would all effectively be addressed by the same DNS entries (different DNS results for load distribution and depending on where the query was made from).  so basically, e.g. [email-masked], and [email-masked] etc would resolve to the same entry point names, but may in effect be different boxes.  The next step is that regardless of the entry point to the network, I view it as reasonable to get to the same working processor, and this may be from another vendor .....

I can't offer any information which says that the database look-ups would be excessive - the feedback during the discussions which I saw were mainly that "If we reduce the number of look-ups, then we reduce the amount of silicon required for the databases, and reduce the cost". 

BR,

..//Steve

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, September 11, 2001 4:14 PM
To: 'Stephen Terrill (ERA)'; 'Juha Heinanen'
Cc: Drage, Keith (Keith); 'Cullen Jennings'; [email-masked]
Subject: RE: [Sipping] Loose Routing Proposal

Steve

Brian

---

From: "Stephen Terrill (ERA)" <[email-masked]>
Date: Thu, 13 Sep 2001 10:17:21 +0200

Hi,

If we look at the way 2G systems work, the call control is realised in the visited network with the MSC - the supscription is downloaded to the serving machine in the visited network.  This of course meant either that a service was not really "switched on" until a sufficient number of networks were upgraded, or the subscriber had a different experience in different networks.

As such, having the serving maching in the home network seemed to make more sence as this created more of a relationship between the subscriber and the home network - and personalisation is easier.

Regarding Juhas comments about bi-passing the home network, the only comment that I can make is that to use SIP, a terminal will have an IP connectivity - and that is something which is being deployed now.  Based on that - there is the opportunity to do whatever is possible over IP.

BR,

..//Steve

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, September 12, 2001 9:08 PM
To: Henning G. Schulzrinne
Cc: Juha Heinanen; [email-masked]
Subject: Re: [Sipping] Loose Routing Proposal

The only problem with this architecture is that the 3GPP groups, I thought, 
were going to have the "virtual home environment" operating at the home 
serving node.  If the visited node is to control the features and services 
(e.g. personalized announcements) of the subscriber in the visited network, 
then it must be possible to transfer that logic to the visited system.  An 
assumption is that the user's phone will contain all the logic and data, 
but I'm not sure if the format of the mobile phones (e.g. a powerful enough 
but small battery) will support that.

The alternative is commodotized rather than personalized service.  Thoughts?

Mike

At 02:14 PM 9/12/2001 -0400, Henning G. Schulzrinne wrote:
>Juha Heinanen wrote:
> >
> > yes, the visited network needs to be able to authenticate the caller,
> > but once that has succeeded, the subsciber should have the choice to
> > make a call directly rather than being routed via the "home" network.
>
>Also, I would imagine that the visited network would not have to go back
>to the home network for authentication for every call. If you know that
>[email-masked] is indeed a Telia customer, you don't have to ask two
>minutes later again.
>
>In addition, while off-line or semi-off-line micropayment schemes aren't
>all that popular today, one could imagine that they might catch on. So
>we shouldn't be designing an architecture that imposes unnecessary
>constraints just because today's billing system works a certain way.
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Sep 2001 20:04:38 +0100

But the home network is one end of all additional service provision, and
therefore needs to be involved in the "call". In 3GPP we have moved from
visited network provision of services in the circuit switched environment
(with service privileges indicated by the home network), to home network
provision of services in the IMS SIP environment.

And before you say "who needs services", one of those services is prepay,
and there are an awful lot of operators who like a network centric model for
prepay phones, and an awful large amount of prepay phones out there. Great
for all those who need a phone but are not eligible for credit facilities,
e.g. every person under 18 in the UK.

So the "call" involves the home network, but the "connection" passes
directly from visited network to visited network.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Juha Heinanen[SMTP:[email-masked]]
> Sent: 	12 September 2001 19:01
> To: 	Michael Hammer
> Cc: 	Stephen Terrill (ERA); Drage, Keith (Keith); Miguel A. Garcia;
> Rosen, Brian; 'Cullen Jennings'; [email-masked]

---

From: "Stephen Terrill (ERA)" <[email-masked]>
Date: Mon, 17 Sep 2001 14:24:43 +0200

Hi,

I would extend this a bit, I would say that the segments 1 and 2 really go to/from the UAs, but through the visited network.  This principle way of looking at it could of course be extended to the other segments.

Based on this, I don't understand the motivation of considering another protocol here and having protocol conversion?

..//Steve

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
Sent: Friday, September 14, 2001 4:11 PM
To: Miguel A. Garcia
Cc: Drage, Keith (Keith); [email-masked]
Subject: RE: [Sipping] Loose Routing Proposal

[MAG] The call signaling flows, for users 1 and 2, both roaming, will
comprise the following segments:

1. Visited network 1 -> Home network 1
2. Home network 1 -> Home network 2
3. Home network 2 -> Visited network 2

[RRR] Miquel's call flows (1, 2, 3) are straight forward. Can we have a
generalized solution in SIP for these flows?

[RRR] I guess that there may be an alternative to above flows as well. The
functions of the home network(s) are not the same as those of the visited
networks. That is, the home network(s) will need to supply all information
to the visited network(s) and will not remain in the call signaling path
once its function is completed.

My guess is that visited networks 1 and 2 need to have association so that
they can work directly for call signaling once the function of the home
networks are completed. For example, address resolution, authentication,
authorization, service association, etc. may need to be done in the home
network(s) and the said may need to be passed to the visited network 1 for
establishment of the call.

Will not the call flows look like this as follows?

1. Visited network 1 -> Home network 1 -> Home Network 2 

2. Home Network 2 -> Home Network 1 -> Visited Network 1 

3. Home network 2 -> Visited Network 2

Items 2 and 3 can go on in parallel.

(Now the visited network 1 has all the information [e.g., address resolution
and others] to complete the call directly with visited network 2)

4. Visited network 1 <-> Visited Network 2 (call signaling using SIP)

5. Media directly between Visited network 1 and Visited Network 2

If we agree that the call flows will be like above, items 1 2, and 3 may be
addressed by a separate protocol other than SIP.

Best regards,
Radhika R. Roy
[email-masked]

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 17 Sep 2001 09:58:09 -0400

Steve:

The question is how far we can go in extending a given protocol.

If people can come up with a generalized solution in extending a given
protocol, there is no problem. If a proposal is there, we can look into it.

However, if the address resolution is the main purpose for completion of a
call, a location server is good enough to solve that problem. Again, it is
not a protocol conversion. Similarly, service association and other special
purposes need to be addressed for completion of a call and, no generalized
solution is not found in extending the main  protocol, then what else is
left other than an alternative approach to solve the problem?

Best regards,

Radhika R. Roy
rrroy.att.com

-----Original Message-----
From: Stephen Terrill (ERA) [mailto:[email-masked]]
Sent: Monday, September 17, 2001 8:25 AM
To: Roy, Radhika R, ALCTA
Cc: [email-masked]
Subject: RE: [Sipping] Loose Routing Proposal

Hi,

I would extend this a bit, I would say that the segments 1 and 2 really go
to/from the UAs, but through the visited network.  This principle way of
looking at it could of course be extended to the other segments.

Based on this, I don't understand the motivation of considering another
protocol here and having protocol conversion?

..//Steve

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
Sent: Friday, September 14, 2001 4:11 PM
To: Miguel A. Garcia
Cc: Drage, Keith (Keith); [email-masked]
Subject: RE: [Sipping] Loose Routing Proposal

Best regards,
Radhika R. Roy
[email-masked]

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 17 Sep 2001 11:50:54 -0400

> generalized solution in SIP for these flows?

[MAG] SIP offers a general solution for 2 and 3 above. However, to my
knowledge, SIP does not offer a solution for 1. I personally call 1 
"routing or caller", because proxy severs use the caller to route the
call to the caller's home network.

[RRR] So, it appears that there is no generalized solution in SIP that
includes 1, 2, and 3.

> once its function is completed.

[MAG] No, home networks don't need to suply any informationt to the visited.
Particularly, services are executed in the home network. You don't need to
transfer any logic from home to visited. This is the main reason whay we
are doing all this staff.

On the other hand, there might be other reasons why the visited network
wants to stay in the path for future requests, for instace, if the visited
network is controlling the cost of the call by time or something similar, 
it may realy on the reception of a BYE. There might be other reasons as
well.

[RRR] It appears that the visited network 1 will be controlling the call.
So, the home network (1 or 2) needs to send the authentication to the
visited network 1, at least, I believe. So, the question is: How do we find
a generalized solution in SIP for call flows that include 1, 2, and 3? If
not, can we not separate the problem in two parts: 1. Non-SIP-based and 2.
SIP-based?

> establishment of the call.

[MAG] Yes, these activities are done in the home network. To my knowledge,
there
is not reason to pass any other information to the visited network.

[RRR] Even not the authentication? Will not visited network 1 be controlling
the call?