Subject: Re: [EME] Is this IMS?

From: Scott W Brim <[email-masked]>
Date: Mon, 02 Jul 2007 13:49:32 -0400

On 06/18/2007 15:23 PM, Hannes Tschofenig allegedly wrote:
> When I first read the document then I got the impression that all
> this stuff already exists. I thought that you are replicating the
> 3GPP IMS work (without referencing it). The only difference I saw
> was that backup paths were established but I wasn't quite sure
> whether this is a good idea anyway.
>
> So, what is the new idea about combining SIP (name-based routing)
> with path-coupled signaling?

To the extent I understand it, IMS is a single pass protocol.  There
are several assumptions there ...

  - The CSCFs (application layer control signaling intermediaries)
    have gathered the knowledge to determine the best path for the
    network-layer connection.  In NUTSS the two are loosely coupled,
    but in IMS allowed paths are restricted to the few that the policy
    boxes can keep track of.

  - All policy boxes mutually trust each other.  In the draft, policy
    boxes can be independent.

  - All policy boxes understand everything you are trying to do.  It
    is not a general-purpose signaling mechanism for all kinds of
    traffic, rather it is very specific to the services the IMS
    provides.

NATs and firewalls are not considered as far as I know, except at
domain boundaries where they might use B2BUAs.  If policy signaling
and data path are less tightly coupled, the need to tie application
layer intelligence into a forwarder (as well as routing intelligence
into a policy box) can be lessened.

Finally, the signaling in the draft can be used not only by a network
operator to control traffic over its infrastructure, but also by the
receiving client, in order to exercise finer control over how it deals
with incoming connection requests.

On 06/19/2007 03:13 AM, Hannes Tschofenig allegedly wrote:
> In IMS there is also the option to obtain authorization tokens via
> SIP signaling that are then put into RSVP messages and signaled to
> the middlebox.
> In NSIS we used the same concept (even the same token format) to
> authorize flows, as one option.

First, I am told that that was in IMS R6 but it's deprecated in R7
(now they use a "binding" mechanism instead of a "token" mechanism).
I don't really know what that means.

Second, regarding the scheme in general ... Yes but it's just one auth
token from a single PDF for a particular service in a particular
environment.  Suppose I need an auth token to punch a hole in a NAT
box, another to use a special interconnect for high bandwidth video,
another to demonstrate to the recipient that I am in his "friends"
list, and so on?  Different policies, different trust domains, even
different services.

>> NUTSS has broader goals.  First, it wants to apply to all data
>> flows, not just media.
>
> SIP is not only about the establishment of media traffic. You can
> setup any type of end-to-end communication.

Yes, with a little tweaking.  When I first heard about NUTSS I said to
Paul that if we used SIP we could call it "SIP as a Session Initiation
Protocol".  :-)

>> It wants to be able to steer packets through middleboxes not on the
>> path (as requested either by the ends or by the middle).
>
> You want to use something similar to source routing or QoS routing.
>
> While these type of things make sense for an operator to perform
> traffic engineering it does not make that much sense for an end
> host.

Do I want my traffic to go through the USA or Kyrghyzstan?  But I
think the main benefit of involving the session endpoints is that you
remove the need for linkage between p-boxes.

>>   It tries to encompass a wide range of topologies, including
>>   multi-homed to different domains (and including dealing with the
>>   assymetric paths that often result from this).
> You can accomplish this using other ways as well, such as ICE. ICE
> would allow you to find a working path between the two end points
> but does not require you to select the path it goes through the
> network. From a deployment point of view that's obviously much
> nicer.

Let's reserve comparison with ICE for the meeting in Chicago.

On 06/25/2007 08:48 AM, Hannes Tschofenig allegedly wrote:
>>   In particular, my understanding of
>> NSIS was that it is primarily an on-path approach.
> Well. The concept of path-coupled and path-decoupled is somewhat a
> philosophical question particularly when you consider that NSIS (and
> RSVP) need to interact with other protocols.

I don't understand how it's just philosophical.  Are you saying it
doesn't matter?

_______________________________________________
EME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Jul 2007 15:34:06 +0200

Hi Scott,

thank you for your response. Please find my comments and questions below:

Scott W Brim wrote:
> To the extent I understand it, IMS is a single pass protocol.
It depends what you call "single pass".

>   There
But there are many ways a network operator can traffic engineer their 
own network (at different layers).

>     boxes can be independent.
Why does this assumption exist?

>     traffic, rather it is very specific to the services the IMS
Some EU funded projects have tried to extend the usage to all sorts of 
protocols, for example HTTP.
I really wonder why this is a good idea. It is a massive change but with 
little utility.

> domain boundaries where they might use B2BUAs. 
I don't agree with you. The work that was done on the usage of Diameter 
QoS considers both firewall and NAT traversal.
This is a MIDCOM alike approach rather than a path-coupled approach.

>  If policy signaling

What do you mean by "less tightly coupled"?

> with incoming connection requests.
When you use NATs on the receiving side then you essentially have very 
tight control with any protocol that allows you to interact with the NAT 
anyway.
See the NATFW NSLP, as an example.

> I don't really know what that means.
That's true. The main reason is that it was not simple to implement and 
RSVP never got very far (and is totally unnecessary in that particular 
environment with the assumptions that are being made for the architecture).

> list, and so on?  Different policies, different trust domains, even
There is no restrictions on the number of tokens you can obtain. It is 
just that more than one is somewhat non-practical since you can encode 
the authorization into a single token.

> Yes, with a little tweaking.
What type of tweaking?

>   When I first heard about NUTSS I said to
> Do I want my traffic to go through the USA or Kyrghyzstan? 
The middlebox does not tell you the physical location (in case you care 
for that).
It just tells you IP address X and IP address Y.

>  But I
If you want to setup tunnels or influence routing then you might just 
want to use VPNs, Mobile IP or other tunneling mechanisms where the end 
host has more control.

> I don't understand how it's just philosophical.  Are you saying it

What you call on-path and what you call off-path is often quite 
difficult to judge.
When you want to let signaling packets to follow the data path then 
there is just the question of how close.
Please take a look at 
http://tools.ietf.org/id/draft-hancock-nsis-pds-problem-04.txt

Ciao
Hannes