IETF Logo Mail Archive

Re: [multimob] Summary from multimob session @ IETF71

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 27 March 2008 11:17 UTC

Return-Path: <multimob-bounces@ietf.org>
X-Original-To: ietfarch-multimob-archive@core3.amsl.com
Delivered-To: ietfarch-multimob-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4B63A6FCB; Thu, 27 Mar 2008 04:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.645
X-Spam-Level:
X-Spam-Status: No, score=-100.645 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 vYD+9VDDqn0y; Thu, 27 Mar 2008 04:17:46 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E621428C8C2; Thu, 27 Mar 2008 04:17:37 -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 F011F3A6FCB for <multimob@core3.amsl.com>; Thu, 27 Mar 2008 04:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 21EicricRpeD for <multimob@core3.amsl.com>; Thu, 27 Mar 2008 04:17:34 -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 690BB3A6FD7 for <multimob@ietf.org>; Thu, 27 Mar 2008 04:17:26 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from [141.22.26.203] by mail2.rz.fhtw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1Jeq4X-000Bcp-NN; Thu, 27 Mar 2008 12:15:05 +0100
Message-ID: <47EB81BB.4040801@informatik.haw-hamburg.de>
Date: Thu, 27 Mar 2008 12:15:07 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
References: <623942.11346.qm@web84309.mail.re1.yahoo.com> <20080327.122746.11606627.asaeda@sfc.wide.ad.jp>
In-Reply-To: <20080327.122746.11606627.asaeda@sfc.wide.ad.jp>
Cc: multimob@ietf.org
Subject: Re: [multimob] Summary from multimob session @ IETF71
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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: multimob-bounces@ietf.org
Errors-To: multimob-bounces@ietf.org

Hi Hitoshi,

Hitoshi Asaeda wrote:
> 
>> ====> Thomas points out that light weight MLD actually does not address 
>> primary multicast issues such as leave latency, but that explicit 
>> tracking does. Explicit tracking is foreseen as an option in MLDv2.
> 
> LW-MLDv2 does not aim to minimize join/leave latency. The main aim of
> this protocol is to reduce the protocol and implementation
> complexities by eliminating (usually) unneeded functions.
> 
Yes, this we tried to clarify ... as you weren't there and the 
discussion somehow brought up the wrong context.

>> ====> Thomas points out that an important multicast proxy function  may 
>> be a pro-active/on-hold subscription (without traffic forwarding). While 
>> operators configure such "listener proxies" manually today, an automated 
>> management will required protocol implementation, e.g., as an MLD 
>> extension.
> 
> Thomas, could you explain more about what this comment means?
> 
This is mechanism is a (subscription-) proxy function used at relays 
already today. A multicast relay maintains a group subscription without 
forwarding traffic, e.g., down a wireless link to assist a fast 
forwarding in case a listener for that group arrives on the link / in 
the domain.

This mechanism is described in the section "5.2.4 MLD Extensions" of the 
problem statement
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

and a protocol realization in the form of an MLD extension is given in 
section "4.5 Router attendance control in MLD" of the M-HMIPv6 draft

http://tools.ietf.org/html/draft-schmidt-waehlisch-mhmipv6

Could I make things clearer, now?

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-8157
° http://www.informatik.haw-hamburg.de/~schmidt
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

v2.23.0 | Report a Bug | By Email