Re: [multimob] PMIPv6 extension for multicast

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Wed, 20 July 2011 01:58 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77111E80A4 for <multimob@ietfa.amsl.com>; Tue, 19 Jul 2011 18:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.096
X-Spam-Level:
X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyniocyYzODv for <multimob@ietfa.amsl.com>; Tue, 19 Jul 2011 18:58:14 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D230D11E80A2 for <multimob@ietf.org>; Tue, 19 Jul 2011 18:58:14 -0700 (PDT)
Received: from localhost (p3151-ipngn1501hodogaya.kanagawa.ocn.ne.jp [114.166.86.151]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E5689278091; Wed, 20 Jul 2011 10:57:41 +0900 (JST)
Date: Wed, 20 Jul 2011 10:57:41 +0900
Message-Id: <20110720.105741.120440517.asaeda@sfc.wide.ad.jp>
To: sarikaya@ieee.org, behcetsarikaya@yahoo.com
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <1311088325.90824.YahooMailRC@web111406.mail.gq1.yahoo.com>
References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <20110719.110313.182753311.asaeda@sfc.wide.ad.jp> <1311088325.90824.YahooMailRC@web111406.mail.gq1.yahoo.com>
X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: multimob@ietf.org
Subject: Re: [multimob] PMIPv6 extension for multicast
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 20 Jul 2011 01:58:15 -0000

Hi Behcet,

>> > We revised our PMIPv6 extension draft as follows:
>> > 
>> >  http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06
>> > 
>> This document addresses the tunnel convergence problem by an  RPF
>> lookup algorithm. Although the approach is straightforward,  this
>> condition assumes both MAG and LMA act as PIM-SM routers.
> 
> In Section 3.2 you have:
> 
> The MAG selects only one upstream link for a multicast channel by
> the Reverse Path Forwarding (RPF) algorithm even if the MAG has
> established multiple  M-Tunnels to LMAs.  This does not cause the
> tunnel convergence problem, because duplicate packets are not
> forwarded to the MAG. This means that MAG does not send any new
> joins to the same group upstream, right?

Right.

> I agree that it would solve the problem but does it create new
> problems, like what happens if the member MN leaves the group and no
> more data can be received while other MNs possibly wanted to continue.

MAG maintains the membership state with MLD.
It is mentioned in section 6 and section 8.1.
For instance, section 8.1 says;

  "If p-MAG thinks that the moving mobile node is the last member of
   multicast channel(s), p-MAG confirms it by sending IGMP/MLD query.
   After the confirmation, p-MAG leaves the channel(s) by sending the
   PIM Prune message to its upstream router."

Well, IGMP is not relevant here, so I'll remove the word "IGMP" from
this sentence in the revised version, though.

>> The proposed  mechanism aims to be flexible and general; it could
>> cooperate with other fast  handover mechanism. As one of the examples,
>> this document refers the idea of  CXTP with multicast extension (*1)
>> and illustrates the scenario to cooperate  with it.
>> (*1) draft-vonhugo-multimob-cxtp-extension-00.txt
> 
> I am confused here.
> If we use draft-vonhugo-multimob-cxtp-extension then the handover in
> Section 8 would not be needed? Is the technique in
> draft-vonhugo-multimob-cxtp-extension stand alone and would achieve
> fast handover by itself or not?

Our draft proposes three possible ways for handover; 1) Policy Profile,
2) PBU-M/PBA-M, and 3) CXTP extension. Either one can be used.
And the above CXTP draft is a stand alone solution as it potentially
also works with other approaches.

Regards,
--
Hitoshi Asaeda