Re: [EME] Is this IMS?

Scott W Brim <swb@employees.org> Mon, 02 July 2007 17:50 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Q2y-0002S1-TG; Mon, 02 Jul 2007 13:50:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Q2x-0002Gs-Du for eme@irtf.org; Mon, 02 Jul 2007 13:50:47 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Q2p-0001tc-1d for eme@irtf.org; Mon, 02 Jul 2007 13:50:47 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jul 2007 13:50:34 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAGvXiEZAZnmf/2dsb2JhbAA
X-IronPort-AV: i="4.16,487,1175486400"; d="scan'208"; a="64186023:sNHT30388560"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62HoYbH017069; Mon, 2 Jul 2007 13:50:34 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l62HoLsC023523; Mon, 2 Jul 2007 17:50:34 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 13:50:22 -0400
Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 13:50:22 -0400
Message-ID: <46893AAC.8090605@employees.org>
Date: Mon, 02 Jul 2007 13:49:32 -0400
From: Scott W Brim <swb@employees.org>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: [EME] Is this IMS?
References: <E6F7A586E0A3F94D921755964F6BE006C9800E@EXCHANGE2.cs.cornell.edu> <4676DBC1.9060201@gmx.net>
In-Reply-To: <4676DBC1.9060201@gmx.net>
X-Enigmail-Version: 0.95.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Jul 2007 17:50:22.0313 (UTC) FILETIME=[7659C590:01C7BCD1]
Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: eme@irtf.org
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

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
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme