Re: [EME] Is this IMS?

Scott W Brim <> Mon, 02 July 2007 17:50 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1I5Q2y-0002S1-TG; Mon, 02 Jul 2007 13:50:48 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1I5Q2x-0002Gs-Du for; Mon, 02 Jul 2007 13:50:47 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1I5Q2p-0001tc-1d for; Mon, 02 Jul 2007 13:50:47 -0400
Received: from ([]) by 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 ( []) by (8.12.11/8.12.11) with ESMTP id l62HoYbH017069; Mon, 2 Jul 2007 13:50:34 -0400
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id l62HoLsC023523; Mon, 2 Jul 2007 17:50:34 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 13:50:22 -0400
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 13:50:22 -0400
Message-ID: <>
Date: Mon, 02 Jul 2007 13:49:32 -0400
From: Scott W Brim <>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070604 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Hannes Tschofenig <>
Subject: Re: [EME] Is this IMS?
References: <> <>
In-Reply-To: <>
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;; dkim=neutral
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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

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