Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 23 October 2008 08:16 UTC

Return-Path: <multimob-bounces@ietf.org>
X-Original-To: multimob-archive@optimus.ietf.org
Delivered-To: ietfarch-multimob-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19E83A6C25; Thu, 23 Oct 2008 01:16:18 -0700 (PDT)
X-Original-To: multimob@core3.amsl.com
Delivered-To: multimob@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF133A6C21 for <multimob@core3.amsl.com>; Thu, 23 Oct 2008 01:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level:
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGdpNBS9mFga for <multimob@core3.amsl.com>; Thu, 23 Oct 2008 01:16:16 -0700 (PDT)
Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D09603A6C26 for <multimob@ietf.org>; Thu, 23 Oct 2008 01:15:20 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from e178169063.adsl.alicedsl.de ([85.178.169.63] helo=[192.168.178.20]) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1KsvMl-000LTj-5i; Thu, 23 Oct 2008 10:16:23 +0200
Message-ID: <490032CA.1040809@informatik.haw-hamburg.de>
Date: Thu, 23 Oct 2008 10:16:10 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Behcet Sarikaya <sarikaya@ieee.org>
References: <881583.21711.qm@web38802.mail.mud.yahoo.com>
In-Reply-To: <881583.21711.qm@web38802.mail.mud.yahoo.com>
Cc: multimob@ietf.org
Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

Hi Behcet,

Behcet Sarikaya wrote:

> It is not exactly clear why you state "Figure 2 depicts local routing
> as something totally different" ??? -
> what is expressed here: a content source local to the PMIP-domain - but
> not local to a particular MAP.
> 
> [behcet] In PMIP6 there is no MAP. You mean MAG here?

[thomas] Yes, sorry for the misprint.
> 
> And in consequence a (multicast) routing
>   within the PMIP domain without LMA-MAG tunneling. That's what the text
> says, as well.
> 
> [behcet] In PMIP6, the nodes between MAG and LMA do not matter because 
> all traffic is tunneled.

[thomas] except for the local routing option as described in section 
6.10.3 of RFC 5213. Here a local routing is foreseen between two unicast 
nodes on the same access link.

> Local routing in Fig. 2 would refer to a packet sent from MN1 to MN2 
> being routed by MAG1 locally without tunneling it to LMA1.
> If the packet MN1 sends is a multicast packet, RFC 5213 does not 
> describe how such a packet would be routed. Is this what you are trying 
> to address?
> 
[thomas] RFC5213 does not address multicast routing (that's why we are 
discussing it). The scenario described in fig 2 is *not* addressing 
mobile multicast senders, but a typical content distribution setting as 
for instance used in a provider-centric IPTV service. This means, a 
provider issues multicast streams from within his network domain, aiming 
at an efficient way to preserve (his own) network resources.

 From the minimal perspective of RFC5213 (unicast routing) there is no 
efficient way to do this. That's why we are trying to identify protocol 
extensions that smoothly cooperate with RFC 5213.

Best regards,

Thomas


-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg, Germany
° Fon: +49-40-42875-8452, Fax: -8409
° http://www.informatik.haw-hamburg.de/~schmidt
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob