From Dirk.von-Hugo@telekom.de Wed Feb 11 06:24:55 2009 Return-Path: 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 A85CD3A68ED for ; Wed, 11 Feb 2009 06:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 52vojQLq+7Cp for ; Wed, 11 Feb 2009 06:24:54 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id D67143A680B for ; Wed, 11 Feb 2009 06:24:53 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 11 Feb 2009 15:24:55 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 15:24:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98C54.823609E0" Date: Wed, 11 Feb 2009 15:24:54 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC80278489EA702@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <428980.61634.qm@web111416.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Simulation Results for Multicast deployment in PMIPv6 thread-index: Acl7F8rzP/aGowkMRp+ktMWoHnSkXQROJ//A References: <493D7E97.5060400@innovationslab.net> <428980.61634.qm@web111416.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 11 Feb 2009 14:24:55.0331 (UTC) FILETIME=[829E1730:01C98C54] Cc: guanjian8632@163.com Subject: Re: [multimob] Simulation Results for Multicast deployment in PMIPv6 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:24:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98C54.823609E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, sorry for my late reply: I was not sure on whether we decided to proceed on the aspect of optimising a PMIP Multicast solution as could be seen as the approach proposed by Tony and colleagues with simulation and draft-zhang-netlmm-pmipv6-mcast. If so we may try to update the draft expiring in March before next IETF. On the other hand the simulations also show that both methods (i.e. MAG and LMA based) HO delay increase with ratio of one-hop delay (wireless/wired) - this would even be more pronounciated in case all MAGs were interconnected also by wireless links, right? Another more general question would be whether also simulations are availaible which describe end-to-end delay and multicast handover delay without any of both proposed mechanisms - this would also show the definite demand for a specified MultiMob protocol.=20 =20 Just my 2 cents ;-) =20 Best regards Dirk=20 _____ =20 Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya Gesendet: Dienstag, 20. Januar 2009 16:57 An: multimob@ietf.org Cc: Tony Betreff: [multimob] Simulation Results for Multicast deployment in PMIPv6 Hello Folks, Happy new year everyone =20 A few months back I had received some analysis of PMIPv6 Multicast Deployment from Tony. Thought now is a good time to share this as we debate the deployment choices.=20 Tony simulated mobile MNs with MAGs and LMA serving them. He compared MAG based and LMA based multicast support choices for deployment. He measured things like multicast handover delay and end-to-end delay for many scenarios. One of the findings is that LMA-based deployment choice has lower handover delay but higher end-to-end delay. 5-page report on these simulations is attached.=20 Regards, =20 Behcet _____ =20 From: Brian Haberman To: multimob@ietf.org Sent: Monday, December 8, 2008 2:07:51 PM Subject: [multimob] Multicast deployment in PMIPv6 All, As I mentioned in an earlier message, one of the takeaways from the BoF is that there is some confusion of how multicast can be deployed in the current PMIPv6 architecture. Some people argued that multicast in PMIPv6 already exists using the base MIPv6 protocol. Others argued that either the MIPv6 multicast extensions can't be used or that they were insufficient. From those arguments, I would see a work item being the investigation of what the baseline deployment of multicast in PMIPv6 would look like. This would preclude (for the time being) optimizations such as different approaches to supporting LMA to MAG multicast transit. I view this task as requiring a tight involvement with the NETLMM working group in order to ensure complete understanding of their evolving PMIPv6 specification. Thoughts? Comments? Regards, Brian _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ------_=_NextPart_001_01C98C54.823609E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
sorry=20 for my late reply: I was not sure on whether we decided to proceed on = the aspect=20 of optimising a PMIP Multicast solution as could be seen as the approach = proposed by Tony and colleagues with simulation and=20 draft-zhang-netlmm-pmipv6-mcast. If so we may try to update the draft = expiring=20 in March before next IETF.
On the=20 other hand the simulations also show that both methods (i.e. MAG and LMA = based)=20 HO delay increase with ratio of one-hop delay (wireless/wired) - this = would even=20 be more pronounciated in case all MAGs were interconnected also by = wireless=20 links, right?
Another more general question would be whether also simulations = are=20 availaible which describe end-to-end delay and multicast handover delay = without=20 any of both proposed mechanisms - this would also show the definite = demand=20 for a specified MultiMob protocol. 
 
Just=20 my 2 cents ;-)
 
Best=20 regards
Dirk

Von: multimob-bounces@ietf.org=20 [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet=20 Sarikaya
Gesendet: Dienstag, 20. Januar 2009 = 16:57
An:=20 multimob@ietf.org
Cc: Tony
Betreff: [multimob] = Simulation=20 Results for Multicast deployment in PMIPv6

Hello Folks,
Happy new year everyone
A few months=20 back I had received some analysis of PMIPv6 Multicast Deployment from = Tony.=20 Thought now is a good time to share this as we debate the deployment = choices.=20
 =20 Tony simulated mobile MNs with MAGs and LMA serving them. He compared = MAG based=20 and LMA based multicast support choices for deployment.  =20 He measured things like multicast handover delay and end-to-end delay = for many=20 scenarios.  =20 One of the findings is that LMA-based deployment choice has lower = handover delay=20 but higher end-to-end delay.  =20 5-page report on these simulations is attached.  =20 Regards,   Behcet
From: Brian Haberman=20 <brian@innovationslab.net>
To: multimob@ietf.org
Sent: Monday, December 8, 2008 = 2:07:51=20 PM
Subject: = [multimob]=20 Multicast deployment in PMIPv6

All,
    As I=20 mentioned in an earlier message, one of the takeaways from the BoF is = that there=20 is some confusion of how multicast can be deployed in the current PMIPv6 = architecture.  Some people argued that multicast in PMIPv6 already = exists=20 using the base MIPv6 protocol.  Others argued that either the MIPv6 = multicast extensions can't be used or that they were = insufficient.

 =20   From those arguments, I would see a work item being the = investigation of=20 what the baseline deployment of multicast in PMIPv6 would look = like.  This=20 would preclude (for the time being) optimizations such as different = approaches=20 to supporting LMA to MAG multicast transit.  I view this task as = requiring=20 a tight involvement with the NETLMM working group in order to ensure = complete=20 understanding of their evolving PMIPv6 specification.

  =  =20 Thoughts? =20 Comments?

Regards,
Brian
___________________________________= ____________
multimob=20 mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

------_=_NextPart_001_01C98C54.823609E0--