From behcetsarikaya@yahoo.com Sat Jul 2 09:43:20 2011 Return-Path: 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 B03D411E80AC for ; Sat, 2 Jul 2011 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 x-br0YQE6DPX for ; Sat, 2 Jul 2011 09:43:19 -0700 (PDT) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfa.amsl.com (Postfix) with SMTP id C48FE11E808C for ; Sat, 2 Jul 2011 09:43:19 -0700 (PDT) Received: from [98.139.91.67] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jul 2011 16:43:19 -0000 Received: from [98.139.91.37] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jul 2011 16:43:19 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 02 Jul 2011 16:43:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 728548.31299.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 69958 invoked by uid 60001); 2 Jul 2011 16:43:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309624999; bh=pf1Z5OtZjq7A+zufPOJ+Rwg5ObuDM1JzNkWkwtLAYIA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=b9seYg257AOmYp8iQkyI6o/VX39Op/+NBXkeXg//sO2c7m+mTPAe8QSefyhBbcxdgUTid2DIgQ1GREGp2Fqakp4llDWPj7Hc4G7lZftJoSpgcHdw+/ed6RBZAYmA4P9e4M1Iq5wmWiDwhIrhBE5+4gTVl6PPer1j8Ib/iecQ9l0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=sLFRXRckx8a7t0nnBK9dp9Riw0jwQ5qPmT5ygeQ5UIwfYtYIEj4pa3hwoOM/pZuBiaR3QK09a3QDCOcibjfdWlENxCx5LWgugZLde51SCSpMZriIL8nTNU8+Lf5yjq5udCEIVcINimM8pE2L48wYE+rFU9513aC+X1mS1CvTbEw=; X-YMail-OSG: 9B2kWxYVM1nPtdS3h_IUNH9j_14wSz4ar7VZrZDleY8ChlF GuqYRJsIeknxQLoOg91ASwxijf95OegJR29SGBMe06GxdIuCJYT8l_GSOW8x 4SuUjT_BImu4lRc2YNTGEaL.xA._VTg.82_cEbQdvpCk0xTqnCwtHi2YSQ70 n10SIKW7EYF2j3UnS9JP0wHmWT77NIpDZAJUNXZ2vlApBIhEudxiuYq_hpDW QvGkXulPsLe9nqJeJNBTPmdxCyoqyOqP65nBNVOBjr8DIVvANdGM260Xr2o8 rWRm55s43hVcgbh8bPJBOfNs9Y1RJrEk6phIDEPC8VGY1c4FFpzDZO0Fi5RW I_bKUKVcbbZRzM_GTPyg4pADgsIV0ElXG6vKlqql95cRHa9y4v8b7nUZgh8S zd7BCLAH86o0tmQ-- Received: from [71.170.141.239] by web111406.mail.gq1.yahoo.com via HTTP; Sat, 02 Jul 2011 09:43:19 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <4D91F335.40709@informatik.haw-hamburg.de> <4D95988A.9060703@informatik.haw-hamburg.de> <1309448140.75241.YahooMailRC@web111408.mail.gq1.yahoo.com> <78F1C759D89E1C44A6DD4C06B9A4B270C39A70E274@E2K7MBX.napier-mail.napier.ac.uk> Message-ID: <1309624999.60043.YahooMailRC@web111406.mail.gq1.yahoo.com> Date: Sat, 2 Jul 2011 09:43:19 -0700 (PDT) From: Behcet Sarikaya To: "multimob@ietf.org" In-Reply-To: <78F1C759D89E1C44A6DD4C06B9A4B270C39A70E274@E2K7MBX.napier-mail.napier.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:43:20 -0000 It will nice to write all these issues in a draft and present them in Quebec. There is still time to submit such a draft as -00 by Monday night. We can have a slot to discuss it as part of tunnel convergence solutions section of our session. Regards, Behcet > Dear all, > > In my opinion, there is no optimal solution to this problem as it depends on >several constraints: > > - The location of the multicast source (Within the home network or elsewhere); > - The scope of distribution; > - The location of the HA or equivalent entity in the home network (closeness >to Ingress router); > - The number and the mobility pattern of the mobile receivers; > - and the availability and the accessibility of the same multicast service in >visited networks. > > Even inside the home network, when the home subscription method is used and >both the source and the receivers are located outside, we may have a >duplication of tunnels snaking within the home domain and carrying the same >content towards remote mobile receivers. These tunnels may take the same route >or different routes. In other words, the multicast traffic enters natively the >home domain (down to the HA or equivalent) and leaves in tunnel mode (from the >same or different egress points) the home domain to the receivers. > > So, we may just limit our work by making some suggestions how to improve each >specific scenario. > > Kind regards, > Imed > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf >Of Behcet Sarikaya > Sent: 30 June 2011 16:36 > To: multimob@ietf.org > Subject: [multimob] Thoughts on PMIP Optimized Routing > > Hi all, > Let us get back to this thread and continue to discuss the issues involved >on > > the solutions for tunnel convergence problem. > > Currently we have two proposals (somewhat quoting from Thomas' email) > - direct routing (just enable multicast forwarding on MAGs > assuming MAGs are in the local multicast cloud) > - home tunneling (just > perform multicast subscription to one LMA/Multicast DR called M-LMA). > > What are the issues? (again quoting Thomas) > > * the two operations are mixed > * MN moves between PMIP-domains. > > To me the issue is separating unicast and multicast flow paths from the >MAG-LMA > > that we have in the base solution. > > Can we have a solution that is faithful to the base solution and solves all >the > > problems? > Is such a design feasible? worth looking into? > I am saying this because Mobile IPv6 spec says that if you have multicast > locally available which corresponds to the local routing solution we have, go > and use it and does not elaborate much. > > Regards, > > Behcet > > > >Hi, Thomas, > > > >Thanks for your useful comment. > > > >Please see below "Seil" > > > > > > > >2011/4/1 Thomas C. Schmidt > > > >Hi Luis, Seil, > >> > >>some additional remarks marked by [thomas] > >> > >> > >>On 31.03.2011 23:03, Luis M. Contreras wrote: > >> > >>Hi Seil, > >>>more discussion below: > >>> > >>> "Seil" => You don't see the benefit. why? ISPs are now making a > >>> pitch for building and getting their own contents from public > >>> broadcasters, cable broadcasters, ... so on. Obiviously, this is > >>> inevitable trend to achieve competiveness from other ISPs. That will > >>> be getting serious more than now. And as I presented in my > >>> slot, this concept is reflected at MBMS architecture of 3GPP SAE. > >>> Only appropriate manner needs to be handled between home and visited > >>> network. About that, the draft will be updated. > >>> In M-LMA, how about local contents? > >>> > >>>Luis>> It is just my personal view in this interesting and necessary > >>>debate opened byThomas. I would like to distinguish two concepts: remote > >>>content distributed locally, and local content distributed locally. In > >>>the first case, I don't see the benefit. I think that the simplest way > >>>to deliver the service is through M-LMA. In the second case, I agree > >>>that it seems more optimal to use direct routing. But, in my opinion, > >>>the direct routing can not be consider as the main solution, but an > >>>ocassional optimization scenario in case the content is local to the > >>>visited domain (probably the most common is that a MN usually will > >>>demand contents from its Home Network, because the user maintains a > >>>service contract its Home Operator). I think it is the same idea than in > >>>the unicast case regarding the routing optimization: it is an > >>>optimization case for a more general solution (which I believe it is the > >>>M-LMA approach). > >>> > >>> > >[thomas] The problem with direct routing as a "general solution" is that it >is > > >unrealistic to assume all multicast traffic, which is globally available, is > >routed directly into an access network of an operator. This will most likely > >only be the case for content streams the operator is willing to offer to its > >customers, e.g., selected IPTV channels ... So relying purely on the direct > >routing might end up with a poor choice of content services, in particular >with > > > >changing offers between access network operators. > >> > >>However, the benefit of local routing in the "remote content distributed > >>locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Stream > > >>...) guides the content into its access network and then simply turns on > >>multicast routing (this is what wired operators do today). This will result >in > > > >>full scaling, no tunnels or extra boxes involved and at least optimizes >Capex, > > > >>but typically Opex, as well (depending on Mcast route management brains). > >> > >>The M-LMA, as mentioned many times, is an extra box that needs to handle all > > >>streams simultaneously and redistribute them via tunnels. This leads to a > >>scaling bottleneck, traffic multiplication in the access network (including > >>waste of bandwidth) and efforts in semi-manual configurations ... > > "Seil" => I agree this comment as my response to Luis's comment in previous > mail. As I mentioned in previous comment, this is serious issue. In my >opinion, > > it might be an instance of the biter getting bitten. > > > * Coexistence of home/remote content retrieval (e.g., by the base > >> solution) and access from local multicast routing. Thus a MAG would > >> need to distinguish (preconfigured) local group subscriptions from > >> non-local content. > >> > >> Luis>> This is not possible with current functionality on MAG as > >> MLD proxy. It is only possible to define one upstream interface, > >> so the operator would be forced to permanently choose between > >> local or remote multicast for all kind of traffic. > >> > >> "Seil" => Yes, it's possible. Only one upstream interface is > >> available but "per single MLD proxy instance". So, the choice will > >> not be forced to operators. > >> > >>Luis>> I don't think so. According to base solution, the MN is > >>associated to an MLD proxy instance as a function of the LMA it is bound > >>to. That is, the association to an MLD instance is previous to the MLD > >>Report processing. So, the MAG doesn't know the required content (local > >>or remote) before associating the MN to a proxy instance. As > >>consequence, the operator is forced to choose between using an MLD proxy > >>pointing to the M-LMA or another one pointing to local MR for all kind > >>of traffic, and for all the MNs associated to the same LMA. > >> > >> > [Thomas] In my understanding, Luis is correct here. Upstream interfaces of > RFC4605 MLD proxies cannot distinguish between different groups. For one > downstream interface you always need to have one single proxy instance and >this > > instance only can have one upstream interface. As the downstream interface > corresponds to a link with an MN, this MN can either receive local or remote > content. > > > >This is not what we want: we want to distinguish traffic per group, not per > >host. So I guess, a solution for this scenario is not possible using a >standard > > > >MLD proxy function. It is of course easy to achieve by making MAGs PIM (SM or > > >BIDIR) routers and configuring RPs per group(-range). > > > > > > "Seil" => Considering the structure where several sources connect to an MAG, > it could be a good candidate. > > > > Best wishes, > > > > > >Thomas > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > Edinburgh Napier University is Edinburgh's top university for graduate >employability (HESA 2010), and proud winner of the Queen's Anniversary Prize >for Higher and Further Education 2009, awarded for innovative housing >construction for environmental benefit and quality of life. > > This message is intended for the addressee(s) only > and should not be read, copied or disclosed to anyone else outwith the >University without the permission of the sender. It is your responsibility to >ensure that this message and any attachments are scanned for viruses or other >defects. > > Edinburgh Napier University does not accept liability for any loss or > damage which may result from this email or any attachment, or for errors or >omissions arising after it was sent. Email is not a secure medium. Email >entering the University's system is subject to routine monitoring and filtering >by the University. > > > Edinburgh Napier University is a registered Scottish > charity. > Registration number SC018373 > > > From Dirk.von-Hugo@telekom.de Tue Jul 5 00:46:43 2011 Return-Path: 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 6269521F87F1 for ; Tue, 5 Jul 2011 00:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 EivJEsOk5PjP for ; Tue, 5 Jul 2011 00:46:42 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id D57AC21F85A6 for ; Tue, 5 Jul 2011 00:46:37 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jul 2011 09:46:32 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.236]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Jul 2011 09:46:30 +0200 From: To: Date: Tue, 5 Jul 2011 09:46:30 +0200 Thread-Topic: New Version Notification for draft-vonhugo-multimob-cxtp-extension-00.txt Thread-Index: Acw6aZiTfCuzdsn1RoOIoOW4q8dAxwAfaKUg Message-ID: <05C81A773E48DD49B181B04BA21A342A25B8611D15@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multimob] WG: New Version Notification for draft-vonhugo-multimob-cxtp-extension-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 07:46:43 -0000 Dear all, We have posted a draft new draft to be found at http://tools.ietf.org/id/dr= aft-vonhugo-multimob-cxtp-extension-00.txt on handover improvement. Any suggestions, comments, and contributions welcome! C U in Quebec! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Gesendet: Montag, 4. Juli 2011 18:44 An: asaeda@wide.ad.jp Cc: asaeda@wide.ad.jp; von Hugo, Dirk Betreff: New Version Notification for draft-vonhugo-multimob-cxtp-extension= -00.txt A new version of I-D, draft-vonhugo-multimob-cxtp-extension-00.txt has been= successfully submitted by Hitoshi Asaeda and posted to the IETF repository= . Filename: draft-vonhugo-multimob-cxtp-extension Revision: 00 Title: Context Transfer Protocol Extension for Multicast Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 16 Abstract: This document describes an extension of the Context Transfer Protocol (CXTP) to support seamless IP multicast services with Proxy Mobile IPv6 (PMIPv6). The IETF Secretariat From Dirk.von-Hugo@telekom.de Thu Jul 7 05:42:50 2011 Return-Path: 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 CD58321F87C9 for ; Thu, 7 Jul 2011 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 AP3pG6JZXACk for ; Thu, 7 Jul 2011 05:42:50 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B121F8795 for ; Thu, 7 Jul 2011 05:42:49 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jul 2011 14:37:05 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.236]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 7 Jul 2011 14:37:05 +0200 From: To: , , , Date: Thu, 7 Jul 2011 14:37:03 +0200 Thread-Topic: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards Thread-Index: AcwhQqFFhD+xUGErQJ2xN5YtH6smrAbUMnjQ Message-ID: <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> References: <8054.73450.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <8054.73450.qm@web111406.mail.gq1.yahoo.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:42:50 -0000 Dear Thomas, Matthias, Rajeev, and Gorry, though your handover related draft draft-schmidt-multimob-fmipv6-pfmipv6-mu= lticast-04 had not changed much since last session I would like to ask some= questions I had when re-reading it recently: First of all I like the simple idea for the NMAG/NAR to just send MLD to PM= AG/PAR to receive 'old' multicast data. It only might complicate things whe= n MAG and LMA are native multicast routers by having to add MLD proxy funct= ionality. I wonder whether in reactive scenario without buffering at PMAG/PAR a loss = of data may occur before NMAG-NAR has completed subscription ... Some minor observations: Saying on page 6: On reception of the HI message, NAR returns a multicast acknowledgement in = its HACK answer that indicates its ability to support each requested group Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups" at NMAG= /NAR has to occur _before_ replying to PMAG/PAR with "HAck(Multicast AckOpt= )" because otherwise NMAG/NAR cannot confirm ist ability? Saying on page 8: Note that group traffic may already arrive from a MN's subscription at the time NAR receives the HI message. This deals with group traffic from another MN's subscription arriving at NA= R, right? And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant to happen= between MN and PAR (as fepicted) to show the previous attachment, and not = between MN and NAR, corresponding to sect. 4.1.3. saying: NAR will advertise its multicast support by setting the M-bit in PrRtAdv. Saying on page 9 (on PMIPv6): In either case, the PAR will become knowledgeable about multicast group su= bscriptions of the MN. PAR means the same as PMAG (PAR) in the following text - and do I understan= d correctly that PAR shall indicate that MAG is also the 1st router of the = AN towards MN? Finally some very minor nits: Page 6: As group membership information are present =3D> As group membership inform= ation is present Page 13: and intersect the request subscription =3D> and intersect the request for s= ubscription Bidiretional =3D> Bidirectional Page 16: details on message formats. =3D> details on message formats). BTW I would recommend a consistent writing throughout the document of HACK/= HAck/HACk (e.g. RFC 5949 says "Hack"), FBACK/Fback, and NMAG/nMAG ... As we say: nix f=FCr ungut, ja? ;-) Thanks! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Donnerstag, 2. Juni 2011 18:31 An: multimob@ietf.org Betreff: [multimob] Session in IETF-81 Folks, We need to come up with a draft agenda by June 10. I expect that Quebec City session will be more on handover related drafts. Tunnel convergence drafts were discussed in depth in Prague. Based on this, please send your session requests to the chairs. Regards, Behcet _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jul 7 09:21:39 2011 Return-Path: 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 1BE1621F873F for ; Thu, 7 Jul 2011 09:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HuVI015+gKdF for ; Thu, 7 Jul 2011 09:21:38 -0700 (PDT) Received: from nm17-vm0.bullet.mail.sp2.yahoo.com (nm17-vm0.bullet.mail.sp2.yahoo.com [98.139.91.212]) by ietfa.amsl.com (Postfix) with SMTP id 7870821F8681 for ; Thu, 7 Jul 2011 09:21:38 -0700 (PDT) Received: from [98.139.91.66] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 16:21:34 -0000 Received: from [98.139.91.24] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 16:21:34 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 16:21:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531199.34444.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 20214 invoked by uid 60001); 7 Jul 2011 16:21:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310055694; bh=NzflwtUrYBsTslzIRD8p2xh7F/fxsNZNl2buY6vtxw8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v4/grrK8CDtRQRaguw47BE9QTjHoy/57vX529qCw2yJ5r72Q7rCmUPsoSCNBdjh8yh14VAVrLoqKj/D4jFjfU/TJziMnfmX3AEopMnlcYSclLgV7mpuzPyDOCjG1ObmJ0JON+qEfRUUXfKVCpEPbbyXN8sNq6VHcxsRMYtu4DBQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nTt0duV6cBsegx01J3tWcyR1teFpkyNk+oxMMvrmcnaT8vu9hNnloSSe3dxugTQ6bQdAvnSkxKMzTnkt07xLDlTSLXjTxVevRVDK664eu2OxHh1az9yWcrcP4AJ45/oktewrIwv/I28hmZHNB7vxVcr/DobKKCG25Rw4HhJ+yg8=; X-YMail-OSG: VSgjumgVM1mE1hL3Bon2_q4AuX3cFvOgfvsUnT1WfX_OpEI azI5V3vC6CaOf6z.AvO5FIi39HP19xRHbHZBAD3DfSiWbhTN6SOy_9AjWyiA 4lEntYccI9OprZiJ10UgeH_OjiJTzZ1pDYtKLLTYAcSs.f02kG.QlCt2iRuY ajcsuIyJcjGcSoydKjx3zCrgx1vP4jDp9NXDHdjWrSg0kIJmA8vpLYnomSRa 7pa88WoKzZY02olKztDrhXut_9ZrDfOHcwd8T88aUSvFl0.zBB7Cl.3pT.o1 5c9PbQbK.uYciqaioJxYZDnAzbgWCCtSi6ClxtX1iKSMtuvU3zsianH.ckAH OOE78jdsAMjXJgWPElyOHdNY4HctMSIKaye_fwqVnXUE_MvK0fbf_0UxFej2 hfyFKsV6x4pnAsg-- Received: from [50.58.7.243] by web111401.mail.gq1.yahoo.com via HTTP; Thu, 07 Jul 2011 09:21:33 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <8054.73450.qm@web111406.mail.gq1.yahoo.com> <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> Message-ID: <1310055693.13668.YahooMailRC@web111401.mail.gq1.yahoo.com> Date: Thu, 7 Jul 2011 09:21:33 -0700 (PDT) From: Behcet Sarikaya To: Dirk.von-Hugo@telekom.de, schmidt@fhtw-berlin.de, mw@link-lab.net, rkoodli@cisco.com, gorry@erg.abdn.ac.uk In-Reply-To: <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:21:39 -0000 BTW =0Anix f=FCr ungut, ja?=0Ameans no offense :-).=0A=0ABehcet=0A=0A=0A=0A= -=0A> =0A> Dear Thomas, Matthias, Rajeev, and Gorry,=0A> =0A> though your h= andover related draft =0A>draft-schmidt-multimob-fmipv6-pfmipv6-multicast-= 04 had not changed much since =0A>last session I would like to ask some qu= estions I had when re-reading it =0A>recently:=0A> =0A> First of all I lik= e the simple idea for the NMAG/NAR to just send MLD to =0A>PMAG/PAR to rec= eive 'old' multicast data. It only might complicate things when =0A>MAG an= d LMA are native multicast routers by having to add MLD proxy =0A>function= ality.=0A> I wonder whether in reactive scenario without buffering at PMAG= /PAR a loss of =0A>data may occur before NMAG-NAR has completed subscriptio= n ...=0A> =0A> Some minor observations:=0A> =0A> Saying on page 6:=0A> On = reception of the HI message, NAR returns a multicast acknowledgement in it= s =0A>HACK answer=0A> that indicates its ability to support each reques= ted group=0A> =0A> Doesn't this imply in Figs. 2 and 4 that "Join to multi= cast groups" at =0A>NMAG/NAR has to occur _before_ replying to PMAG/PAR wi= th "HAck(Multicast =0A>AckOpt)" because otherwise NMAG/NAR cannot confirm = ist ability?=0A> =0A> Saying on page 8:=0A> Note that group traffic may a= lready arrive from a MN's subscription=0A> at the time NAR receives the= HI message.=0A> This deals with group traffic from another MN's subscript= ion arriving at NAR, =0A>right?=0A> =0A> And just for clarification: In Fi= g.3 the RtSolPr/PrRtAdv is meant to happen =0A>between MN and PAR (as fepi= cted) to show the previous attachment, and not =0A>between MN and NAR, cor= responding to sect. 4.1.3. saying:=0A> NAR will advertise its multicast= support by setting the M-bit in=0A> PrRtAdv.=0A> =0A> Saying on page 9= (on PMIPv6):=0A> In either case, the PAR will become knowledgeable about= multicast group =0A>subscriptions of the MN.=0A> =0A> PAR means the same = as PMAG (PAR) in the following text - and do I understand =0A>correctly th= at PAR shall indicate that MAG is also the 1st router of the AN =0A>toward= s MN?=0A> =0A> Finally some very minor nits:=0A> =0A> Page 6:=0A> As group = membership information are present =3D> As group membership information = =0A>is present=0A> =0A> Page 13:=0A> and intersect the request subscriptio= n =3D> and intersect the request for =0A>subscription=0A> Bidiretional =3D= > Bidirectional=0A> =0A> Page 16:=0A> details on message formats. =3D> det= ails on message formats).=0A> =0A> BTW I would recommend a consistent writ= ing throughout the document of =0A>HACK/HAck/HACk (e.g. RFC 5949 says "Hac= k"), FBACK/Fback, and NMAG/nMAG ...=0A> =0A> As we say: nix f=FCr ungut, j= a?=0A> ;-)=0A> Thanks!=0A> =0A> Best regards=0A> Dirk=0A> =0A> -----Urspr= =FCngliche Nachricht-----=0A> Von: multimob-bounces@ietf.org [mailto:multim= ob-bounces@ietf.org] Im Auftrag =0A>von Behcet Sarikaya=0A> Gesendet: Donn= erstag, 2. Juni 2011 18:31=0A> An: multimob@ietf.org=0A> Betreff: [multimob= ] Session in IETF-81=0A> =0A> Folks,=0A> We need to come up with a draft= agenda by June 10.=0A> I expect that Quebec City session will be more on = handover related drafts.=0A> Tunnel convergence drafts were discussed in d= epth in Prague.=0A> =0A> Based on this, please send your session requests = to the chairs.=0A> =0A> Regards,=0A> =0A> Behcet=0A> =0A> ________________= _______________________________=0A> multimob mailing list=0A> multimob@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A> From stig@venaas.com Thu Jul 7 14:42:20 2011 Return-Path: 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 586E19E8028 for ; Thu, 7 Jul 2011 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 hm5ZtX7CRZzF for ; Thu, 7 Jul 2011 14:42:19 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6848B9E8029 for ; Thu, 7 Jul 2011 14:42:18 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:8558:34ae:1f72:d272] (unknown [IPv6:2001:420:4:ea0c:8558:34ae:1f72:d272]) by ufisa.uninett.no (Postfix) with ESMTPSA id 01AE98096; Thu, 7 Jul 2011 23:42:15 +0200 (CEST) Message-ID: <4E162836.1060704@venaas.com> Date: Thu, 07 Jul 2011 14:42:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Romdhani, Imed" References: <4D91F335.40709@informatik.haw-hamburg.de> <4D95988A.9060703@informatik.haw-hamburg.de> <1309448140.75241.YahooMailRC@web111408.mail.gq1.yahoo.com> <78F1C759D89E1C44A6DD4C06B9A4B270C39A70E274@E2K7MBX.napier-mail.napier.ac.uk> In-Reply-To: <78F1C759D89E1C44A6DD4C06B9A4B270C39A70E274@E2K7MBX.napier-mail.napier.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "multimob@ietf.org" Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:42:20 -0000 On 6/30/2011 9:07 AM, Romdhani, Imed wrote: > Dear all, > > In my opinion, there is no optimal solution to this problem as it depends on several constraints: > > - The location of the multicast source (Within the home network or elsewhere); > - The scope of distribution; > - The location of the HA or equivalent entity in the home network (closeness to Ingress router); > - The number and the mobility pattern of the mobile receivers; > - and the availability and the accessibility of the same multicast service in visited networks. > > Even inside the home network, when the home subscription method is used and both the source and the receivers are located outside, we may have a duplication of tunnels snaking within the home domain and carrying the same content towards remote mobile receivers. These tunnels may take the same route or different routes. In other words, the multicast traffic enters natively the home domain (down to the HA or equivalent) and leaves in tunnel mode (from the same or different egress points) the home domain to the receivers. > > So, we may just limit our work by making some suggestions how to improve each specific scenario. Right, so looking at the current basic solution vs direct routing, the choice depends on where the source is and where it can be received. If you want to receive multicast from your home provider, then the basic solution would work. If you want to receive multicast available locally, then the direct routing would work, hopefully. If you are visiting another network, you can only receive multicast from your home provider as direct routing, if they have a multicast peering. Looking at the solution of some kind of dedicated router, as in the so-called multicast LMA. This would work if the different home providers all have peerings with the one operating the dedicated router. These may also be combined. Maybe there is both home and local content that should be available. Or something along these lines. So we may need to either pick a specific scenario and come up with a solution for that, or come up with a few different scenarios and solutions, and the different deployments can choose what is right for them. Stig > Kind regards, > Imed > > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: 30 June 2011 16:36 > To: multimob@ietf.org > Subject: [multimob] Thoughts on PMIP Optimized Routing > > Hi all, > Let us get back to this thread and continue to discuss the issues involved on > the solutions for tunnel convergence problem. > > Currently we have two proposals (somewhat quoting from Thomas' email) > - direct routing (just enable multicast forwarding on MAGs > assuming MAGs are in the local multicast cloud) > - home tunneling (just > perform multicast subscription to one LMA/Multicast DR called M-LMA). > > What are the issues? (again quoting Thomas) > > * the two operations are mixed > * MN moves between PMIP-domains. > > To me the issue is separating unicast and multicast flow paths from the MAG-LMA > that we have in the base solution. > > Can we have a solution that is faithful to the base solution and solves all the > problems? > Is such a design feasible? worth looking into? > I am saying this because Mobile IPv6 spec says that if you have multicast > locally available which corresponds to the local routing solution we have, go > and use it and does not elaborate much. > > Regards, > > Behcet >> >> Hi, Thomas, >> >> Thanks for your useful comment. >> >> Please see below "Seil" >> >> >> >> 2011/4/1 Thomas C. Schmidt >> >> Hi Luis, Seil, >>> >>> some additional remarks marked by [thomas] >>> >>> >>> On 31.03.2011 23:03, Luis M. Contreras wrote: >>> >>> Hi Seil, >>>> more discussion below: >>>> >>>> "Seil" => You don't see the benefit. why? ISPs are now making a >>>> pitch for building and getting their own contents from public >>>> broadcasters, cable broadcasters, ... so on. Obiviously, this is >>>> inevitable trend to achieve competiveness from other ISPs. That will >>>> be getting serious more than now. And as I presented in my >>>> slot, this concept is reflected at MBMS architecture of 3GPP SAE. >>>> Only appropriate manner needs to be handled between home and visited >>>> network. About that, the draft will be updated. >>>> In M-LMA, how about local contents? >>>> >>>> Luis>> It is just my personal view in this interesting and necessary >>>> debate opened byThomas. I would like to distinguish two concepts: remote >>>> content distributed locally, and local content distributed locally. In >>>> the first case, I don't see the benefit. I think that the simplest way >>>> to deliver the service is through M-LMA. In the second case, I agree >>>> that it seems more optimal to use direct routing. But, in my opinion, >>>> the direct routing can not be consider as the main solution, but an >>>> ocassional optimization scenario in case the content is local to the >>>> visited domain (probably the most common is that a MN usually will >>>> demand contents from its Home Network, because the user maintains a >>>> service contract its Home Operator). I think it is the same idea than in >>>> the unicast case regarding the routing optimization: it is an >>>> optimization case for a more general solution (which I believe it is the >>>> M-LMA approach). >>>> >>>> >> [thomas] The problem with direct routing as a "general solution" is that it is >> unrealistic to assume all multicast traffic, which is globally available, is >> routed directly into an access network of an operator. This will most likely >> only be the case for content streams the operator is willing to offer to its >> customers, e.g., selected IPTV channels ... So relying purely on the direct >> routing might end up with a poor choice of content services, in particular with > >> changing offers between access network operators. >>> >>> However, the benefit of local routing in the "remote content distributed >>> locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Stream >>> ...) guides the content into its access network and then simply turns on >>> multicast routing (this is what wired operators do today). This will result in > >>> full scaling, no tunnels or extra boxes involved and at least optimizes Capex, > >>> but typically Opex, as well (depending on Mcast route management brains). >>> >>> The M-LMA, as mentioned many times, is an extra box that needs to handle all >>> streams simultaneously and redistribute them via tunnels. This leads to a >>> scaling bottleneck, traffic multiplication in the access network (including >>> waste of bandwidth) and efforts in semi-manual configurations ... > > "Seil" => I agree this comment as my response to Luis's comment in previous > mail. As I mentioned in previous comment, this is serious issue. In my opinion, > it might be an instance of the biter getting bitten. > > > * Coexistence of home/remote content retrieval (e.g., by the base >>> solution) and access from local multicast routing. Thus a MAG would >>> need to distinguish (preconfigured) local group subscriptions from >>> non-local content. >>> >>> Luis>> This is not possible with current functionality on MAG as >>> MLD proxy. It is only possible to define one upstream interface, >>> so the operator would be forced to permanently choose between >>> local or remote multicast for all kind of traffic. >>> >>> "Seil" => Yes, it's possible. Only one upstream interface is >>> available but "per single MLD proxy instance". So, the choice will >>> not be forced to operators. >>> >>> Luis>> I don't think so. According to base solution, the MN is >>> associated to an MLD proxy instance as a function of the LMA it is bound >>> to. That is, the association to an MLD instance is previous to the MLD >>> Report processing. So, the MAG doesn't know the required content (local >>> or remote) before associating the MN to a proxy instance. As >>> consequence, the operator is forced to choose between using an MLD proxy >>> pointing to the M-LMA or another one pointing to local MR for all kind >>> of traffic, and for all the MNs associated to the same LMA. >>> >>> > [Thomas] In my understanding, Luis is correct here. Upstream interfaces of > RFC4605 MLD proxies cannot distinguish between different groups. For one > downstream interface you always need to have one single proxy instance and this > instance only can have one upstream interface. As the downstream interface > corresponds to a link with an MN, this MN can either receive local or remote > content. >> >> This is not what we want: we want to distinguish traffic per group, not per >> host. So I guess, a solution for this scenario is not possible using a standard > >> MLD proxy function. It is of course easy to achieve by making MAGs PIM (SM or >> BIDIR) routers and configuring RPs per group(-range). >> >> > > "Seil" => Considering the structure where several sources connect to an MAG, > it could be a good candidate. > > > > Best wishes, >> >> >> Thomas > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > > Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life. > > This message is intended for the addressee(s) only > and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. > Edinburgh Napier University does not accept liability for any loss or > damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. > > Edinburgh Napier University is a registered Scottish > charity. > Registration number SC018373 > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From waehlisch@ieee.org Fri Jul 8 13:50:51 2011 Return-Path: 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 1209221F8B30 for ; Fri, 8 Jul 2011 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MTdKqffu5Scm for ; Fri, 8 Jul 2011 13:50:46 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 657A221F8B59 for ; Fri, 8 Jul 2011 13:50:45 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178059126.adsl.alicedsl.de ([85.178.59.126] helo=mw-PC.fritz.box) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QfI0Z-000Hoz-BE; Fri, 08 Jul 2011 22:50:43 +0200 Date: Fri, 8 Jul 2011 22:50:42 +0200 From: Matthias Waehlisch To: Dirk.von-Hugo@telekom.de In-Reply-To: <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> Message-ID: References: <8054.73450.qm@web111406.mail.gq1.yahoo.com> <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1465890356-27888-1310158242=:3352" X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:50:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1465890356-27888-1310158242=:3352 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Dirk, thanks a lot for your message and sorry for the delay. Please see=20 comments inline. On Thu, 7 Jul 2011, Dirk.von-Hugo@telekom.de wrote: > though your handover related draft=20 > draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed=20 > much since last session I would like to ask some questions I had when=20 > re-reading it recently: >=20 > First of all I like the simple idea for the NMAG/NAR to just send MLD=20 > to PMAG/PAR to receive 'old' multicast data. It only might complicate=20 > things when MAG and LMA are native multicast routers by having to add=20 > MLD proxy functionality. I wonder whether in reactive scenario without=20 > buffering at PMAG/PAR a loss of data may occur before NMAG-NAR has=20 > completed subscription ... >=20 as usual in PFMIPv6, packet loss may occur if there is no buffering:=20 "MN will be able to participate in multicast group communication with a=20 handover performance comparable to that for unicast, while network=20 resources consumption is minimized." (page 6). > Some minor observations: >=20 > Saying on page 6: > On reception of the HI message, NAR returns a multicast acknowledgement i= n its HACK answer > that indicates its ability to support each requested group >=20 > Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups" at=20 > NMAG/NAR has to occur _before_ replying to PMAG/PAR with=20 > "HAck(Multicast AckOpt)" because otherwise NMAG/NAR cannot confirm ist=20 > ability? >=20 No, with respect to the group service the Multicast Acknowledgement=20 Option indicates if (a) group service is unsupported or (b) group=20 service is administratively prohibited. This does not say if the group=20 service is available. If the NAR waits for direct multicast traffic this would require some=20 timeout mechanisms and (in the worst case) would lead to an additional=20 delay. > Saying on page 8: > Note that group traffic may already arrive from a MN's subscription > at the time NAR receives the HI message. > > This deals with group traffic from another MN's subscription arriving=20 > at NAR, right? >=20 Yes, but it can also indicate that a branching point is close to the=20 NAR. > And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant to=20 > happen between MN and PAR (as fepicted) to show the previous=20 > attachment, and not between MN and NAR, corresponding to sect. 4.1.3.=20 > saying: > > NAR will advertise its multicast support by setting the M-bit in > PrRtAdv. >=20 Not necessarily. A NAR sends a PrRtAdv based on a RtSolPr by the MN.=20 In this case, it advertises its multicast support, as well. This is=20 mentioned just for completeness. Maybe we should clarify this. > Saying on page 9 (on PMIPv6): > In either case, the PAR will become knowledgeable about multicast group = subscriptions of the MN. >=20 > PAR means the same as PMAG (PAR) in the following text - and do I=20 > understand correctly that PAR shall indicate that MAG is also the 1st=20 > router of the AN towards MN? >=20 Yes, we will correct this. > Finally some very minor nits: >=20 > Page 6: > As group membership information are present =3D> As group membership info= rmation is present >=20 > Page 13: > and intersect the request subscription =3D> and intersect the request for= subscription > Bidiretional =3D> Bidirectional >=20 > Page 16: > details on message formats. =3D> details on message formats). >=20 > BTW I would recommend a consistent writing throughout the document of=20 > HACK/HAck/HACk (e.g. RFC 5949 says "Hack"), FBACK/Fback, and NMAG/nMAG=20 > ... >=20 Agree with all of corrections. > As we say: nix f=FCr ungut, ja? > ;-) > And many thanks your the careful reading! Cheers matthias --=20 Matthias Waehlisch =2E Freie Universitaet Berlin, Inst. fuer Informatik, AG CST =2E Takustr. 9, D-14195 Berlin, Germany =2E. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net --1465890356-27888-1310158242=:3352-- From contreras.uc3m@gmail.com Mon Jul 11 08:38:32 2011 Return-Path: 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 12BD321F8DA0 for ; Mon, 11 Jul 2011 08:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tN8jcYsng4Lv for ; Mon, 11 Jul 2011 08:38:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7069D21F8D9C for ; Mon, 11 Jul 2011 08:38:31 -0700 (PDT) Received: by pzk5 with SMTP id 5so4580207pzk.31 for ; Mon, 11 Jul 2011 08:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6+awe0lZ9YnUzGHQ4uvVkHjjdSryBNfouA8BnEoLH5I=; b=DeB2VDfN8RY5LXQLzvMqRTFX7IAW2/QZKhGNIi3Cepyr+zLcr8ZF6CQh2x4h4aR40p 6zPv7YnnMV6XotQI4/zBCDsDamTt4lo5caiMT0TmyOKrwPuIajtVaKPy2tV42FTNTvAn B69N7gvgyaQaNTq7rYzE5Mfg6oSnbeJQl3ehU= MIME-Version: 1.0 Received: by 10.68.50.9 with SMTP id y9mr8191887pbn.24.1310398710530; Mon, 11 Jul 2011 08:38:30 -0700 (PDT) Received: by 10.68.40.5 with HTTP; Mon, 11 Jul 2011 08:38:30 -0700 (PDT) In-Reply-To: <20110711153202.22473.35497.idtracker@ietfa.amsl.com> References: <20110711153202.22473.35497.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 17:38:30 +0200 Message-ID: From: "Luis M. Contreras" To: multimob@ietf.org Content-Type: multipart/alternative; boundary=bcaec5430590a7c3ef04a7ccf9dd Cc: Ignacio Soto Subject: [multimob] Fwd: New Version Notification for draft-zuniga-multimob-smspmip-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:38:32 -0000 --bcaec5430590a7c3ef04a7ccf9dd Content-Type: text/plain; charset=ISO-8859-1 Dear all, we have just posted an updated version of the multicast solution proposal draft-zuniga-multimob-smspmip. You can find the new draft at the following link: http://www.ietf.org/id/draft-zuniga-multimob-smspmip-06.txt best regards, Luis ---------- Forwarded message ---------- From: Date: 2011/7/11 Subject: New Version Notification for draft-zuniga-multimob-smspmip-06.txt To: contreras.uc3m@gmail.com Cc: akbar.rahman@interdigital.com, contreras.uc3m@gmail.com, isoto@dit.upm.es, cjbc@it.uc3m.es A new version of I-D, draft-zuniga-multimob-smspmip-06.txt has been successfully submitted by Luis M. Contreras and posted to the IETF repository. Filename: draft-zuniga-multimob-smspmip Revision: 06 Title: Support Multicast Services Using Proxy Mobile IPv6 Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 22 Abstract: The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [RFC6224]. In this document, an enhancement is proposed to the base solution to use a multicast tree mobility anchor as the topological anchor point for multicast traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement provides benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployments scenarios. The IETF Secretariat --bcaec5430590a7c3ef04a7ccf9dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

we have just posted an updated version of the multic= ast solution proposal draft-zuniga-multimob-smspmip.

=A0

You can find the new draft at the following link:

=A0

best regards,

=A0

Luis


---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: 2011/7/11
Subject: New Version Notification for draft-zuniga-multi= mob-smspmip-06.txt
To: contr= eras.uc3m@gmail.com
Cc: akbar.rahman@interdigital.com, contreras.uc3m@gmail.com, = isoto@dit.upm.es, cjbc@it.uc3m.es


A new version of I-D, draft-zuniga-multimob-smspmip-06.txt has been= successfully submitted by Luis M. Contreras and posted to the IETF reposit= ory.

Filename: =A0 =A0 =A0 =A0draft-zuniga-multimob-smspmip
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Support Multicast Services Using Proxy Mobile IP= v6
Creation date: =A0 2011-07-11
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 22

Abstract:
=A0 The MULTIMOB group has specified a base solution to support IP
=A0 multicasting in a PMIPv6 domain [RFC6224]. In this document, an
=A0 enhancement is proposed to the base solution to use a multicast tree =A0 mobility anchor as the topological anchor point for multicast
=A0 traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement<= br> =A0 provides benefits such as reducing multicast traffic replication and =A0 supporting different PMIPv6 deployments scenarios.





The IETF Secretariat

--bcaec5430590a7c3ef04a7ccf9dd-- From contreras.uc3m@gmail.com Mon Jul 11 08:55:53 2011 Return-Path: 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 17E2B21F8C3D for ; Mon, 11 Jul 2011 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 9004gMsGBlbG for ; Mon, 11 Jul 2011 08:55:52 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4133C21F8B94 for ; Mon, 11 Jul 2011 08:55:52 -0700 (PDT) Received: by pvh18 with SMTP id 18so4159876pvh.31 for ; Mon, 11 Jul 2011 08:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W28a2Z/aSxTQuLTkTReOeQBjNHFYJ2ZK4JgxCPjPeUY=; b=vSmbXT5Ff0d4uOGKD8Rp+Kbe2grRj6AwLCypHd1pYxg64f2JdweJ0i3aN01PB5IZrS J7dWcegIrF0EmW69i/kA5lde8nIY0GtIzW9oITKHc7nxXlYOFl7XgDYbTEa9QiijuK7j 0Htiomv5rIjWnoxF4iK03XbUT11bv1Lm7pkhE= MIME-Version: 1.0 Received: by 10.68.17.232 with SMTP id r8mr7619507pbd.91.1310399751801; Mon, 11 Jul 2011 08:55:51 -0700 (PDT) Received: by 10.68.40.5 with HTTP; Mon, 11 Jul 2011 08:55:51 -0700 (PDT) In-Reply-To: References: <20110711153202.22473.35497.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 17:55:51 +0200 Message-ID: From: "Luis M. Contreras" To: multimob@ietf.org Content-Type: multipart/alternative; boundary=bcaec520e993b84b4a04a7cd3732 Cc: Ignacio Soto Subject: Re: [multimob] New Version Notification for draft-zuniga-multimob-smspmip-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:55:53 -0000 --bcaec520e993b84b4a04a7cd3732 Content-Type: text/plain; charset=ISO-8859-1 Hi all, it seems that the previous link does not work properly when directly clicking on it. Please, try this one to access the new draft version. http://www.ietf.org/id/draft-zuniga-multimob-smspmip-06.txt My apologies for that, regards, Luis 2011/7/11 Luis M. Contreras > Dear all, > > we have just posted an updated version of the multicast solution proposal > draft-zuniga-multimob-smspmip. > > > > You can find the new draft at the following link: > > http://www.ietf.org/id/draft-zuniga-multimob-smspmip-06.txt > > > > best regards, > > > Luis > > > ---------- Forwarded message ---------- > From: > Date: 2011/7/11 > Subject: New Version Notification for draft-zuniga-multimob-smspmip-06.txt > To: contreras.uc3m@gmail.com > Cc: akbar.rahman@interdigital.com, contreras.uc3m@gmail.com, > isoto@dit.upm.es, cjbc@it.uc3m.es > > > A new version of I-D, draft-zuniga-multimob-smspmip-06.txt has been > successfully submitted by Luis M. Contreras and posted to the IETF > repository. > > Filename: draft-zuniga-multimob-smspmip > Revision: 06 > Title: Support Multicast Services Using Proxy Mobile IPv6 > Creation date: 2011-07-11 > WG ID: Individual Submission > Number of pages: 22 > > Abstract: > The MULTIMOB group has specified a base solution to support IP > multicasting in a PMIPv6 domain [RFC6224]. In this document, an > enhancement is proposed to the base solution to use a multicast tree > mobility anchor as the topological anchor point for multicast > traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement > provides benefits such as reducing multicast traffic replication and > supporting different PMIPv6 deployments scenarios. > > > > > > The IETF Secretariat > > --bcaec520e993b84b4a04a7cd3732 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

it seems that the previous link does not work properly w= hen directly clicking on it.

Please, try this one to access the new = draft version.

http://www.ietf.org/id/draft-zuniga-multimob-smspmip-06.= txt

My apologies for that,

regards,

Luis


2011/7/11 Luis M. Contreras <contreras.uc3m@gmail.com>
Dear all,

we have just posted an updated version of the multic= ast solution proposal draft-zuniga-multimob-smspmip.

=A0

You can find the new draft at the following link:

=A0

best regards,

=A0

Luis


---------- For= warded message ----------
From: <internet-drafts@ietf.org>
Date: 2011/7/11
Subject: New Version Notification for draft-zuniga-multi= mob-smspmip-06.txt
To: contreras.uc3m@gmail.com
Cc: akbar.rahman@interdigital.com,= contreras.uc= 3m@gmail.com, iso= to@dit.upm.es, cjb= c@it.uc3m.es


A new version of I-D, draft= -zuniga-multimob-smspmip-06.txt has been successfully submitted by Luis M. = Contreras and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-zuniga-multimob-smspmip
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Support Multicast Services Using Proxy Mobile IP= v6
Creation date: =A0 2011-07-11
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 22

Abstract:
=A0 The MULTIMOB group has specified a base solution to support IP
=A0 multicasting in a PMIPv6 domain [RFC6224]. In this document, an
=A0 enhancement is proposed to the base solution to use a multicast tree =A0 mobility anchor as the topological anchor point for multicast
=A0 traffic, while the MAG remains as an IGMP/MLD proxy. This enhancement<= br> =A0 provides benefits such as reducing multicast traffic replication and =A0 supporting different PMIPv6 deployments scenarios.





The IETF Secretariat


--bcaec520e993b84b4a04a7cd3732-- From contreras.uc3m@gmail.com Mon Jul 11 09:38:49 2011 Return-Path: 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 0FF9211E80E2 for ; Mon, 11 Jul 2011 09:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 9iZS72C0m6h6 for ; Mon, 11 Jul 2011 09:38:48 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id F038E11E80AF for ; Mon, 11 Jul 2011 09:38:43 -0700 (PDT) Received: by pvh18 with SMTP id 18so4204600pvh.31 for ; Mon, 11 Jul 2011 09:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9FQYMfP8dSd78+3lJJJ5ILxffhJN7TQY17LKUbw+d1M=; b=GKbaLz51ezYpn6Br1Z5rovuwfzWCgQba7IufgX1bz+RN6Kd70/NgeA29tl7XwnTtvF iB1H7b/ajXxiLlO76VQc2S14WArAVfABQdtzij+4rcSndUcPeZQWOyIBiyBf5AbadQR1 P8ibMmM2zRSc3tslTkUTmfNokk8zSOQG70C/I= MIME-Version: 1.0 Received: by 10.68.47.132 with SMTP id d4mr6763651pbn.359.1310402323570; Mon, 11 Jul 2011 09:38:43 -0700 (PDT) Received: by 10.68.40.5 with HTTP; Mon, 11 Jul 2011 09:38:43 -0700 (PDT) In-Reply-To: <20110711163414.20332.63579.idtracker@ietfa.amsl.com> References: <20110711163414.20332.63579.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 18:38:43 +0200 Message-ID: From: "Luis M. Contreras" To: multimob@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a733a02604604a7cdd12c Cc: Ignacio Soto Subject: [multimob] Fwd: New Version Notification for draft-contreras-multimob-rams-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:38:49 -0000 --bcaec51a733a02604604a7cdd12c Content-Type: text/plain; charset=ISO-8859-1 Dear all, we have just uploaded an updated version of draft-contreras-multimob-rams, contributing to the set of solutions proposed for defining mechanisms to optimize multicast traffic during a handover. The new version can be found at: http://tools.ietf.org/html/draft-contreras-multimob-rams-01 Best regards, Luis ---------- Forwarded message ---------- From: Date: 2011/7/11 Subject: New Version Notification for draft-contreras-multimob-rams-01.txt To: contreras.uc3m@gmail.com Cc: contreras.uc3m@gmail.com, isoto@dit.upm.es, cjbc@it.uc3m.es A new version of I-D, draft-contreras-multimob-rams-01.txt has been successfully submitted by Luis Contreras and posted to the IETF repository. Filename: draft-contreras-multimob-rams Revision: 01 Title: Rapid acquisition of the MN multicast subscription after handover Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 33 Abstract: A new proposal is presented for speeding up the acquisition by the MAG of the MN's active multicast subscription information, in order to accelerate the multicast delivery to the MN during handover. To do that, an extension of the current PMIPv6 protocol is required. The solution described in this memo is not only applicable to the base multicast solution, but also it can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, it is also independent of the role played by the MAG within the multicast metwork (either acting as MLD proxy or multicast router). The IETF Secretariat --bcaec51a733a02604604a7cdd12c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

we have just uploaded an updated version of draft-contrera= s-multimob-rams, contributing to the set of solutions proposed for defining= mechanisms to optimize multicast traffic during a handover.

The new= version can be found at:
htt= p://tools.ietf.org/html/draft-contreras-multimob-rams-01

Best re= gards,

Luis


---------- Forward= ed message ----------
From: <internet-drafts@ietf.org>
= Date: 2011/7/11
Subject: New Version Notification for draft-contreras-mu= ltimob-rams-01.txt
To: contreras.uc3m@gmail.com
Cc: contreras.uc3m@gmail.c= om, isoto@dit.upm.es, cjbc@it.uc3m.es


A new version of I-D, draft-contreras-multimob-rams-01.txt has been= successfully submitted by Luis Contreras and posted to the IETF repository= .

Filename: =A0 =A0 =A0 =A0draft-contreras-multimob-rams
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Rapid acquisition of the MN multicast subscripti= on after handover
Creation date: =A0 2011-07-11
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 33

Abstract:
=A0 A new proposal is presented for speeding up the acquisition by the
=A0 MAG of the MN&#39;s active multicast subscription information, in = order
=A0 to accelerate the multicast delivery to the MN during handover. To do<= br> =A0 that, an extension of the current PMIPv6 protocol is required. The
=A0 solution described in this memo is not only applicable to the base
=A0 multicast solution, but also it can be applied to other solutions
=A0 envisioned as possible architectural evolutions of it. Furthermore, =A0 it is also independent of the role played by the MAG within the
=A0 multicast metwork (either acting as MLD proxy or multicast router).




The IETF Secretariat

--bcaec51a733a02604604a7cdd12c-- From internet-drafts@ietf.org Mon Jul 11 10:14:27 2011 Return-Path: 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 6183911E8112; Mon, 11 Jul 2011 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 13NBVycRxxu2; Mon, 11 Jul 2011 10:14:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE26411E80EB; Mon, 11 Jul 2011 10:14:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711171426.2622.51120.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 10:14:26 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-igmp-mld-tuning-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 17:14:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of t= he IETF. Title : Tuning the Behavior of IGMP and MLD for Routers in Mobil= e and Wireless Networks Author(s) : Hitoshi Asaeda Hui Liu Qin Wu Filename : draft-ietf-multimob-igmp-mld-tuning-01.txt Pages : 18 Date : 2011-07-11 IGMP and MLD are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility, and aims to become a guideline for query and other timers and values tuning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-01.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-01.t= xt From behcetsarikaya@yahoo.com Mon Jul 11 11:36:41 2011 Return-Path: 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 203EB11E813B for ; Mon, 11 Jul 2011 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_50=0.001] 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 gYoido-EDByS for ; Mon, 11 Jul 2011 11:36:40 -0700 (PDT) Received: from nm13.bullet.mail.sp2.yahoo.com (nm13.bullet.mail.sp2.yahoo.com [98.139.91.83]) by ietfa.amsl.com (Postfix) with SMTP id 922C011E8104 for ; Mon, 11 Jul 2011 11:36:40 -0700 (PDT) Received: from [98.139.91.67] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 18:36:37 -0000 Received: from [98.139.91.51] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 18:36:37 -0000 Received: from [127.0.0.1] by omp1051.mail.sp2.yahoo.com with NNFMP; 11 Jul 2011 18:36:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 252834.727.bm@omp1051.mail.sp2.yahoo.com Received: (qmail 23247 invoked by uid 60001); 11 Jul 2011 18:36:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310409396; bh=0TMypT7KLIy/Eq5C9QqCp8bae6sD8WXUyYEp3vRIqeY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GyIpxFxBSuAsU0BkYjT08TlAgzrGfV9oZhvtGeKdHz7ZKsjv2nuMlUlcCYqldmfYNdLC2U7G4+gCaJGGlXspbf8GCyYQl7R2f9ZS12NQxo8NRQKqdYF4Wm26Ekvp3JCu76RGugKC72WIOhd5VyjzjDSQ0tqHmivaVLyn+O/YrIA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=qIMlhQ6cXzKyyrGoDVmo2lXClMkh0BrTlAVYQtxNpC4Tk9zjp/KJCj9q8JvuRszPPlCdElXMdRXSAp10ajadUfvWIlr0cPwXqTFAkdazVaBOWFn9/gKx45JRw5Y6zesMg/n6GQq23Idih4b0Tye/xGXzSiD7nc5ic7e6ix2mJRY=; X-YMail-OSG: r2BvSZYVM1lOcTE0DjqfaApJnC_Y_U88pKTiYFxcB6yl0vX GkoM- Received: from [50.58.7.243] by web111408.mail.gq1.yahoo.com via HTTP; Mon, 11 Jul 2011 11:36:36 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 Message-ID: <1310409396.6081.YahooMailRC@web111408.mail.gq1.yahoo.com> Date: Mon, 11 Jul 2011 11:36:36 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Presentations X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 18:36:41 -0000 Hi Folks, It seems like the agenda is now stable. It is time to get the presentations. Please send your presentation to the chairs. Regards, Behcet From sijeon79@gmail.com Mon Jul 11 18:16:25 2011 Return-Path: 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 AAE9F11E8354 for ; Mon, 11 Jul 2011 18:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 P9q01B+9-pY7 for ; Mon, 11 Jul 2011 18:16:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1571911E8213 for ; Mon, 11 Jul 2011 18:16:25 -0700 (PDT) Received: by iye7 with SMTP id 7so5103996iye.31 for ; Mon, 11 Jul 2011 18:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:x-mimeole:thread-index; bh=2+So9hOsw+GGlNUY733Znr/0sK56eyqkFmfCO/TEqwY=; b=oqIa25HJ9/Wqv5U82gPMapHtQ7wBFF2xxQ6DVFLh7K2VN5CfMSoFeeW18ELazkFfeR P6+oPHT/8d2Dc2xXdhXw8o7cYymWpnk+FsLftHyYiQM3jun8nLPmUDR0hM3JON9A+Zrq ydXlTsrXeOkuO+haNxSnQrVi81dTn8CnmN6Mg= Received: by 10.42.246.67 with SMTP id lx3mr6373358icb.52.1310433383974; Mon, 11 Jul 2011 18:16:23 -0700 (PDT) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id my4sm8031223ibb.3.2011.07.11.18.16.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 18:16:23 -0700 (PDT) From: "Seil Jeon" To: Date: Tue, 12 Jul 2011 10:16:13 +0900 Message-ID: <0137F877CFE54BA08D374CBF316426BF@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 thread-index: Acw/salbl0SXsc1dT3GAYrVCsAOzLQAf09Hw Subject: [multimob] FW: New Version Notification fordraft-sijeon-multimob-direct-routing-pmip6-01.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 01:16:25 -0000 Hi,multimob folks, This is a update version of direct routing solution. Compared to previous version, applicability under a few of constraints have been added. Best regards, Seil Jeon --------------------------------------------------------- Soongsil Univ. Ubiquitous Network Research Center (SUNRC) 511 Sangdo-dong, Dongjak-gu, Seoul Tel. +82-2-820-0841 Homepage: http://sites.google.com/site/seiljeon -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 11, 2011 7:03 PM To: sijeon@dcn.ssu.ac.kr Cc: sijeon@dcn.ssu.ac.kr; yhkim@dcn.ssu.ac.kr Subject: New Version Notification fordraft-sijeon-multimob-direct-routing- pmip6-01.txt A new version of I-D, draft-sijeon-multimob-direct-routing-pmip6-01.txt has been successfully submitted by Seil Jeon and posted to the IETF repository. Filename: draft-sijeon-multimob-direct-routing-pmip6 Revision: 01 Title: PMIPv6 Multicasting Support using Native Infrastructure Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 13 Abstract: To support IP multicasting in PMIPv6 domain, [RFC6424] has been determined as a base solution. This solution requires all the LMA to forward multicast packets to MAG via PMIPv6 tunnel. This approach creates a tunnel convergence problem. To resolve the issue, the current MULTIMOB WG charter is trying to draw a solution about how to separate multicasting routing from a mobility anchor. To address the issue, we propose the local routing approach that makes the direct connection between MAG and multicast router. The advantages of the proposed local routing solution are compared with the base solution and dedicated LMA approach. In addition, we present the applicability of local routing solution depending on several constraints. The IETF Secretariat From schmidt@informatik.haw-hamburg.de Wed Jul 13 04:45:52 2011 Return-Path: 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 18CE621F8A64 for ; Wed, 13 Jul 2011 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AVZR7Bl1GhYl for ; Wed, 13 Jul 2011 04:45:48 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 05A9C21F8A67 for ; Wed, 13 Jul 2011 04:45:47 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.26.184] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qgxsw-0003C7-IB; Wed, 13 Jul 2011 13:45:46 +0200 Message-ID: <4E1D8567.9070502@informatik.haw-hamburg.de> Date: Wed, 13 Jul 2011 13:45:43 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <8054.73450.qm@web111406.mail.gq1.yahoo.com> <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A25B86B6639@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: rkoodli@cisco.com, multimob@ietf.org Subject: Re: [multimob] Session in IETF-81: Multicast Context Transfer for Mobility Protocol Standards X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 11:45:52 -0000 Dear Dirk, first of all many thanks for your careful review! While I was away, Matthias has answered to most of your questions / issues ... so let me just add a few details. On 07.07.2011 14:37, Dirk.von-Hugo@telekom.de wrote: > though your handover related draft draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04 had not changed much since last session ... Yes, we actually wait for progress with this document - actually, the first draft is from San Francisco IETF (years back ;) ). > > First of all I like the simple idea for the NMAG/NAR to just send MLD to PMAG/PAR to receive 'old' multicast data. It only might complicate things when MAG and LMA are native multicast routers by having to add MLD proxy functionality. Actually, as a full mcast router you are not required to have an additional MLD proxy functionality. All you need is the ability to parse MLD records (which is normally present at routers). Whenever you are a full router, you can use the NAR-PAR tunnel as a Multicast-enabled link, which is identical to MLD proxying (for that uplink) here. > I wonder whether in reactive scenario without buffering at PMAG/PAR a loss of data may occur before NMAG-NAR has completed subscription ... As Matthias wrote: there is packet loss (like in the unicast case) which we analyzed and quantified in Reference [FMIPv6-Analysis]. > > Some minor observations: > > Saying on page 6: > On reception of the HI message, NAR returns a multicast acknowledgement in its HACK answer > that indicates its ability to support each requested group > > Doesn't this imply in Figs. 2 and 4 that "Join to multicast groups" at NMAG/NAR has to occur _before_ replying to PMAG/PAR with "HAck(Multicast AckOpt)" because otherwise NMAG/NAR cannot confirm ist ability? > As Matthias said: this is not a report on mcast routing success, thus not generated from actual packet observation. > And just for clarification: In Fig.3 the RtSolPr/PrRtAdv is meant to happen between MN and PAR (as fepicted) to show the previous attachment, and not between MN and NAR, corresponding to sect. 4.1.3. saying: > NAR will advertise its multicast support by setting the M-bit in > PrRtAdv. > RtSolPr/PrRtAdv is the general client signaling of FMIPv6. So it occurs between MN and all ARs. I guess, the rest was already exhaustively discussed. See you in Quebec! Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Fri Jul 15 09:33:20 2011 Return-Path: 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 BF75621F8B31 for ; Fri, 15 Jul 2011 09:33:20 -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 r02gRsrC-UMb for ; Fri, 15 Jul 2011 09:33:20 -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 32DA721F8AB0 for ; Fri, 15 Jul 2011 09:33:16 -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 08B8F27811D for ; Sat, 16 Jul 2011 01:32:45 +0900 (JST) Date: Sat, 16 Jul 2011 01:32:44 +0900 (JST) Message-Id: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda 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 Subject: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:33:20 -0000 Hello folks, We revised our PMIPv6 extension draft as follows: http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06 This draft specifies the scenario in which both LMA and MAG act as PIM-SM routers. This draft addresses the tunnel convergence problem and provides seamless handover. It defines Proxy Binding Update and Proxy Binding Acknowledgement messages with multicast extension. Comments welcome. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Mon Jul 18 19:03:49 2011 Return-Path: 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 590CA21F86C0 for ; Mon, 18 Jul 2011 19:03:49 -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 mYOpcs8TbhbK for ; Mon, 18 Jul 2011 19:03:48 -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 CC5EC21F86AE for ; Mon, 18 Jul 2011 19:03:47 -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 4E0C82780E1 for ; Tue, 19 Jul 2011 11:03:15 +0900 (JST) Date: Tue, 19 Jul 2011 11:03:13 +0900 (JST) Message-Id: <20110719.110313.182753311.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> 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 Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 02:03:49 -0000 Hi folks, > We revised our PMIPv6 extension draft as follows: > > http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06 > > This draft specifies the scenario in which both LMA and MAG act as > PIM-SM routers. This draft addresses the tunnel convergence problem > and provides seamless handover. It defines Proxy Binding Update and > Proxy Binding Acknowledgement messages with multicast extension. I'd like to summarize the points this document focuses on. 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 addition, only enabling PIM-SM on MAG and LMA does not provide mobility. Therefore this document also provides handover mechanisms by adopting the standard PBU/PBA messages with multicast extension or using Policy Store maintaining subscribing multicast channel list. Note that, to simplyfy the protocol extension, this document does not provide any "fast" handover mechanism, such as link-layer specific mechanisms (e.g. scan in WLAN), prediction for movement, data pre-forwarding, and so on. 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 Thank you for your attention. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Jul 19 08:12:10 2011 Return-Path: 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 A9BBA21F88D9 for ; Tue, 19 Jul 2011 08:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599] 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 h2ffN4JLWsXX for ; Tue, 19 Jul 2011 08:12:10 -0700 (PDT) Received: from nm4-vm3.bullet.mail.ne1.yahoo.com (nm4-vm3.bullet.mail.ne1.yahoo.com [98.138.91.134]) by ietfa.amsl.com (Postfix) with SMTP id 8C27621F8599 for ; Tue, 19 Jul 2011 08:12:09 -0700 (PDT) Received: from [98.138.90.51] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 15:12:06 -0000 Received: from [98.138.89.246] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 15:12:06 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 19 Jul 2011 15:12:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 174178.58821.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 24562 invoked by uid 60001); 19 Jul 2011 15:12:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311088325; bh=/uDOi41ELJ5o+H5nGIXth35qBgj6d+QnZGP6dx5vn8I=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=HKaiSZzlSpKfCfhwMbhHhI/avAo3KfxwLe3GkI1GUNAR1zh1p0KXZXix59bGnKPBmliMCw01kpN60YZi5kgSgdl3UPslnESBrB2XX+h78Waw4Uv7f1h5w2sC66RzSaLzYNHiCMnY6YR6/So1XBjsap/WgofP5HHuXPCc2/MWM3s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Bv73pbH3iBOrbUMYALSbI6EVwOPZa6AqUlwVt+NYHGTHVCKyOSRNIEZmfmnsgndPdarDFCzfhKTWmz5qDS+9QQNnhN68SnnPNGXn/4mk/CHRdxss77FYr13dMIrUqsYRfnryJHWQfwQmrHk7o2RqPiOMcau7txD4SW1AnNd/pWM=; X-YMail-OSG: rQTqSCMVM1nQR79r8ySTaQB5lMclZMhu8BZQcU7TnLiruC2 N3EigCMaV2DuZFaFaUJCEVGdbgpQzcr.uYCImhLpU6Sxzeku6m9izpIUyrI8 uXsF7VCaxEnTYutvKntGSbg1GITvFng2FleD3uwWXEF3nBtEcyZH3CIT6uRK 1UkP7A9gdLdj9S5L6U434gCGqINQdNAT.AquX.eFAajHMsopb2fLA.93hf5Z 8p_rB2UmYBBcBXmOCEMEniMnlw29mKedjwIsdDQPrOKiYVveI3idIu0Xw9NE RBkr7aWZfimC8lnm8ErpG.CPtWYjN7PRfm4yH6l_AnJX20ShIRAmpbmhLPRZ Uxdw0Wh3eIPPsvb46SjQxWIQjADfwaQWohIk79YQypBBHN8ynKnSkkWVrqvS 3R.won6AU1JE8i3yvfaJVZwcq.kOt3Uns_qQKtTgEtAT7JsvZQRpKgVOXPjm ua0H2fTZ8Wnaic0vSel9Pc7KxwT6S0Aww94Bm89bg7IpDlL9H0uzgsmZceuc yvE9YLURC0g-- Received: from [50.58.7.243] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 19 Jul 2011 08:12:05 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <20110719.110313.182753311.asaeda@sfc.wide.ad.jp> Message-ID: <1311088325.90824.YahooMailRC@web111406.mail.gq1.yahoo.com> Date: Tue, 19 Jul 2011 08:12:05 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , multimob@ietf.org In-Reply-To: <20110719.110313.182753311.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:12:10 -0000 > Hi folks, > > > We revised our PMIPv6 extension draft as follows: > > > > http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06 > > > > This draft specifies the scenario in which both LMA and MAG act as > > PIM-SM routers. This draft addresses the tunnel convergence problem > > and provides seamless handover. It defines Proxy Binding Update and > > Proxy Binding Acknowledgement messages with multicast extension. > > I'd like to summarize the points this document focuses on. > > 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? 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. > In addition, only enabling PIM-SM on MAG and LMA does not provide > mobility. Therefore this document also provides handover mechanisms by > adopting the standard PBU/PBA messages with multicast extension or > using Policy Store maintaining subscribing multicast channel list. > > Note that, to simplyfy the protocol extension, this document does not > provide any "fast" handover mechanism, such as link-layer specific > mechanisms (e.g. scan in WLAN), prediction for movement, data > pre-forwarding, and so on. > 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? Regards, Behcet From asaeda@sfc.wide.ad.jp Tue Jul 19 18:58:15 2011 Return-Path: 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 ; 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 ; 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 ; 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 (JST) Message-Id: <20110720.105741.120440517.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From gaoxlh@gmail.com Wed Jul 20 00:37:02 2011 Return-Path: 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 BAD5921F893E for ; Wed, 20 Jul 2011 00:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.463 X-Spam-Level: ** X-Spam-Status: No, score=2.463 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 CqAsZRDeoPdk for ; Wed, 20 Jul 2011 00:37:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3AE621F8779 for ; Wed, 20 Jul 2011 00:36:58 -0700 (PDT) Received: by iye7 with SMTP id 7so5197173iye.31 for ; Wed, 20 Jul 2011 00:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=kUHvjmYH9u4hCa6LR2MgsE63rc+fPvyxU/cRr0nyRoM=; b=ZIyR+Q7FLnU9L3sFeheNXUr+N+boD5F7jHmWYNCcKgyBNe8J0PCkHY03hdo1khi3rI +W1/itHAIpNuwGrj4vMhuI3w+UyP1zvT2bSk+w4svcf/BRGspW2OIXDY0HRFsWMkm945 MsVoKbj11xzE8k0hcnnk9UaWSDbjQTYTIW0G8= Received: by 10.231.52.209 with SMTP id j17mr2524302ibg.94.1311147418334; Wed, 20 Jul 2011 00:36:58 -0700 (PDT) Received: from gao-PC ([211.71.74.133]) by mx.google.com with ESMTPS id q13sm4132136ibi.9.2011.07.20.00.36.56 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 00:36:57 -0700 (PDT) Date: Wed, 20 Jul 2011 15:36:54 +0800 From: "Shuai Gao" To: "Hitoshi Asaeda" References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> Message-ID: <201107201536525272109@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: multimob Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 07:37:02 -0000 SGksIEhpdG9zaGksDQoNCgkgSW4geW91ciBkcmFmdCwgaXQncyBtZW50aW9uZWQgdGhhdCB0aGUg TUFHIHNlbmRzIFBJTSBKb2luIG1lc3NhZ2UgdG8gaXRzIG5laWdoYm9yaW5nIHJvdXRlciAodXBz dHJlYW0gcm91dGVyKS4gIEFuZCB0aGUgdXBzdHJlYW0gbGluayBpcyBzZWxlY3RlZCBieSB0aGUg UlBGIGFsZ29yaXRobS4gVGhhdCBpcywgdGhlIHVwc3RyZWFtIHJvdXRlciBpcyBkZXBlbmRlbnQg b24gdGhlIG5ldHdvcmsgdG9wb2xvZ3k/ICBJZiB0aGUgdXBzdHJlYW0gcm91dGVyIGlzIG5vdCBh IExNQSwgeW91IGNob29zZSBhIGRpcmVjdCBhbmQgbmF0aXZlIHJvdXRpbmcuIElzIHRoaXMgc2Ft ZSBhcyB0aGUgc29sdXRpb24gcHJvcG9zZWQgYnkgc2lqZW9uIGluIGRyYWZ0LXNpamVvbi1tdWx0 aW1vYi1kaXJlY3Qtcm91dGluZy1wbWlwNi0wMT8gIA0KCUFuZCBpZiB0aGUgdXBzdHJlYW0gcm91 dGVyIGlzIHRoZSBMTUEsIHRoZSBNLXR1bm5lbCBpcyBnZW5lcmF0ZWQgYW5kIHVzZWQgZm9yIG11 bGljYXN0IHRyYW5zbWlzc2lvbi4gIEFjdHVhbHksIHRoZSBMTUEgaXMgYWxzbyBhIGRpcmVjdCBu ZWlnaGJvciBvZiB0aGUgTUFHIGluIHRoaXMgc2NlbmFyaW8uICBJIGRvbid0IHVuZGVyc3RhbmQg dGhlIG5lY2Vzc2l0eSBvZiB0aGUgTS10dW5uZWwuICBUaGUgZGlyZWN0IHJvdXRpbmcgIGRvZXMg bm90IHdvcmsgaW4gdGhpcyBzY2VuYXJpbz8gIE9yIHRoZSBNLXR1bm5lbCBpcyB1c2VkIGZvciBv dGhlciBwdXJwb3NlcywgbGlrZSBmYXN0IGhhbmRvdmVyPw0KDQpSZWdhcmRzLA0KDQpTaHVhaSBH YW8NCgkNCg0KPT09PT09PSAyMDExLTA3LTE5IDEwOjAzOjU3IMT61NrAtNDF1tDQtLXAo7o9PT09 PT09DQoNCj5IaSBmb2xrcywNCj4NCj4+IFdlIHJldmlzZWQgb3VyIFBNSVB2NiBleHRlbnNpb24g ZHJhZnQgYXMgZm9sbG93czoNCj4+IA0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYXNhZWRhLW11bHRpbW9iLXBtaXA2LWV4dGVuc2lvbi0wNg0KPj4gDQo+PiBUaGlzIGRyYWZ0 IHNwZWNpZmllcyB0aGUgc2NlbmFyaW8gaW4gd2hpY2ggYm90aCBMTUEgYW5kIE1BRyBhY3QgYXMN Cj4+IFBJTS1TTSByb3V0ZXJzLiBUaGlzIGRyYWZ0IGFkZHJlc3NlcyB0aGUgdHVubmVsIGNvbnZl cmdlbmNlIHByb2JsZW0NCj4+IGFuZCBwcm92aWRlcyBzZWFtbGVzcyBoYW5kb3Zlci4gSXQgZGVm aW5lcyBQcm94eSBCaW5kaW5nIFVwZGF0ZSBhbmQNCj4+IFByb3h5IEJpbmRpbmcgQWNrbm93bGVk Z2VtZW50IG1lc3NhZ2VzIHdpdGggbXVsdGljYXN0IGV4dGVuc2lvbi4NCj4NCj5JJ2QgbGlrZSB0 byBzdW1tYXJpemUgdGhlIHBvaW50cyB0aGlzIGRvY3VtZW50IGZvY3VzZXMgb24uDQo+DQo+VGhp cyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlIHR1bm5lbCBjb252ZXJnZW5jZSBwcm9ibGVtIGJ5IGFu IFJQRg0KPmxvb2t1cCBhbGdvcml0aG0uIEFsdGhvdWdoIHRoZSBhcHByb2FjaCBpcyBzdHJhaWdo dGZvcndhcmQsIHRoaXMNCj5jb25kaXRpb24gYXNzdW1lcyBib3RoIE1BRyBhbmQgTE1BIGFjdCBh cyBQSU0tU00gcm91dGVycy4NCj5JbiBhZGRpdGlvbiwgb25seSBlbmFibGluZyBQSU0tU00gb24g TUFHIGFuZCBMTUEgZG9lcyBub3QgcHJvdmlkZQ0KPm1vYmlsaXR5LiBUaGVyZWZvcmUgdGhpcyBk b2N1bWVudCBhbHNvIHByb3ZpZGVzIGhhbmRvdmVyIG1lY2hhbmlzbXMgYnkNCj5hZG9wdGluZyB0 aGUgc3RhbmRhcmQgUEJVL1BCQSBtZXNzYWdlcyB3aXRoIG11bHRpY2FzdCBleHRlbnNpb24gb3IN Cj51c2luZyBQb2xpY3kgU3RvcmUgbWFpbnRhaW5pbmcgc3Vic2NyaWJpbmcgbXVsdGljYXN0IGNo YW5uZWwgbGlzdC4NCj4NCj5Ob3RlIHRoYXQsIHRvIHNpbXBseWZ5IHRoZSBwcm90b2NvbCBleHRl bnNpb24sIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QNCj5wcm92aWRlIGFueSAiZmFzdCIgaGFuZG92 ZXIgbWVjaGFuaXNtLCBzdWNoIGFzIGxpbmstbGF5ZXIgc3BlY2lmaWMNCj5tZWNoYW5pc21zIChl LmcuIHNjYW4gaW4gV0xBTiksIHByZWRpY3Rpb24gZm9yIG1vdmVtZW50LCBkYXRhDQo+cHJlLWZv cndhcmRpbmcsIGFuZCBzbyBvbi4NCj5UaGUgcHJvcG9zZWQgbWVjaGFuaXNtIGFpbXMgdG8gYmUg ZmxleGlibGUgYW5kIGdlbmVyYWw7IGl0IGNvdWxkDQo+Y29vcGVyYXRlIHdpdGggb3RoZXIgZmFz dCBoYW5kb3ZlciBtZWNoYW5pc20uIEFzIG9uZSBvZiB0aGUgZXhhbXBsZXMsDQo+dGhpcyBkb2N1 bWVudCByZWZlcnMgdGhlIGlkZWEgb2YgQ1hUUCB3aXRoIG11bHRpY2FzdCBleHRlbnNpb24gKCox KQ0KPmFuZCBpbGx1c3RyYXRlcyB0aGUgc2NlbmFyaW8gdG8gY29vcGVyYXRlIHdpdGggaXQuDQo+ KCoxKSBkcmFmdC12b25odWdvLW11bHRpbW9iLWN4dHAtZXh0ZW5zaW9uLTAwLnR4dA0KPg0KPlRo YW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24uDQo+DQo+UmVnYXJkcywNCj4tLQ0KPkhpdG9zaGkg QXNhZWRhDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5tdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj5tdWx0aW1vYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQog DQoJCQkJIA0KU2h1YWkgR2FvDQpOYXRpb25hbCBFbmdpbmVlcmluZyBMYWIgZm9yIE5leHQgR2Vu ZXJhdGlvbiBJbnRlcm5ldCBJbnRlcmNvbm5lY3Rpb24gRGV2aWNlcw0KQmVpamluZyBKaWFvdG9u ZyBVbml2ZXJzaXR5DQpCZWlqaW5nLCBDaGluYSwgMTAwMDQ0DQpnYW94bGhAZ21haWwuY29tDQoy MDExLTA3LTIwDQoNCg== From asaeda@sfc.wide.ad.jp Wed Jul 20 01:32:58 2011 Return-Path: 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 D24B021F8726 for ; Wed, 20 Jul 2011 01:32:58 -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=[AWL=-0.000, 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 T7Pt3rLWANvX for ; Wed, 20 Jul 2011 01:32:58 -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 4896721F86DB for ; Wed, 20 Jul 2011 01:32:57 -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 3CD01278089; Wed, 20 Jul 2011 17:32:26 +0900 (JST) Date: Wed, 20 Jul 2011 17:32:25 +0900 (JST) Message-Id: <20110720.173225.26932237.asaeda@sfc.wide.ad.jp> To: gaoxlh@gmail.com From: Hitoshi Asaeda In-Reply-To: <201107201536525272109@gmail.com> References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <201107201536525272109@gmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 08:32:58 -0000 Hi Shuai, > In your draft, it's mentioned that the MAG sends PIM Join > message to its neighboring router (upstream router). And the > upstream link is selected by the RPF algorithm. That is, the > upstream router is dependent on the network topology? Yes, correct. > If the > upstream router is not a LMA, you choose a direct and native > routing. Is this same as the solution proposed by sijeon in > draft-sijeon-multimob-direct-routing-pmip6-01? I've just taken a very quick look at this draft. It seems that the proposal is to provide local routing with the MLD proxy function on MAG and a dedicated multicast router. The dedicated multicast router is always MAG's upstream router in this solution. The approach is different from ours. In our proposal, the PIM-SM routing function is enabled on both LMA and MAG. Upstream routers are selected according to the topology. When MAG selects LMA as the upstream router for some multicast channel, MAG sends PIM Join/Prune via M-Tunnel. When MAG selects an adjacent multicast router (i.e. not a foreign LMA) as the upstream router, MAG sends PIM Join/Prune natively. > And if the upstream router is the LMA, the M-tunnel is > generated and used for mulicast transmission. Actualy, the LMA is > also a direct neighbor of the MAG in this scenario. I don't > understand the necessity of the M-tunnel. The direct routing does > not work in this scenario? Or the M-tunnel is used for other > purposes, like fast handover? I cannot understand the statement, "the LMA is also a direct neighbor of the MAG in this scenario". M-Tunnel is a virtual (i.e. tunnel) link. It is used to make LMA as an MAG's neighbor router in the routing protocol. For direct routing (I assume the condition for direct routing and local routing is same), M-Tunnel won't be used, because MAG will recognize the neighbor router, which is not an LMA, without M-Tunnel. M-Tunnel is not relevant to handover. Whether multicast extension is included or not, PBU/PBA messages are transmitted in the regular PMIPv6 procedure (defined in RFC5213). Regards, -- Hitoshi Asaeda From gaoxlh@gmail.com Wed Jul 20 03:00:11 2011 Return-Path: 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 934D021F89A7 for ; Wed, 20 Jul 2011 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.833 X-Spam-Level: ** X-Spam-Status: No, score=2.833 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] 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 7jvWAtNNu5JR for ; Wed, 20 Jul 2011 03:00:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0293021F8892 for ; Wed, 20 Jul 2011 03:00:10 -0700 (PDT) Received: by iwn39 with SMTP id 39so61297iwn.31 for ; Wed, 20 Jul 2011 03:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=a7vcpzMsRgpsZKr5uWaoV7gL2YyyyLeEvpmYI+F2juc=; b=DCJxrXfttkx+wYR8idADT9pS3oQyR7o4UivgN/okFfahRLh3l+/UYizXZd/QiJZ7yr GZF9X2b+g+CFTCUmHtGXGE8fMspXU6shab8rUs18zanS8qt9e2q8mVQvy8R0urlhM4TE ECHVwbtVt9D/pXVtQ2YOzfR8g2ara6laKEap0= Received: by 10.231.82.193 with SMTP id c1mr7759808ibl.177.1311156010270; Wed, 20 Jul 2011 03:00:10 -0700 (PDT) Received: from gao-PC ([211.71.74.133]) by mx.google.com with ESMTPS id j8sm117591icz.16.2011.07.20.03.00.06 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 03:00:08 -0700 (PDT) Date: Wed, 20 Jul 2011 18:00:05 +0800 From: "Shuai Gao" To: "Hitoshi Asaeda" References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp>, <201107201536525272109@gmail.com> Message-ID: <201107201800034811523@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: multimob Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:00:11 -0000 SEksIEhpdG9zaGksDQoNCgkNCg0KPT09PT09PSAyMDExLTA3LTIwIDE2OjMyOjI5IMT61NrAtNDF 1tDQtLXAo7o9PT09PT09DQoNCj5IaSBTaHVhaSwNCj4NCj4+IAkgSW4geW91ciBkcmFmdCwgaXQn cyBtZW50aW9uZWQgdGhhdCB0aGUgTUFHIHNlbmRzIFBJTSBKb2luDQo+PiBtZXNzYWdlIHRvIGl0 cyBuZWlnaGJvcmluZyByb3V0ZXIgKHVwc3RyZWFtIHJvdXRlcikuICBBbmQgdGhlDQo+PiB1cHN0 cmVhbSBsaW5rIGlzIHNlbGVjdGVkIGJ5IHRoZSBSUEYgYWxnb3JpdGhtLiBUaGF0IGlzLCB0aGUN Cj4+IHVwc3RyZWFtIHJvdXRlciBpcyBkZXBlbmRlbnQgb24gdGhlIG5ldHdvcmsgdG9wb2xvZ3k/ DQo+DQo+WWVzLCBjb3JyZWN0Lg0KPg0KPj4gIElmIHRoZQ0KPj4gdXBzdHJlYW0gcm91dGVyIGlz IG5vdCBhIExNQSwgeW91IGNob29zZSBhIGRpcmVjdCBhbmQgbmF0aXZlDQo+PiByb3V0aW5nLiBJ cyB0aGlzIHNhbWUgYXMgdGhlIHNvbHV0aW9uIHByb3Bvc2VkIGJ5IHNpamVvbiBpbg0KPj4gZHJh ZnQtc2lqZW9uLW11bHRpbW9iLWRpcmVjdC1yb3V0aW5nLXBtaXA2LTAxPyAgDQo+DQo+SSd2ZSBq dXN0IHRha2VuIGEgdmVyeSBxdWljayBsb29rIGF0IHRoaXMgZHJhZnQuDQo+SXQgc2VlbXMgdGhh dCB0aGUgcHJvcG9zYWwgaXMgdG8gcHJvdmlkZSBsb2NhbCByb3V0aW5nIHdpdGggdGhlIE1MRA0K PnByb3h5IGZ1bmN0aW9uIG9uIE1BRyBhbmQgYSBkZWRpY2F0ZWQgbXVsdGljYXN0IHJvdXRlci4g VGhlIGRlZGljYXRlZA0KPm11bHRpY2FzdCByb3V0ZXIgaXMgYWx3YXlzIE1BRydzIHVwc3RyZWFt IHJvdXRlciBpbiB0aGlzIHNvbHV0aW9uLg0KPg0KPlRoZSBhcHByb2FjaCBpcyBkaWZmZXJlbnQg ZnJvbSBvdXJzLg0KPkluIG91ciBwcm9wb3NhbCwgdGhlIFBJTS1TTSByb3V0aW5nIGZ1bmN0aW9u IGlzIGVuYWJsZWQgb24gYm90aCBMTUEgYW5kDQo+TUFHLiBVcHN0cmVhbSByb3V0ZXJzIGFyZSBz ZWxlY3RlZCBhY2NvcmRpbmcgdG8gdGhlIHRvcG9sb2d5LiBXaGVuIE1BRw0KPnNlbGVjdHMgTE1B IGFzIHRoZSB1cHN0cmVhbSByb3V0ZXIgZm9yIHNvbWUgbXVsdGljYXN0IGNoYW5uZWwsIE1BRw0K PnNlbmRzIFBJTSBKb2luL1BydW5lIHZpYSBNLVR1bm5lbC4gV2hlbiBNQUcgc2VsZWN0cyBhbiBh ZGphY2VudA0KPm11bHRpY2FzdCByb3V0ZXIgKGkuZS4gbm90IGEgZm9yZWlnbiBMTUEpIGFzIHRo ZSB1cHN0cmVhbSByb3V0ZXIsIE1BRw0KPnNlbmRzIFBJTSBKb2luL1BydW5lIG5hdGl2ZWx5Lg0K DQpNYXliZSBzaWplb24gaXMgbW9yZSBlbGlnaWJsZSB0byBkaXNjdXNzIHRoaXMuIA0KPg0KPj4g CUFuZCBpZiB0aGUgdXBzdHJlYW0gcm91dGVyIGlzIHRoZSBMTUEsIHRoZSBNLXR1bm5lbCBpcw0K Pj4gZ2VuZXJhdGVkIGFuZCB1c2VkIGZvciBtdWxpY2FzdCB0cmFuc21pc3Npb24uICBBY3R1YWx5 LCB0aGUgTE1BIGlzDQo+PiBhbHNvIGEgZGlyZWN0IG5laWdoYm9yIG9mIHRoZSBNQUcgaW4gdGhp cyBzY2VuYXJpby4gIEkgZG9uJ3QNCj4+IHVuZGVyc3RhbmQgdGhlIG5lY2Vzc2l0eSBvZiB0aGUg TS10dW5uZWwuICBUaGUgZGlyZWN0IHJvdXRpbmcgIGRvZXMNCj4+IG5vdCB3b3JrIGluIHRoaXMg c2NlbmFyaW8/ICBPciB0aGUgTS10dW5uZWwgaXMgdXNlZCBmb3Igb3RoZXINCj4+IHB1cnBvc2Vz LCBsaWtlIGZhc3QgaGFuZG92ZXI/DQo+DQo+SSBjYW5ub3QgdW5kZXJzdGFuZCB0aGUgc3RhdGVt ZW50LCAidGhlIExNQSBpcyBhbHNvIGEgZGlyZWN0IG5laWdoYm9yDQo+b2YgdGhlIE1BRyBpbiB0 aGlzIHNjZW5hcmlvIi4NCj5NLVR1bm5lbCBpcyBhIHZpcnR1YWwgKGkuZS4gdHVubmVsKSBsaW5r LiBJdCBpcyB1c2VkIHRvIG1ha2UgTE1BIGFzIGFuDQo+TUFHJ3MgbmVpZ2hib3Igcm91dGVyIGlu IHRoZSByb3V0aW5nIHByb3RvY29sLg0KDQpIZXJlLCBJIGFtIGNvbmNlcm5lZCB0aGF0IGhvdyB0 aGUgTE1BIGJlY29tZXMgdGhlIHVwc3RyZWFtIHJvdXRlci4gIEkgdGhpbmsgdGhhdCB0aGUgTE1B IGlzIGNvbm5lY3RlZCB3aXRoIHRoZSBNQUcgZGlyZWN0bHkgaWYgdGhlIExNQSBhcmUgc2VsZWN0 ZWQgYXMgdGhlIHVwc3RyZWFtIHJvdXRlciBieSB0aGUgUlBGIGFsZ29yaXRobS4gICBJZiBub3Qs IHRoZSBMTUEgYmVjb21lcyB0aGUgdXBzdHJlYW0gcm91dGVyIHdoZW4gdGhlIE1BRyBoYXMgbm90 IG5laWdoYm9yIHJvdXRlciB0aGF0IGRvZXMgc3VwcG9ydHMgUElNLVNNPyANCg0KPkZvciBkaXJl Y3Qgcm91dGluZyAoSSBhc3N1bWUgdGhlIGNvbmRpdGlvbiBmb3IgZGlyZWN0IHJvdXRpbmcgYW5k DQo+bG9jYWwgcm91dGluZyBpcyBzYW1lKSwgTS1UdW5uZWwgd29uJ3QgYmUgdXNlZCwgYmVjYXVz ZSBNQUcgd2lsbA0KPnJlY29nbml6ZSB0aGUgbmVpZ2hib3Igcm91dGVyLCB3aGljaCBpcyBub3Qg YW4gTE1BLCB3aXRob3V0IE0tVHVubmVsLg0KPg0KPk0tVHVubmVsIGlzIG5vdCByZWxldmFudCB0 byBoYW5kb3Zlci4NCj5XaGV0aGVyIG11bHRpY2FzdCBleHRlbnNpb24gaXMgaW5jbHVkZWQgb3Ig bm90LCBQQlUvUEJBIG1lc3NhZ2VzIGFyZQ0KPnRyYW5zbWl0dGVkIGluIHRoZSByZWd1bGFyIFBN SVB2NiBwcm9jZWR1cmUgKGRlZmluZWQgaW4gUkZDNTIxMykuDQo+DQo+UmVnYXJkcywNCj4tLQ0K PkhpdG9zaGkgQXNhZWRhDQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PQ0KCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSANClNodWFpIEdhbw0K TmF0aW9uYWwgRW5naW5lZXJpbmcgTGFiIGZvciBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQgSW50 ZXJjb25uZWN0aW9uIERldmljZXMNCkJlaWppbmcgSmlhb3RvbmcgVW5pdmVyc2l0eQ0KQmVpamlu ZywgQ2hpbmEsIDEwMDA0NA0KZ2FveGxoQGdtYWlsLmNvbQ0KMjAxMS0wNy0yMA0KDQo= From asaeda@sfc.wide.ad.jp Wed Jul 20 03:26:17 2011 Return-Path: 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 B32C921F86E5 for ; Wed, 20 Jul 2011 03:26:17 -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 82IJ0l2GxslB for ; Wed, 20 Jul 2011 03:25:55 -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 BF1EA21F86E1 for ; Wed, 20 Jul 2011 03:25:55 -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 D976A278110; Wed, 20 Jul 2011 19:25:23 +0900 (JST) Date: Wed, 20 Jul 2011 19:25:23 +0900 (JST) Message-Id: <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> To: gaoxlh@gmail.com From: Hitoshi Asaeda In-Reply-To: <201107201800034811523@gmail.com> References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <201107201536525272109@gmail.com> <201107201800034811523@gmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:26:17 -0000 >>> And if the upstream router is the LMA, the M-tunnel is >>> generated and used for mulicast transmission. Actualy, the LMA is >>> also a direct neighbor of the MAG in this scenario. I don't >>> understand the necessity of the M-tunnel. The direct routing does >>> not work in this scenario? Or the M-tunnel is used for other >>> purposes, like fast handover? >> >>I cannot understand the statement, "the LMA is also a direct neighbor >>of the MAG in this scenario". >>M-Tunnel is a virtual (i.e. tunnel) link. It is used to make LMA as an >>MAG's neighbor router in the routing protocol. > > Here, I am concerned that how the LMA becomes the upstream router. > I think that the LMA is connected with the MAG directly if the LMA > are selected as the upstream router by the RPF algorithm. If not, > the LMA becomes the upstream router when the MAG has not neighbor > router that does supports PIM-SM? Still I cannot understand what point you are concerned. But let me assume that your concern is related to the sequence of M-Tunnel establishment and PIM neighbor discovery. If M-Tunnel is not established between LMA and MAG, MAG cannot discover LMA as one of the PIM neighbor routers according to multicast channel subscription requests given by its downstream nodes (i.e. MNs). Therefore M-Tunnel must be set up between LMA and MAG prior to PIM neighbor discovery. This is mentioned in section 4 such as; "M-Tunnel is established between PIM-SM capable LMA and MAG. It is established in a bootstrap phase of MAG (without detecting a multicast channel subscription request from a mobile node) and kept while the MAG is running." Hope this helps. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed Jul 20 09:26:40 2011 Return-Path: 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 4FFE021F87C7 for ; Wed, 20 Jul 2011 09:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_20=-0.74] 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 zcBxWDn6HR+2 for ; Wed, 20 Jul 2011 09:26:39 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id B9B7C21F855B for ; Wed, 20 Jul 2011 09:26:33 -0700 (PDT) Received: from [98.139.91.63] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 16:26:33 -0000 Received: from [98.139.91.10] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 16:26:33 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 16:26:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 696946.34865.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 7699 invoked by uid 60001); 20 Jul 2011 16:26:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311179193; bh=ewuZVkcfx4Ti2XgnV4Il0O3agy6quNgyxUte9gIsdTg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P5PpNnnp4/J9vbCJ/d0pY9jy1Q25N51ZakT/3ZHYAt/Kpjwv9R9l5cnCtEO+/1dczefV+roiwEHg9vx77EzMJztnvdxXWA2Lt5rBy2QZr4aHk2975AKwy0oshCHL5QFgANhu2PJQ2XpcrxfJg8yvrN16s9f2TEafe/OxC1VWw3A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nE2Vsq1ph7/6XD76JlLxwHr3aJfqbKHqgOc5+PT0XTsGLd5VOogtYNwlRhYP7CYaE/a635RKsc4ILnciiEUcuxKHyYr/SmkIv8JJO+qZMvPxCuTRBMvfKaebbJ0NgkXNdhMFFLXTUj/X7zN5qLZ4+t5F0dUCp8SavICj9Ld3nCk=; X-YMail-OSG: Mml054cVM1mp_3342lEKBtppE6Otxw3rT7VNFzA.jai6Rr6 H6JCU9Nq38oBjPvsDxdsggHIIwjxCxT4JnQfUWwQBM21oC9HxkhsDfCPHzq5 qSUDgpFeAzFvWvpZRXmx2BBWCR.UCN05GnKfdZdznHA_MHkJvtGCK0myV5Ll Q.bR7OiOsJCl7BTHBtNSr.jSt6Jv4FnsVATlN1wk6NAClNXCjR_6N7vFTZq3 .yrP9QOVyrnFVgs0AIOOhhO7WeEw6TkjKtzvauM.Jufot2xhM0ylxPW5FtvK 6ZnHA6LZn2wHpcOOl1WK6ybSZIg9U7_D6Kmt40qeEO3if43dnxokIu68iT_n o4HNndpyXA0iWdp6P4YRVZ.iq9rR6bggTeMneis0Hu4fM7WRf2Sa_oBTP.n6 zHuiGbV8ybn0taQ-- Received: from [50.58.7.243] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 20 Jul 2011 09:26:33 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <201107201536525272109@gmail.com> <201107201800034811523@gmail.com> <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> Message-ID: <1311179193.7275.YahooMailRC@web111402.mail.gq1.yahoo.com> Date: Wed, 20 Jul 2011 09:26:33 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , gaoxlh@gmail.com In-Reply-To: <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:26:40 -0000 Hi Hitoshi, If PIM-SM at the MAG and LMA does not require any protocol extensions, then I think this piece of your draft becomes an alternative to the base solution. So this could have been a better "base" solution. Why then we did not consider it maybe about a year ago? Regards, Behcet > >>> And if the upstream router is the LMA, the M-tunnel is > >>> generated and used for mulicast transmission. Actualy, the LMA is > >>> also a direct neighbor of the MAG in this scenario. I don't > >>> understand the necessity of the M-tunnel. The direct routing does > >>> not work in this scenario? Or the M-tunnel is used for other > >>> purposes, like fast handover? > >> > >>I cannot understand the statement, "the LMA is also a direct neighbor > >>of the MAG in this scenario". > >>M-Tunnel is a virtual (i.e. tunnel) link. It is used to make LMA as an > >>MAG's neighbor router in the routing protocol. > > > > Here, I am concerned that how the LMA becomes the upstream router. > > I think that the LMA is connected with the MAG directly if the LMA > > are selected as the upstream router by the RPF algorithm. If not, > > the LMA becomes the upstream router when the MAG has not neighbor > > router that does supports PIM-SM? > > Still I cannot understand what point you are concerned. > > But let me assume that your concern is related to the sequence of > M-Tunnel establishment and PIM neighbor discovery. > > If M-Tunnel is not established between LMA and MAG, MAG cannot > discover LMA as one of the PIM neighbor routers according to multicast > channel subscription requests given by its downstream nodes (i.e. MNs). > Therefore M-Tunnel must be set up between LMA and MAG prior to PIM > neighbor discovery. > > This is mentioned in section 4 such as; > > "M-Tunnel is established between PIM-SM capable LMA and MAG. It is > established in a bootstrap phase of MAG (without detecting a > multicast channel subscription request from a mobile node) and kept > while the MAG is running." > > Hope this helps. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Thu Jul 21 10:07:40 2011 Return-Path: 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 CA05421F8733 for ; Thu, 21 Jul 2011 10:07:40 -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=[AWL=-0.000, 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 7fsqByNBSFVu for ; Thu, 21 Jul 2011 10:07:40 -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 47AF221F8700 for ; Thu, 21 Jul 2011 10:07:39 -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 6D0042780CA; Fri, 22 Jul 2011 02:07:08 +0900 (JST) Date: Fri, 22 Jul 2011 02:07:07 +0900 (JST) Message-Id: <20110722.020707.167523534.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1311179193.7275.YahooMailRC@web111402.mail.gq1.yahoo.com> References: <201107201800034811523@gmail.com> <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> <1311179193.7275.YahooMailRC@web111402.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:07:40 -0000 Hi Behcet, > If PIM-SM at the MAG and LMA does not require any protocol > extensions, then I think this piece of your draft becomes an > alternative to the base solution. > So this could have been a better "base" solution. Why then we did > not consider it maybe about a year ago? I believe that the combination of the routing protocol and mobility support is required for the best solution. And the combination is descrived in the single document. If the combination includes some extension, then the proposal should be categorized as the extension. This is the situation we have considered and presented in this draft. The point we need to discuss for the further step is whether this draft had better (again) split into two drafts or not; one is the different base solution whose title would be "PMIPv6 multicast support with PIM-SM and M-Tunnel", and the other is the extension proposal, "(P)BU/(P)BA extension for multicast handover". Please discuss it in the meeting. I'll follow the decision made by the group. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Jul 21 11:35:35 2011 Return-Path: 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 7715121F8760 for ; Thu, 21 Jul 2011 11:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001] 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 PWLoPLp0Pgoe for ; Thu, 21 Jul 2011 11:35:35 -0700 (PDT) Received: from nm17-vm1.bullet.mail.sp2.yahoo.com (nm17-vm1.bullet.mail.sp2.yahoo.com [98.139.91.213]) by ietfa.amsl.com (Postfix) with SMTP id 0825F21F85EC for ; Thu, 21 Jul 2011 11:35:35 -0700 (PDT) Received: from [98.139.91.65] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 18:35:31 -0000 Received: from [98.139.91.23] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 18:35:31 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 18:35:31 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 857542.83991.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 98954 invoked by uid 60001); 21 Jul 2011 18:35:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311273331; bh=mzZfvO+mWQDVwfPFtblIdPUgkX6eb0KU1Sj1g3kNSgU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gIEBKbEZaeyN5/GnDIH3XY624PgMbHnH+sta/U/uHsuK2A441q5G46Bbj+mzgIbT+wTkf6o4biA7tr0h2cudN88ZLjRpsUugJtFij8ZeuKfxmPMPl0mVJKhGhH+mY7UtShSb+QK93B+X6yull+QpDC3SUL5hcpMeu7v2oA+ycwM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q8S4L/8RwWcdpngIiX6TWJu4jTQCbMgoWLqyyka2E3Pwnmif0PbBu6LSgp8o/TIHbXXiobf2/ruGAWUrt4e2NbdPDqeebgMo7vl5S2nfOrd0k65u8MJyWGgqHov81nl7/SAyxlA6CTUZPZJJSZx+gPh3KIXUZy0di4shyMv1cYo=; X-YMail-OSG: eDRX3noVM1lQr3Zywvbir5HplaoFm7FnXnAW2_aij.tfvRw zoPKsNGgz9FRAlRREVUrOKkNbvRy4YFgd6yX_1WjBhYhcxjABNw_9cL4v1Q0 IH9JfKMaKtno58xoVah6v70MWcdZQv28f8URy5j0P1P53b0r4Eaab8h2Qy1n vTLSDIwylb7JLxha3w0fqjQzeZw8PVnUBXTt5.Mi6yDABTBOHoHXZwx.NBu7 .3HsNZCdo.a08bJ.GHBlqhWrFzqapClm_I22OEp9RZXbwMSudBDAJHCTRlTb 3Mb9K8tEHJ4WjPEmY1UNJXAiWpTp8J1npdeenP3ZkHog9R50JKGsQ7oyvZ96 C4B49F_cyM1kM7dGgpJrbV61eeFxxmtRzmVUDLySEUuestER.090iZoGgWj. eRJ8S9Bsot88Nbg-- Received: from [50.58.7.243] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 21 Jul 2011 11:35:31 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <201107201800034811523@gmail.com> <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> <1311179193.7275.YahooMailRC@web111402.mail.gq1.yahoo.com> <20110722.020707.167523534.asaeda@sfc.wide.ad.jp> Message-ID: <1311273331.98608.YahooMailRC@web111403.mail.gq1.yahoo.com> Date: Thu, 21 Jul 2011 11:35:31 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110722.020707.167523534.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:35:35 -0000 Hi Hitoshi, Please split the draft into two (one informational one standard track) as soon as IETF draft submissions open up. I have a concern about M-Tunnel. How is it different than MAG-LMA tunnel or the upstream tunnel to the LMA as RFC 6224 calls it? Regards, Behcet > Hi Behcet, > > > If PIM-SM at the MAG and LMA does not require any protocol > > extensions, then I think this piece of your draft becomes an > > alternative to the base solution. > > So this could have been a better "base" solution. Why then we did > > not consider it maybe about a year ago? > > I believe that the combination of the routing protocol and mobility > support is required for the best solution. And the combination is > descrived in the single document. If the combination includes some > extension, then the proposal should be categorized as the extension. > This is the situation we have considered and presented in this draft. > > The point we need to discuss for the further step is whether this > draft had better (again) split into two drafts or not; one is the > different base solution whose title would be "PMIPv6 multicast support > with PIM-SM and M-Tunnel", and the other is the extension proposal, > "(P)BU/(P)BA extension for multicast handover". > > Please discuss it in the meeting. > I'll follow the decision made by the group. > > Regards, > -- > Hitoshi Asaeda > From behcetsarikaya@yahoo.com Thu Jul 21 12:53:07 2011 Return-Path: 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 28D3B21F8829 for ; Thu, 21 Jul 2011 12:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599] 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 LjWDWzdm+wGq for ; Thu, 21 Jul 2011 12:53:06 -0700 (PDT) Received: from nm3-vm1.bullet.mail.sp2.yahoo.com (nm3-vm1.bullet.mail.sp2.yahoo.com [98.139.90.231]) by ietfa.amsl.com (Postfix) with SMTP id AFB9D21F847C for ; Thu, 21 Jul 2011 12:53:06 -0700 (PDT) Received: from [98.139.91.62] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 19:53:06 -0000 Received: from [98.139.91.49] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 19:53:06 -0000 Received: from [127.0.0.1] by omp1049.mail.sp2.yahoo.com with NNFMP; 21 Jul 2011 19:53:06 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 652850.74408.bm@omp1049.mail.sp2.yahoo.com Received: (qmail 76455 invoked by uid 60001); 21 Jul 2011 19:53:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311277986; bh=dZqoNpnMeEzTA7fVHw90ZWmSyI/x0Rxgvelb8yfy5ko=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CIiAS8NbBd4U6I3R+6xo+EYaSXfOapr6GAUHr0Mc5ueqruvxxKx4urys7v7bQP/j9Zi4Jf0Og4JV3+NTmvkm3dtpmsQyT/a6YVl02XTc3taRH/AqoJLn6i5AVbafIOQm0QntBGOTXm26P5JCfmBiKkUd5XUrQ0QQLKBCJWl4V0g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1jMzfGdxUEmbMOzz4GQeeRl9Q9aqPTUFGxb9PdAufjF+RKtdpQE0u8Q+im2BVQewhgJu0mVwsjABaTahuk/iEY8YkAnjqZXcipukYGpBr9gE4OLkB1wqkt5TU5jqiI5kY3yIsqJTvt/MNcykOJ1W0ysQ8jVmJKVTCx5GAaEfZVU=; X-YMail-OSG: .NKGLYcVM1kcDIvNhjzLtTWZWzs7sE_v.0DIdTVXfTDtxu2 feOINZvMKFkEMnCWosFwqzSWHr.G0tjpju5hgaYFTy__emzMvfIwQl8DvHfV _IGslE3GZQ9LLuU8isWaZtaiwArRw3ekLGWLYTy2RCUHIiGBqGcgEh2k14_t 2.Iygrc0wDte1WnfoXHsYNqLzTn_QMIPe31JKk9cY5OUIj3AYl80HVq_UPTU DDOc8T3JXFHkXVqcyKxUjoxPSVKc8jxiBHEsSyoKrxhGV3neig8UbPMZ.M9U WCSd5zGmmAfC2I918iqwpf03fWMUgtWSpRhD8WyPSA5SOuW5Z4lpS56fI0ps SDhirGhOqe4HEp3FrohCx1PfbXbtQ5MxLj2ZtqXiaVYBGZX628DzUVwFvWVo 3mgjoRXdLckF8iA-- Received: from [50.58.7.243] by web111406.mail.gq1.yahoo.com via HTTP; Thu, 21 Jul 2011 12:53:05 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <201107201800034811523@gmail.com> <20110720.192523.10906069.asaeda@sfc.wide.ad.jp> <1311179193.7275.YahooMailRC@web111402.mail.gq1.yahoo.com> <20110722.020707.167523534.asaeda@sfc.wide.ad.jp> <1311273331.98608.YahooMailRC@web111403.mail.gq1.yahoo.com> Message-ID: <1311277985.37544.YahooMailRC@web111406.mail.gq1.yahoo.com> Date: Thu, 21 Jul 2011 12:53:05 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <1311273331.98608.YahooMailRC@web111403.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 19:53:07 -0000 a little bit of correction. If you want your draft to be considered as a solution to the tunnel convergence problem, it could be standards track. > Hi Hitoshi, > Please split the draft into two (one informational one standard track) as >soon > > as IETF draft submissions open up. > I have a concern about M-Tunnel. How is it different than MAG-LMA tunnel or > the upstream tunnel to the LMA as RFC 6224 calls it? > > > Regards, > > Behcet > > > > Hi Behcet, > > > > > If PIM-SM at the MAG and LMA does not require any protocol > > > extensions, then I think this piece of your draft becomes an > > > alternative to the base solution. > > > So this could have been a better "base" solution. Why then we did > > > not consider it maybe about a year ago? > > > > I believe that the combination of the routing protocol and mobility > > support is required for the best solution. And the combination is > > descrived in the single document. If the combination includes some > > extension, then the proposal should be categorized as the extension. > > This is the situation we have considered and presented in this draft. > > > > The point we need to discuss for the further step is whether this > > draft had better (again) split into two drafts or not; one is the > > different base solution whose title would be "PMIPv6 multicast support > > with PIM-SM and M-Tunnel", and the other is the extension proposal, > > "(P)BU/(P)BA extension for multicast handover". > > > > Please discuss it in the meeting. > > I'll follow the decision made by the group. > > > > Regards, > > -- > > Hitoshi Asaeda > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From sijeon79@gmail.com Thu Jul 21 23:29:03 2011 Return-Path: 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 1AFAD11E8071 for ; Thu, 21 Jul 2011 23:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MXjKgsDi33JE for ; Thu, 21 Jul 2011 23:29:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6511E8070 for ; Thu, 21 Jul 2011 23:29:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so1135217gxk.31 for ; Thu, 21 Jul 2011 23:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; bh=AfsHfV41oefusHTzwpUJk02IbrKYJzkKrcvPAnun1HI=; b=Uk5sJVIGb3OQ3APGZcFx3iSOc7SmMxxP+VL3L5b5fykCs0DNHGTgZ8EZMG0X5r7jh8 Z/3PzjBcFlL2QLYzxrxefBRArpvZye4k5af8UokCz1NGOkUS0ERXHeldkw55m5aIM6ss wnt+3jxiyTChFPW+jvfB+gbe89JBlrBeqWCic= Received: by 10.68.62.199 with SMTP id a7mr1644460pbs.286.1311316141284; Thu, 21 Jul 2011 23:29:01 -0700 (PDT) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id q2sm1457225pbj.19.2011.07.21.23.28.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jul 2011 23:28:59 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" Date: Fri, 22 Jul 2011 15:28:49 +0900 Message-ID: <263D66B6DD6949BCBFDFB7E94E4516C4@sijeonPC> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcxG+dMj6XfY3tLMQbmb5pDJT4IxOgBOZUDw X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Cc: multimob@ietf.org Subject: [multimob] FW: PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 06:29:03 -0000 Hi Behcet and folks, The approach of PIM-SM on a MAG proposed by hitoshi may be one of routing optimization solutions.. However, regarding on the using native multicast infrastructure, several options may be possible. A MLD proxy and a MR can be integrated into a one box (MAG) or a MLD proxy can be separated from a MAG. Former case is hitoshi's idea, of course it is not a "MLD proxy instance" but "MLD instance" on downstream of MN-side. Latter case will be our direct routing solution. Relating to the tunnel between MR on MAG and MR on LMA, hitoshi uses GRE tunnel but any tunnel could be used. In direct routing, if we assume that a MR (MR-1) is placed on LMA, a MR (MR- 2) connected to a MAG can be connected with MR-1 through any tunnel mechanism. Except that what kinds of MR protocol we will use or which tunneling mechanism is more proper, overally they look similar. So, I would like to discuss about the several options using native infrastructure. Best your regards, Seil Jeon --------------------------------------------------------- Soongsil Univ. Ubiquitous Network Research Center (SUNRC) 511 Sangdo-dong, Dongjak-gu, Seoul Tel. +82-2-820-0841 Homepage: http://sites.google.com/site/seiljeon -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, July 21, 2011 1:27 AM To: Hitoshi Asaeda; gaoxlh@gmail.com Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast Hi Hitoshi, If PIM-SM at the MAG and LMA does not require any protocol extensions, then I think this piece of your draft becomes an alternative to the base solution. So this could have been a better "base" solution. Why then we did not consider it maybe about a year ago? Regards, Behcet > >>> And if the upstream router is the LMA, the M-tunnel is > >>> generated and used for mulicast transmission. Actualy, the LMA is > >>> also a direct neighbor of the MAG in this scenario. I don't > >>> understand the necessity of the M-tunnel. The direct routing > >>> does not work in this scenario? Or the M-tunnel is used for > >>> other purposes, like fast handover? > >> > >>I cannot understand the statement, "the LMA is also a direct > >>neighbor of the MAG in this scenario". > >>M-Tunnel is a virtual (i.e. tunnel) link. It is used to make LMA as > >>an MAG's neighbor router in the routing protocol. > > > > Here, I am concerned that how the LMA becomes the upstream router. > > I think that the LMA is connected with the MAG directly if the LMA > > are selected as the upstream router by the RPF algorithm. If not, > > the LMA becomes the upstream router when the MAG has not neighbor > > router that does supports PIM-SM? > > Still I cannot understand what point you are concerned. > > But let me assume that your concern is related to the sequence of > M-Tunnel establishment and PIM neighbor discovery. > > If M-Tunnel is not established between LMA and MAG, MAG cannot > discover LMA as one of the PIM neighbor routers according to > multicast channel subscription requests given by its downstream nodes (i.e. MNs). > Therefore M-Tunnel must be set up between LMA and MAG prior to PIM > neighbor discovery. > > This is mentioned in section 4 such as; > > "M-Tunnel is established between PIM-SM capable LMA and MAG. It is > established in a bootstrap phase of MAG (without detecting a > multicast channel subscription request from a mobile node) and kept > while the MAG is running." > > Hope this helps. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Fri Jul 22 09:40:39 2011 Return-Path: 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 C78E021F8B52 for ; Fri, 22 Jul 2011 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_50=0.001] 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 51ycGjxX0adE for ; Fri, 22 Jul 2011 09:40:39 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id 65FF521F8B4C for ; Fri, 22 Jul 2011 09:40:39 -0700 (PDT) Received: from [98.139.91.62] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:40:39 -0000 Received: from [98.139.91.56] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:40:39 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 16:40:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 331953.97361.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 28511 invoked by uid 60001); 22 Jul 2011 16:40:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311352838; bh=aY+yRdYRIBeGdvwHCMzvTdE4PzIQMwvfIFaMC9V8EsI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=4DFvbRUUGYKt+47+IGrRaIzt8wBV30n6vbsUSqbv94biJ5N2epSZZ9LfndRCweQSGCEOaQO0H0XsI6isHhUKKag5pi/DIzHbJpatDRG4U7Z3eWq2NcP6yq3xq2soiEalmCLIYwragDC6sZhsq0KcyiFU3qwmCWENLIbV3gWJdtw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gZSlBgITdXeWTjcE4FsaMPcaHWYqaoJCaT5Eb1S+L6jtfdMSt3C1RFFsGjM0UiTEsthSQwIviwSq9pIdOCL2rKYs1ID7kMzv9hW9gnrO2FmRRr7hUAvQ78aMGISd9gfETeGkYy20ilSO+5K/lFKfsuBwy8ojXa0XStC9wYf7T94=; X-YMail-OSG: d4GjzdgVM1k5LgXxGAjlfVp9_6b3tt7PxspTC3wX68SdgWl ykKz.nTGVSxbPg9MBW7FBJCOQd3m8f66uiNMZ2gd6XVih9rAkTox1rUhrQ7L WNqZMcFVyuwOgq5lA0A7LjljJyVLXo4rgdcFfP3rNGqwSDHQ527JtaJRcKIn 9Oqyd_ySH6HGZQXeeg_ewQKgcw7PseB2p..2UJcjLIIUQxyEKcuS83KnLYEt Qi37mqehQaZ3wqRJRDkW2UBfDvdBv4o.F5qisgsyinsz2NBmLOgEao16OBmV D6pLvq2E3k1Tut4VTwQ53AcSbt5ZmEEm_HFtvY0XTe4LQ7udUST0mguWc932 w_e8ruMiVUlGhht6UG_ML0LSdHc2fmOeKA8ltcsEQx.Eje7tedf13dnhgJR_ 8IRAxHB_pYvKs Received: from [50.58.7.243] by web111416.mail.gq1.yahoo.com via HTTP; Fri, 22 Jul 2011 09:40:38 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 Message-ID: <1311352838.18128.YahooMailRC@web111416.mail.gq1.yahoo.com> Date: Fri, 22 Jul 2011 09:40:38 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Presentations - Final call X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:40:39 -0000 The agenda has been updated. There are still many presentations missing. Our session is Monday morning, please send your presentation ASAP. Behcet From schmidt@informatik.haw-hamburg.de Sun Jul 24 09:24:44 2011 Return-Path: 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 00AE421F8997 for ; Sun, 24 Jul 2011 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.585 X-Spam-Level: X-Spam-Status: No, score=-101.585 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FTAnlZSIAsWb for ; Sun, 24 Jul 2011 09:24:43 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id B554421F88E5 for ; Sun, 24 Jul 2011 09:24:42 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from modemcable227.81-176-173.mc.videotron.ca ([173.176.81.227] helo=[192.168.0.187]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ql1Tt-000D1D-C8; Sun, 24 Jul 2011 18:24:41 +0200 Message-ID: <4E2C474A.5040401@informatik.haw-hamburg.de> Date: Sun, 24 Jul 2011 12:24:42 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 16:24:44 -0000 Hi Hitoshi, hi all, we worked through your revised draft and have the following feedback: For the general, the draft seems to rephrase operations of GRE tunneling, PIM and MLD in your own words which leaves unclear, what actually is the standard protocol behavior (defined elsewhere), and what is particular for your proposal. Understanding is also hindered by observations that are correct, but unrelated to the specific subject, and also statements that are incorrect. In detail, we extracted the following contributions: 1.) Your proposal only addresses SSM (without ever mentioning this) 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs (in addition to PMIP tunnels) 3.) You deploy PIM-SSM on all MAGs and all LMAs Since this scenario experiences the routing convergence problem described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which you should reference, btw.), you define 4.) Some additional smoothing procedures for handover Did we understand this correctly? Our comments on this: Ad 1.): It is legitimate to define solutions solely for SSM, but this should be mentioned right away (in title and abstract). Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large PMIP deployment, you will end up with hundreds to thousands of multicast-induced tunnels at a single LMA. This raises severe scaling & complexity issues, but most likely will be unfeasible for cross-domain PMIP deployments. As these tunnels are static and beyond the control of the PMIP prefix management, there may be issues arising for unicast routing, as well. Ad 3.): PIM-SSM should transparently work on such a dense router mesh. However, multicast routes (selected from RPF) may not turn out to be as described in your draft. After an MN joins (S,G), its MAG selects the upstream according to the unicast route to S. What will this be? Most likely, S is completely "unrelated" to the MN and to its LMA, so the route to S may go wherever the (unicast) routing table of the local MAG points to. In many cases this will be default. In addition, once MN1 has established service of (S,G) at a MAG, a newly arriving MN2 will inherit this service (which is efficient). Now, if MN1 detaches, MN2 will continue to be served on the same route as MN1 did. In the (unlikely) case that MN1 had been subscribed to a "home service" (via its LMA, as suggested in your draft), MN2 continues to consume the "home service" of MN1, even though MN1 is gone. This leads to a picture which is complicated, disadvantageous in policy-based conditions (btw. conflicts with your policy-store solution) and contradicts the PMIP service model. As an intermediate summary: If we understood correctly, up until this point you have defined only a deployment scenario, but no new protocol operations or semantic. So this could simply be activated based on the protocols available today ... but may lead to a quite unexpected outcome ;) Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing dynamics, which may be too slow for smooth handoffs. That's why you define three protocol extensions for smoothing the handover process for multicast (isolated from unicast handover management). Comments on this: * Policy Profile: Your policy is acquired from LMA (after a regular PMIP handover). This is actually the long path & slow procedure, so I don't expect much acceleration here ... in particular, you cannot be faster than unicast (slow) handover. Also: this policy management conflicts with the routing scenario mentioned above. * Extended Proxy Binding Update: This I actually cannot understand. You inform the nMAG of multicast subscriptions prior to handover ... so you do a predictive handover, but you don't define any prediction mechanism. I cannot see how this works ... * CXTP: This context transfer is de-synchronized from the unicast handover, which does not really help in handover acceleration (cannot be faster than unicast, complicates a synchronization later ...). CXTP handover may be interesting in the cases discussed after Prague (a new broadcast access link is selected solely for multicast reception ...). We believe its not the most suitable approach here. So far for the feedback - did we miss(s/s/ -understand) something? Best regards, Thomas & Matthias On 15.07.2011 12:32, Hitoshi Asaeda wrote: > Hello folks, > > We revised our PMIPv6 extension draft as follows: > > http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06 > > This draft specifies the scenario in which both LMA and MAG act as > PIM-SM routers. This draft addresses the tunnel convergence problem > and provides seamless handover. It defines Proxy Binding Update and > Proxy Binding Acknowledgement messages with multicast extension. > > Comments welcome. > > Regards, > -- > Hitoshi Asaeda > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Sun Jul 24 22:16:37 2011 Return-Path: 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 4532D11E807C for ; Sun, 24 Jul 2011 22:16:37 -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 ipAm6fEEykIn for ; Sun, 24 Jul 2011 22:16:36 -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 3693D21F8508 for ; Sun, 24 Jul 2011 22:16:35 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:1c0:2014:5a55:caff:fef6:4c5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 848512780F3; Mon, 25 Jul 2011 14:16:03 +0900 (JST) Date: Mon, 25 Jul 2011 14:16:03 +0900 (JST) Message-Id: <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E2C474A.5040401@informatik.haw-hamburg.de> References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <4E2C474A.5040401@informatik.haw-hamburg.de> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 05:16:37 -0000 Thomas,Matthias > For the general, the draft seems to rephrase operations of GRE > tunneling, PIM and MLD in your own words which leaves unclear, what > actually is the standard protocol behavior (defined elsewhere), and > what is particular for your proposal. Understanding is also hindered > by observations that are correct, but unrelated to the specific > subject, and also statements that are incorrect. I was supprised that you almost misunderstood the document. Please carefully read the document and related RFCs. > In detail, we extracted the following contributions: > > 1.) Your proposal only addresses SSM (without ever mentioning this) Not true. ASM is also supported. > 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs > (in addition to PMIP tunnels) Not correct. Full mesh tunnel is not required. > 3.) You deploy PIM-SSM on all MAGs and all LMAs Not PIM-SSM, but PIM-SM, as the ducument explains. > Since this scenario experiences the routing convergence problem > described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which > you should reference, btw.), you define > > 4.) Some additional smoothing procedures for handover This is correct. > Did we understand this correctly? Unfortunately, you did not understand the document. I give you answer in detail as follows. > Our comments on this: > > Ad 1.): It is legitimate to define solutions solely for SSM, but this > should be mentioned right away (in title and abstract). It supports both ASM and SSM. I don't understand why you believe it is only for SSM. Your mistake comes because I use the words, "multicast channel" or "subscription", in the document? If so, I would add the following terminology in the terminology section; "This document supports both Any-Source Multicast and Source-Specific Multicast [SSM]. Nevertheless, regardless of whether a host specifies source address(es) with multicast address, we use "multicast channel" for multicast service identification and "subscription" for procedure to listen multicast channel. This terminology explanation resolves your misunderstanding? > Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large > PMIP deployment, you will end up with hundreds to thousands of > multicast-induced tunnels at a single LMA. This raises severe scaling > & complexity issues, but most likely will be unfeasible for > cross-domain PMIP deployments. As these tunnels are static and beyond > the control of the PMIP prefix management, there may be issues arising > for unicast routing, as well. Mesh connection is not the requirement. I don't understand why you believe mesh is the requirement. The number of M-Tunnels MAG configures will be usually the same as that of the number of LMAs the MAG communicates with PBU/PBA. > Ad 3.): PIM-SSM should transparently work on such a dense router > mesh. However, multicast routes (selected from RPF) may not turn out > to be as described in your draft. After an MN joins (S,G), its MAG > selects the upstream according to the unicast route to S. What will > this be? Most likely, S is completely "unrelated" to the MN and to its > LMA, so the route to S may go wherever the (unicast) routing table of > the local MAG points to. In many cases this will be default. Both ASM and SSM are supported. Moreover, your claim is very strange. You are saying PIM is disabled on the upstream interface selected by an RPF. But PIM selects an upstream interface only from its PIM neigohbors. > In addition, once MN1 has established service of (S,G) at a MAG, a > newly arriving MN2 will inherit this service (which is > efficient). Now, if MN1 detaches, MN2 will continue to be served on > the same route as MN1 did. In the (unlikely) case that MN1 had been > subscribed to a "home service" (via its LMA, as suggested in your > draft), MN2 continues to consume the "home service" of MN1, even > though MN1 is gone. Selecting a single incoming interface solves the tunnel convergence problem. Allowing multiple incoming interfaces leads the tunnel convergence problem. That's all. > This leads to a picture which is complicated, disadvantageous in > policy-based conditions (btw. conflicts with your policy-store > solution) and contradicts the PMIP service model. Ditto. And information kept in policy profile is independent on the upstream interface selection. So no conflict. > As an intermediate summary: If we understood correctly, up until this > point you have defined only a deployment scenario, but no new protocol > operations or semantic. So this could simply be activated based on the > protocols available today ... but may lead to a quite unexpected > outcome ;) I think most of your claimes are incorrect. > Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing > dynamics, which may be too slow for smooth handoffs. That's why you > define three protocol extensions for smoothing the handover process > for multicast (isolated from unicast handover management). Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow handover will be happen, because no handover mechanism is provided in these standard protocols. Therefore we would propose three possible mechanisms for handover. Operators would select either one according to their implementations, configuration, or policy. > Comments on this: > > * Policy Profile: Your policy is acquired from LMA (after a regular PMIP > * handover). This is actually the long path & slow procedure, so I don't > * expect much acceleration here ... in particular, you cannot be faster > * than unicast (slow) handover. Also: this policy management conflicts > * with the routing scenario mentioned above. Regarding the access to policy profile, there is no difference from rfc5213. See Fig.3 in rfc5213. Only the multicast information kept in policy profile is newly defined in this document. > * Extended Proxy Binding Update: This I actually cannot understand. You > * inform the nMAG of multicast subscriptions prior to handover ... so > * you do a predictive handover, but you don't define any prediction > * mechanism. I cannot see how this works ... No prediction provided in the PBU/PBA extension approach. The PBU/PBA procedure sequences are also not changed from rfc5213. Only the multicast subscription information exchanged with PBU/PBA is newly defined in this document. > * CXTP: This context transfer is de-synchronized from the unicast > * handover, which does not really help in handover acceleration (cannot > * be faster than unicast, complicates a synchronization later ...). > > CXTP handover may be interesting in the cases discussed after Prague > (a new broadcast access link is selected solely for multicast > reception ...). We believe its not the most suitable approach here. The detail specification is described in Dirk's draft. Our draft raises that solution as one of the candidate mechanisms. > So far for the feedback - did we miss(s/s/ -understand) something? In summary, I cannot find any important discussion that should be addressed in the revised draft from your comments, except terminology. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Mon Jul 25 05:11:18 2011 Return-Path: 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 22EDA21F8574 for ; Mon, 25 Jul 2011 05:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 44O1d6qEhCsX for ; Mon, 25 Jul 2011 05:11:17 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 97E0B21F857D for ; Mon, 25 Jul 2011 05:11:16 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from modemcable227.81-176-173.mc.videotron.ca ([173.176.81.227] helo=[192.168.0.187]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlK0A-000E12-Qw; Mon, 25 Jul 2011 14:11:15 +0200 Message-ID: <4E2D5D61.8060504@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 08:11:13 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110716.013244.170374338.asaeda@sfc.wide.ad.jp> <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 12:11:18 -0000 Hi Hitoshi, before going into all the other details: Your draft describes (S,G) joins, only, and refers to and RPF interface selection w.r.t. S. To me, this is SSM with PIM-SSM. ASM with PIM-SM would perform an (*,G) join and the interface selection would follow the direction of a per group configured RP. Let's first clarify what your draft *intends* to talk about. Thomas On 25.07.2011 01:16, Hitoshi Asaeda wrote: > Thomas,Matthias > >> For the general, the draft seems to rephrase operations of GRE >> tunneling, PIM and MLD in your own words which leaves unclear, what >> actually is the standard protocol behavior (defined elsewhere), and >> what is particular for your proposal. Understanding is also hindered >> by observations that are correct, but unrelated to the specific >> subject, and also statements that are incorrect. > > I was supprised that you almost misunderstood the document. > Please carefully read the document and related RFCs. > >> In detail, we extracted the following contributions: >> >> 1.) Your proposal only addresses SSM (without ever mentioning this) > > Not true. ASM is also supported. > >> 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs >> (in addition to PMIP tunnels) > > Not correct. Full mesh tunnel is not required. > >> 3.) You deploy PIM-SSM on all MAGs and all LMAs > > Not PIM-SSM, but PIM-SM, as the ducument explains. > >> Since this scenario experiences the routing convergence problem >> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which >> you should reference, btw.), you define >> >> 4.) Some additional smoothing procedures for handover > > This is correct. > >> Did we understand this correctly? > > Unfortunately, you did not understand the document. > I give you answer in detail as follows. > >> Our comments on this: >> >> Ad 1.): It is legitimate to define solutions solely for SSM, but this >> should be mentioned right away (in title and abstract). > > It supports both ASM and SSM. > I don't understand why you believe it is only for SSM. > Your mistake comes because I use the words, "multicast channel" or > "subscription", in the document? If so, I would add the following > terminology in the terminology section; > "This document supports both Any-Source Multicast and Source-Specific > Multicast [SSM]. Nevertheless, regardless of whether a host specifies > source address(es) with multicast address, we use "multicast channel" > for multicast service identification and "subscription" for procedure > to listen multicast channel. > > This terminology explanation resolves your misunderstanding? > >> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large >> PMIP deployment, you will end up with hundreds to thousands of >> multicast-induced tunnels at a single LMA. This raises severe scaling >> & complexity issues, but most likely will be unfeasible for >> cross-domain PMIP deployments. As these tunnels are static and beyond >> the control of the PMIP prefix management, there may be issues arising >> for unicast routing, as well. > > Mesh connection is not the requirement. I don't understand why you > believe mesh is the requirement. > The number of M-Tunnels MAG configures will be usually the same as > that of the number of LMAs the MAG communicates with PBU/PBA. > >> Ad 3.): PIM-SSM should transparently work on such a dense router >> mesh. However, multicast routes (selected from RPF) may not turn out >> to be as described in your draft. After an MN joins (S,G), its MAG >> selects the upstream according to the unicast route to S. What will >> this be? Most likely, S is completely "unrelated" to the MN and to its >> LMA, so the route to S may go wherever the (unicast) routing table of >> the local MAG points to. In many cases this will be default. > > Both ASM and SSM are supported. > Moreover, your claim is very strange. You are saying PIM is disabled > on the upstream interface selected by an RPF. But PIM selects an > upstream interface only from its PIM neigohbors. > >> In addition, once MN1 has established service of (S,G) at a MAG, a >> newly arriving MN2 will inherit this service (which is >> efficient). Now, if MN1 detaches, MN2 will continue to be served on >> the same route as MN1 did. In the (unlikely) case that MN1 had been >> subscribed to a "home service" (via its LMA, as suggested in your >> draft), MN2 continues to consume the "home service" of MN1, even >> though MN1 is gone. > > Selecting a single incoming interface solves the tunnel convergence > problem. Allowing multiple incoming interfaces leads the tunnel > convergence problem. That's all. > >> This leads to a picture which is complicated, disadvantageous in >> policy-based conditions (btw. conflicts with your policy-store >> solution) and contradicts the PMIP service model. > > Ditto. > And information kept in policy profile is independent on the upstream > interface selection. So no conflict. > >> As an intermediate summary: If we understood correctly, up until this >> point you have defined only a deployment scenario, but no new protocol >> operations or semantic. So this could simply be activated based on the >> protocols available today ... but may lead to a quite unexpected >> outcome ;) > > I think most of your claimes are incorrect. > >> Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing >> dynamics, which may be too slow for smooth handoffs. That's why you >> define three protocol extensions for smoothing the handover process >> for multicast (isolated from unicast handover management). > > Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow > handover will be happen, because no handover mechanism is provided in > these standard protocols. Therefore we would propose three possible > mechanisms for handover. Operators would select either one according > to their implementations, configuration, or policy. > >> Comments on this: >> >> * Policy Profile: Your policy is acquired from LMA (after a regular PMIP >> * handover). This is actually the long path& slow procedure, so I don't >> * expect much acceleration here ... in particular, you cannot be faster >> * than unicast (slow) handover. Also: this policy management conflicts >> * with the routing scenario mentioned above. > > Regarding the access to policy profile, there is no difference from > rfc5213. See Fig.3 in rfc5213. > Only the multicast information kept in policy profile is newly defined > in this document. > >> * Extended Proxy Binding Update: This I actually cannot understand. You >> * inform the nMAG of multicast subscriptions prior to handover ... so >> * you do a predictive handover, but you don't define any prediction >> * mechanism. I cannot see how this works ... > > No prediction provided in the PBU/PBA extension approach. The PBU/PBA > procedure sequences are also not changed from rfc5213. > Only the multicast subscription information exchanged with PBU/PBA is > newly defined in this document. > >> * CXTP: This context transfer is de-synchronized from the unicast >> * handover, which does not really help in handover acceleration (cannot >> * be faster than unicast, complicates a synchronization later ...). >> >> CXTP handover may be interesting in the cases discussed after Prague >> (a new broadcast access link is selected solely for multicast >> reception ...). We believe its not the most suitable approach here. > > The detail specification is described in Dirk's draft. Our draft > raises that solution as one of the candidate mechanisms. > >> So far for the feedback - did we miss(s/s/ -understand) something? > > In summary, I cannot find any important discussion that should be > addressed in the revised draft from your comments, except > terminology. > > Regards, > -- > Hitoshi Asaeda -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Mon Jul 25 05:58:10 2011 Return-Path: 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 40EB121F850E for ; Mon, 25 Jul 2011 05:58:10 -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 vN66VN-i1C2m for ; Mon, 25 Jul 2011 05:58:09 -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 1D0D121F8453 for ; Mon, 25 Jul 2011 05:58:08 -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 AEC072780CE; Mon, 25 Jul 2011 21:57:32 +0900 (JST) Date: Mon, 25 Jul 2011 21:57:32 +0900 (JST) Message-Id: <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E2D5D61.8060504@informatik.haw-hamburg.de> References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 12:58:10 -0000 Thomas, > before going into all the other details: > > Your draft describes (S,G) joins, only, and refers to and RPF > interface selection w.r.t. S. Figure 2 illustrates the MLD report message transmission for (S,G) join invoked by MNs. > To me, this is SSM with PIM-SSM. > > ASM with PIM-SM would perform an (*,G) join and the interface > selection would follow the direction of a per group configured RP. The draft says an RPF lookup for PIM-SM. This explanation does not eliminate ASM. > Let's first clarify what your draft *intends* to talk about. Again, the proposal supports both ASM and SSM. -- Hitoshi Asaeda > Thomas > > On 25.07.2011 01:16, Hitoshi Asaeda wrote: >> Thomas,Matthias >> >>> For the general, the draft seems to rephrase operations of GRE >>> tunneling, PIM and MLD in your own words which leaves unclear, what >>> actually is the standard protocol behavior (defined elsewhere), and >>> what is particular for your proposal. Understanding is also hindered >>> by observations that are correct, but unrelated to the specific >>> subject, and also statements that are incorrect. >> >> I was supprised that you almost misunderstood the document. >> Please carefully read the document and related RFCs. >> >>> In detail, we extracted the following contributions: >>> >>> 1.) Your proposal only addresses SSM (without ever mentioning this) >> >> Not true. ASM is also supported. >> >>> 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs >>> (in addition to PMIP tunnels) >> >> Not correct. Full mesh tunnel is not required. >> >>> 3.) You deploy PIM-SSM on all MAGs and all LMAs >> >> Not PIM-SSM, but PIM-SM, as the ducument explains. >> >>> Since this scenario experiences the routing convergence problem >>> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which >>> you should reference, btw.), you define >>> >>> 4.) Some additional smoothing procedures for handover >> >> This is correct. >> >>> Did we understand this correctly? >> >> Unfortunately, you did not understand the document. >> I give you answer in detail as follows. >> >>> Our comments on this: >>> >>> Ad 1.): It is legitimate to define solutions solely for SSM, but this >>> should be mentioned right away (in title and abstract). >> >> It supports both ASM and SSM. >> I don't understand why you believe it is only for SSM. >> Your mistake comes because I use the words, "multicast channel" or >> "subscription", in the document? If so, I would add the following >> terminology in the terminology section; >> "This document supports both Any-Source Multicast and Source-Specific >> Multicast [SSM]. Nevertheless, regardless of whether a host specifies >> source address(es) with multicast address, we use "multicast channel" >> for multicast service identification and "subscription" for procedure >> to listen multicast channel. >> >> This terminology explanation resolves your misunderstanding? >> >>> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large >>> PMIP deployment, you will end up with hundreds to thousands of >>> multicast-induced tunnels at a single LMA. This raises severe scaling >>> & complexity issues, but most likely will be unfeasible for >>> cross-domain PMIP deployments. As these tunnels are static and beyond >>> the control of the PMIP prefix management, there may be issues arising >>> for unicast routing, as well. >> >> Mesh connection is not the requirement. I don't understand why you >> believe mesh is the requirement. >> The number of M-Tunnels MAG configures will be usually the same as >> that of the number of LMAs the MAG communicates with PBU/PBA. >> >>> Ad 3.): PIM-SSM should transparently work on such a dense router >>> mesh. However, multicast routes (selected from RPF) may not turn out >>> to be as described in your draft. After an MN joins (S,G), its MAG >>> selects the upstream according to the unicast route to S. What will >>> this be? Most likely, S is completely "unrelated" to the MN and to its >>> LMA, so the route to S may go wherever the (unicast) routing table of >>> the local MAG points to. In many cases this will be default. >> >> Both ASM and SSM are supported. >> Moreover, your claim is very strange. You are saying PIM is disabled >> on the upstream interface selected by an RPF. But PIM selects an >> upstream interface only from its PIM neigohbors. >> >>> In addition, once MN1 has established service of (S,G) at a MAG, a >>> newly arriving MN2 will inherit this service (which is >>> efficient). Now, if MN1 detaches, MN2 will continue to be served on >>> the same route as MN1 did. In the (unlikely) case that MN1 had been >>> subscribed to a "home service" (via its LMA, as suggested in your >>> draft), MN2 continues to consume the "home service" of MN1, even >>> though MN1 is gone. >> >> Selecting a single incoming interface solves the tunnel convergence >> problem. Allowing multiple incoming interfaces leads the tunnel >> convergence problem. That's all. >> >>> This leads to a picture which is complicated, disadvantageous in >>> policy-based conditions (btw. conflicts with your policy-store >>> solution) and contradicts the PMIP service model. >> >> Ditto. >> And information kept in policy profile is independent on the upstream >> interface selection. So no conflict. >> >>> As an intermediate summary: If we understood correctly, up until this >>> point you have defined only a deployment scenario, but no new protocol >>> operations or semantic. So this could simply be activated based on the >>> protocols available today ... but may lead to a quite unexpected >>> outcome ;) >> >> I think most of your claimes are incorrect. >> >>> Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing >>> dynamics, which may be too slow for smooth handoffs. That's why you >>> define three protocol extensions for smoothing the handover process >>> for multicast (isolated from unicast handover management). >> >> Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow >> handover will be happen, because no handover mechanism is provided in >> these standard protocols. Therefore we would propose three possible >> mechanisms for handover. Operators would select either one according >> to their implementations, configuration, or policy. >> >>> Comments on this: >>> >>> * Policy Profile: Your policy is acquired from LMA (after a regular PMIP >>> * handover). This is actually the long path& slow procedure, so I don't >>> * expect much acceleration here ... in particular, you cannot be faster >>> * than unicast (slow) handover. Also: this policy management conflicts >>> * with the routing scenario mentioned above. >> >> Regarding the access to policy profile, there is no difference from >> rfc5213. See Fig.3 in rfc5213. >> Only the multicast information kept in policy profile is newly defined >> in this document. >> >>> * Extended Proxy Binding Update: This I actually cannot understand. You >>> * inform the nMAG of multicast subscriptions prior to handover ... so >>> * you do a predictive handover, but you don't define any prediction >>> * mechanism. I cannot see how this works ... >> >> No prediction provided in the PBU/PBA extension approach. The PBU/PBA >> procedure sequences are also not changed from rfc5213. >> Only the multicast subscription information exchanged with PBU/PBA is >> newly defined in this document. >> >>> * CXTP: This context transfer is de-synchronized from the unicast >>> * handover, which does not really help in handover acceleration (cannot >>> * be faster than unicast, complicates a synchronization later ...). >>> >>> CXTP handover may be interesting in the cases discussed after Prague >>> (a new broadcast access link is selected solely for multicast >>> reception ...). We believe its not the most suitable approach here. >> >> The detail specification is described in Dirk's draft. Our draft >> raises that solution as one of the candidate mechanisms. >> >>> So far for the feedback - did we miss(s/s/ -understand) something? >> >> In summary, I cannot find any important discussion that should be >> addressed in the revised draft from your comments, except >> terminology. >> >> Regards, >> -- >> Hitoshi Asaeda > > -- > > Prof. Dr. Thomas C. Schmidt > $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B > $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany $B!k(B > $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B > $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: > +49-40-42875-8409 $B!k(B From cjbc@it.uc3m.es Mon Jul 25 09:15:15 2011 Return-Path: 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 D1FBE21F8686 for ; Mon, 25 Jul 2011 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 vZZQqP0xB4ZP for ; Mon, 25 Jul 2011 09:15:14 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4F21F8E52 for ; Mon, 25 Jul 2011 08:21:32 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.83.185] (unknown [130.129.83.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 73463B492C6 for ; Mon, 25 Jul 2011 17:21:26 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: multimob@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pVXfxu0RSoOvPlILyee8" Organization: Universidad Carlos III de Madrid Date: Mon, 25 Jul 2011 17:21:12 +0200 Message-ID: <1311607272.10685.28.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18284.000 Subject: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:15:16 -0000 --=-pVXfxu0RSoOvPlILyee8 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, For those interested, here is the link of the paper I mention analyzing the performance of our RAMS proposal: http://www.jowua.org/index.php/jowua/article/view/66/56 Comments would be more than welcome, of course. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-pVXfxu0RSoOvPlILyee8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4tiegACgkQNdy6TdFwT2egSQCgnKwhbIS8dhMl8P7AV56fbfes z2kAnAqPAOZ4AUnClcvqyyowyaVl4u2J =A73m -----END PGP SIGNATURE----- --=-pVXfxu0RSoOvPlILyee8-- From behcetsarikaya@yahoo.com Mon Jul 25 10:23:35 2011 Return-Path: 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 0E4E221F88A1 for ; Mon, 25 Jul 2011 10:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sXNiDLsR5KpC for ; Mon, 25 Jul 2011 10:23:33 -0700 (PDT) Received: from nm2-vm1.bullet.mail.sp2.yahoo.com (nm2-vm1.bullet.mail.sp2.yahoo.com [98.139.91.249]) by ietfa.amsl.com (Postfix) with SMTP id D681221F859E for ; Mon, 25 Jul 2011 10:23:30 -0700 (PDT) Received: from [98.139.91.62] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 17:23:30 -0000 Received: from [98.139.91.35] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 17:23:30 -0000 Received: from [127.0.0.1] by omp1035.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 17:23:30 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 781085.28571.bm@omp1035.mail.sp2.yahoo.com Received: (qmail 74658 invoked by uid 60001); 25 Jul 2011 17:23:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311614610; bh=DkXgKgdPPvXoz6rbrn7UvvtvpDOSep5nBQK/Z/8ZjWg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IUsVDYkfbnbTnXjJMHKixO0GkXXoMDkbz6p22eYsp3yubnpnnvjIfaEwfx6aZ1FP3Bka3yyTYR3tEIwK7aSGGgBVT/svk+yaJPl1dAOsoDIW2qIRgRMfPTfJgSLtxcGbOdkwVoFhUnhrMyrKp4kqFt2nrcG44YoNf9r/wr0mv5I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xaZn/QHzRsmEuAtJuzRBqWCaOt5RLvehTTytugrBxbOwzQfNeXbOBJdgtq52leggXJ4wslFbSFR9Cm6qt/eyjK4GS/GAuXEW1rC0sJozPENq43foJ4kwZXP2HWKJhn0MFiHXKUvaCRq4H8OizFg6tUF36otcaXG6R2fHa+KuvqU=; X-YMail-OSG: Vr6mBYwVM1lMgNmq81.V4fyo.nN6209ASesuJFKqgIG1GYD ipXVJCgebcLkmsUFNHlvrQhqkGLrbd0bw1qCckv.8QGPLKZjYMge1FPMZFHL dF9kmKtdCPu0_ADN.Va0tEsdWJSFqvbArsC.pIdyTDnbXK9raXjO7RwUMvMa XyD79YltDEMaIJjgtXvh5139.S03qqCJHuLoi70ybabC2W6R2TLa.z.KS538 WAnRUc0PlTEMNQJJRbSTm35UEhG_orn.MXmJAf2XhmG7F0.Yg8KcMCwPZQMV LE1mlyjtuKrB812Z9S16J1X1b5Is7ZBEHPyigdSCZa.NfqihsewcrQQD8jyn 4pw4afsfjDoyOxvgqoVNTZdg5hlutq5ucZfqeKLxMbGXrfGNzo_8JpoAIyjQ paPjx3GHL2i6cPAJSl0TtmVGY.AFNWYg5kq21EVaFxR1M9OBPKlSVDfQuXzb TRKnawoa46uU8GuASHJeCMcxNKk_P Received: from [130.129.87.243] by web111416.mail.gq1.yahoo.com via HTTP; Mon, 25 Jul 2011 10:23:30 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> Message-ID: <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> Date: Mon, 25 Jul 2011 10:23:30 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , schmidt@informatik.haw-hamburg.de In-Reply-To: <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:23:35 -0000 =0A=0A=0A=0AIf MAG is deciding then there is only one choice, the LMA to wh= ich the MN is =0Aassociated.=0AIsn't this why you talk about M-tunnel?=0A= =0ABehcet=0A=0A> Thomas,=0A> =0A> > before going into all the other details= :=0A> > =0A> > Your draft describes (S,G) joins, only, and refers to and = RPF=0A> > interface selection w.r.t. S.=0A> =0A> Figure 2 illustrates the = MLD report message transmission for (S,G)=0A> join invoked by MNs.=0A> = =0A> > To me, this is SSM with PIM-SSM.=0A> > =0A> > ASM with PIM-SM wou= ld perform an (*,G) join and the interface=0A> > selection would follow t= he direction of a per group configured RP.=0A> =0A> The draft says an RPF = lookup for PIM-SM. This explanation does not=0A> eliminate ASM.=0A> =0A> >= Let's first clarify what your draft *intends* to talk about.=0A> =0A> Aga= in, the proposal supports both ASM and SSM.=0A> --=0A> Hitoshi Asaeda=0A> = =0A> =0A> > Thomas=0A> > =0A> > On 25.07.2011 01:16, Hitoshi Asaeda wrote:= =0A> >> Thomas,Matthias=0A> >>=0A> >>> For the general, the draft seems to= rephrase operations of GRE=0A> >>> tunneling, PIM and MLD in your own wor= ds which leaves unclear, what=0A> >>> actually is the standard protocol be= havior (defined elsewhere), and=0A> >>> what is particular for your propos= al. Understanding is also hindered=0A> >>> by observations that are correc= t, but unrelated to the specific=0A> >>> subject, and also statements that= are incorrect.=0A> >>=0A> >> I was supprised that you almost misundersto= od the document.=0A> >> Please carefully read the document and related RFC= s.=0A> >>=0A> >>> In detail, we extracted the following contributions:=0A>= >>>=0A> >>> 1.) Your proposal only addresses SSM (without ever mention= ing this)=0A> >>=0A> >> Not true. ASM is also supported.=0A> >>=0A> >>> = 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs=0A> = >>> (in addition to PMIP tunnels)=0A> >>=0A> >> Not correct. Full mesh = tunnel is not required.=0A> >>=0A> >>> 3.) You deploy PIM-SSM on all M= AGs and all LMAs=0A> >>=0A> >> Not PIM-SSM, but PIM-SM, as the ducument ex= plains.=0A> >>=0A> >>> Since this scenario experiences the routing converg= ence problem=0A> >>> described in http://tools.ietf.org/html/rfc5757#secti= on-2.2.2 (which=0A> >>> you should reference, btw.), you define=0A> >>>=0A= > >>> 4.) Some additional smoothing procedures for handover=0A> >>=0A> = >> This is correct.=0A> >>=0A> >>> Did we understand this correctly?=0A> = >>=0A> >> Unfortunately, you did not understand the document.=0A> >> I giv= e you answer in detail as follows.=0A> >>=0A> >>> Our comments on this:= =0A> >>>=0A> >>> Ad 1.): It is legitimate to define solutions solely for S= SM, but this=0A> >>> should be mentioned right away (in title and abstract= ).=0A> >>=0A> >> It supports both ASM and SSM.=0A> >> I don't understand w= hy you believe it is only for SSM.=0A> >> Your mistake comes because I use= the words, "multicast channel" or=0A> >> "subscription", in the document?= If so, I would add the following=0A> >> terminology in the terminology se= ction;=0A> >> "This document supports both Any-Source Multicast and Source= -Specific=0A> >> Multicast [SSM]. Nevertheless, regardless of whether a ho= st specifies=0A> >> source address(es) with multicast address, we use "mu= lticast channel"=0A> >> for multicast service identification and "subscrip= tion" for procedure=0A> >> to listen multicast channel.=0A> >>=0A> >> This= terminology explanation resolves your misunderstanding?=0A> >>=0A> >>> Ad= 2.): A mesh of permanent tunnels appears pretty ugly. In a large=0A> >>> = PMIP deployment, you will end up with hundreds to thousands of=0A> >>> mul= ticast-induced tunnels at a single LMA. This raises severe scaling=0A> >>>= & complexity issues, but most likely will be unfeasible for=0A> >>> cro= ss-domain PMIP deployments. As these tunnels are static and beyond=0A> >>>= the control of the PMIP prefix management, there may be issues arising=0A= > >>> for unicast routing, as well.=0A> >>=0A> >> Mesh connection is not t= he requirement. I don't understand why you=0A> >> believe mesh is the requ= irement.=0A> >> The number of M-Tunnels MAG configures will be usually the= same as=0A> >> that of the number of LMAs the MAG communicates with PBU/= PBA.=0A> >>=0A> >>> Ad 3.): PIM-SSM should transparently work on such a de= nse router=0A> >>> mesh. However, multicast routes (selected from RPF) may= not turn out=0A> >>> to be as described in your draft. After an MN joins = (S,G), its MAG=0A> >>> selects the upstream according to the unicast route= to S. What will=0A> >>> this be? Most likely, S is completely "unrelated"= to the MN and to its=0A> >>> LMA, so the route to S may go wherever the (= unicast) routing table of=0A> >>> the local MAG points to. In many cases t= his will be default.=0A> >>=0A> >> Both ASM and SSM are supported.=0A> >> = Moreover, your claim is very strange. You are saying PIM is disabled=0A> >= > on the upstream interface selected by an RPF. But PIM selects an=0A> >> = upstream interface only from its PIM neigohbors.=0A> >>=0A> >>> In additio= n, once MN1 has established service of (S,G) at a MAG, a=0A> >>> newly arr= iving MN2 will inherit this service (which is=0A> >>> efficient). Now, if = MN1 detaches, MN2 will continue to be served on=0A> >>> the same route as = MN1 did. In the (unlikely) case that MN1 had been=0A> >>> subscribed to a = "home service" (via its LMA, as suggested in your=0A> >>> draft), MN2 cont= inues to consume the "home service" of MN1, even=0A> >>> though MN1 is go= ne.=0A> >>=0A> >> Selecting a single incoming interface solves the tunnel = convergence=0A> >> problem. Allowing multiple incoming interfaces leads th= e tunnel=0A> >> convergence problem. That's all.=0A> >>=0A> >>> This leads= to a picture which is complicated, disadvantageous in=0A> >>> policy-base= d conditions (btw. conflicts with your policy-store=0A> >>> solution) and = contradicts the PMIP service model.=0A> >>=0A> >> Ditto.=0A> >> And inform= ation kept in policy profile is independent on the upstream=0A> >> interfa= ce selection. So no conflict.=0A> >>=0A> >>> As an intermediate summary: I= f we understood correctly, up until this=0A> >>> point you have defined on= ly a deployment scenario, but no new protocol=0A> >>> operations or seman= tic. So this could simply be activated based on the=0A> >>> protocols avai= lable today ... but may lead to a quite unexpected=0A> >>> outcome ;)=0A> = >>=0A> >> I think most of your claimes are incorrect.=0A> >>=0A> >>> Ad 4.= ): The scenario so far adapts to mobility via the PIM-SSM routing=0A> >>> = dynamics, which may be too slow for smooth handoffs. That's why you=0A> >>= > define three protocol extensions for smoothing the handover process=0A> = >>> for multicast (isolated from unicast handover management).=0A> >>=0A> = >> Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow= =0A> >> handover will be happen, because no handover mechanism is provided= in=0A> >> these standard protocols. Therefore we would propose three poss= ible=0A> >> mechanisms for handover. Operators would select either one acc= ording=0A> >> to their implementations, configuration, or policy.=0A> >>= =0A> >>> Comments on this:=0A> >>>=0A> >>> * Policy Profile: Your polic= y is acquired from LMA (after a regular =0APMIP=0A> >>> * handover). Thi= s is actually the long path& slow procedure, so I =0A>don't=0A> >>> * e= xpect much acceleration here ... in particular, you cannot be faster=0A> >= >> * than unicast (slow) handover. Also: this policy management conflict= s=0A> >>> * with the routing scenario mentioned above.=0A> >>=0A> >> Reg= arding the access to policy profile, there is no difference from=0A> >> rf= c5213. See Fig.3 in rfc5213.=0A> >> Only the multicast information kept in= policy profile is newly defined=0A> >> in this document.=0A> >>=0A> >>> = * Extended Proxy Binding Update: This I actually cannot understand. =0AY= ou=0A> >>> * inform the nMAG of multicast subscriptions prior to handove= r ... so=0A> >>> * you do a predictive handover, but you don't define an= y prediction=0A> >>> * mechanism. I cannot see how this works ...=0A> >>= =0A> >> No prediction provided in the PBU/PBA extension approach. The PBU/= PBA=0A> >> procedure sequences are also not changed from rfc5213.=0A> >> O= nly the multicast subscription information exchanged with PBU/PBA is=0A> >= > newly defined in this document.=0A> >>=0A> >>> * CXTP: This context tr= ansfer is de-synchronized from the unicast=0A> >>> * handover, which doe= s not really help in handover acceleration (cannot=0A> >>> * be faster = than unicast, complicates a synchronization later ...).=0A> >>>=0A> >>> CX= TP handover may be interesting in the cases discussed after Prague=0A> >>>= (a new broadcast access link is selected solely for multicast=0A> >>> rec= eption ...). We believe its not the most suitable approach here.=0A> >>=0A= > >> The detail specification is described in Dirk's draft. Our draft=0A> = >> raises that solution as one of the candidate mechanisms.=0A> >>=0A> >>>= So far for the feedback - did we miss(s/s/ -understand) something?=0A> >= >=0A> >> In summary, I cannot find any important discussion that should be= =0A> >> addressed in the revised draft from your comments, except=0A> >> t= erminology.=0A> >>=0A> >> Regards,=0A> >> --=0A> >> Hitoshi Asaeda=0A> > = =0A> > -- =0A> > =0A> > Prof. Dr. Thomas C. Schmidt=0A> > =B0 Hamburg Unive= rsity of Applied Sciences Berliner Tor 7 =B0=0A> > =B0 Dept. Informatik, I= nternet Technologies Group 20099 Hamburg,=0A> > Germany =B0=0A> > =B0 http= ://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 =B0=0A> > =B0 http://www= .informatik.haw-hamburg.de/~schmidt Fax:=0A> > +49-40-42875-8409 =B0=0A> = _______________________________________________=0A> multimob mailing list= =0A> multimob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multimob= =0A> From schmidt@informatik.haw-hamburg.de Mon Jul 25 10:41:21 2011 Return-Path: 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 6B91321F8BB6 for ; Mon, 25 Jul 2011 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hQLAu0kk7rfu for ; Mon, 25 Jul 2011 10:41:20 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAA21F8BDC for ; Mon, 25 Jul 2011 10:41:19 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlP9a-0006ci-Pd; Mon, 25 Jul 2011 19:41:19 +0200 Message-ID: <4E2DAABE.7010404@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 13:41:18 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:41:21 -0000 Hi Hitoshi, On 25.07.2011 08:57, Hitoshi Asaeda wrote: >> Let's first clarify what your draft *intends* to talk about. > > Again, the proposal supports both ASM and SSM. O.k., I guess this should be clarified in the writing. Also it is unclear why the draft puts MLDv2 as a requirement. Now following your answers and the presentation/discussion in the group, the following seems to be clarified: * You span static tunnels between all LMA-MAG pairs that are in the deployment scenario you consider. (This is what we called a mesh, but mesh is only a word.) In typical cases, you will add some hundreds of multicast-initiated tunnel end points to a single LMA ... * These M-tunnels are not used for PMIP unicast routing. Normally, they shouldn't be used for the non-PMIP unicast routing either. So if you just activate PIM-SM on the MAGs and LMAs, these tunnels will *not* be used for multicast routing, as well (remember: RPF uses inverse unicast routes). * If you plainly activate PIM-SM, the routing will follow the non-PMIP unicast routing scheme deployed in the operator network. This is a matter of individual deployment (not specified in PMIP or elsewhere) and would most likely result in a straight-forward local routing solution that ignores PMIP and the M-tunnels. * What you might do (but this is not described in your draft): configure a separate PIM routing (MFIBs) that do use the tunnels. However, this approach does not seem to have an obvious solution, since multicast routing follows (S,G) or (*,G) states, i.e., builds up on group addresses and sources, but PMIP (in particular: home subscriptions) is build upon MN <-> LMA bindings. There seems to be no obvious relation between a Group Channel and an LMA/MN, unless there is a multicast address scheme that associates G <-> LMA. I guess we got the core of your draft right now, correct? Best regards, Thomas >> On 25.07.2011 01:16, Hitoshi Asaeda wrote: >>> Thomas,Matthias >>> >>>> For the general, the draft seems to rephrase operations of GRE >>>> tunneling, PIM and MLD in your own words which leaves unclear, what >>>> actually is the standard protocol behavior (defined elsewhere), and >>>> what is particular for your proposal. Understanding is also hindered >>>> by observations that are correct, but unrelated to the specific >>>> subject, and also statements that are incorrect. >>> >>> I was supprised that you almost misunderstood the document. >>> Please carefully read the document and related RFCs. >>> >>>> In detail, we extracted the following contributions: >>>> >>>> 1.) Your proposal only addresses SSM (without ever mentioning this) >>> >>> Not true. ASM is also supported. >>> >>>> 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs >>>> (in addition to PMIP tunnels) >>> >>> Not correct. Full mesh tunnel is not required. >>> >>>> 3.) You deploy PIM-SSM on all MAGs and all LMAs >>> >>> Not PIM-SSM, but PIM-SM, as the ducument explains. >>> >>>> Since this scenario experiences the routing convergence problem >>>> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which >>>> you should reference, btw.), you define >>>> >>>> 4.) Some additional smoothing procedures for handover >>> >>> This is correct. >>> >>>> Did we understand this correctly? >>> >>> Unfortunately, you did not understand the document. >>> I give you answer in detail as follows. >>> >>>> Our comments on this: >>>> >>>> Ad 1.): It is legitimate to define solutions solely for SSM, but this >>>> should be mentioned right away (in title and abstract). >>> >>> It supports both ASM and SSM. >>> I don't understand why you believe it is only for SSM. >>> Your mistake comes because I use the words, "multicast channel" or >>> "subscription", in the document? If so, I would add the following >>> terminology in the terminology section; >>> "This document supports both Any-Source Multicast and Source-Specific >>> Multicast [SSM]. Nevertheless, regardless of whether a host specifies >>> source address(es) with multicast address, we use "multicast channel" >>> for multicast service identification and "subscription" for procedure >>> to listen multicast channel. >>> >>> This terminology explanation resolves your misunderstanding? >>> >>>> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large >>>> PMIP deployment, you will end up with hundreds to thousands of >>>> multicast-induced tunnels at a single LMA. This raises severe scaling >>>> & complexity issues, but most likely will be unfeasible for >>>> cross-domain PMIP deployments. As these tunnels are static and beyond >>>> the control of the PMIP prefix management, there may be issues arising >>>> for unicast routing, as well. >>> >>> Mesh connection is not the requirement. I don't understand why you >>> believe mesh is the requirement. >>> The number of M-Tunnels MAG configures will be usually the same as >>> that of the number of LMAs the MAG communicates with PBU/PBA. >>> >>>> Ad 3.): PIM-SSM should transparently work on such a dense router >>>> mesh. However, multicast routes (selected from RPF) may not turn out >>>> to be as described in your draft. After an MN joins (S,G), its MAG >>>> selects the upstream according to the unicast route to S. What will >>>> this be? Most likely, S is completely "unrelated" to the MN and to its >>>> LMA, so the route to S may go wherever the (unicast) routing table of >>>> the local MAG points to. In many cases this will be default. >>> >>> Both ASM and SSM are supported. >>> Moreover, your claim is very strange. You are saying PIM is disabled >>> on the upstream interface selected by an RPF. But PIM selects an >>> upstream interface only from its PIM neigohbors. >>> >>>> In addition, once MN1 has established service of (S,G) at a MAG, a >>>> newly arriving MN2 will inherit this service (which is >>>> efficient). Now, if MN1 detaches, MN2 will continue to be served on >>>> the same route as MN1 did. In the (unlikely) case that MN1 had been >>>> subscribed to a "home service" (via its LMA, as suggested in your >>>> draft), MN2 continues to consume the "home service" of MN1, even >>>> though MN1 is gone. >>> >>> Selecting a single incoming interface solves the tunnel convergence >>> problem. Allowing multiple incoming interfaces leads the tunnel >>> convergence problem. That's all. >>> >>>> This leads to a picture which is complicated, disadvantageous in >>>> policy-based conditions (btw. conflicts with your policy-store >>>> solution) and contradicts the PMIP service model. >>> >>> Ditto. >>> And information kept in policy profile is independent on the upstream >>> interface selection. So no conflict. >>> >>>> As an intermediate summary: If we understood correctly, up until this >>>> point you have defined only a deployment scenario, but no new protocol >>>> operations or semantic. So this could simply be activated based on the >>>> protocols available today ... but may lead to a quite unexpected >>>> outcome ;) >>> >>> I think most of your claimes are incorrect. >>> >>>> Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing >>>> dynamics, which may be too slow for smooth handoffs. That's why you >>>> define three protocol extensions for smoothing the handover process >>>> for multicast (isolated from unicast handover management). >>> >>> Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow >>> handover will be happen, because no handover mechanism is provided in >>> these standard protocols. Therefore we would propose three possible >>> mechanisms for handover. Operators would select either one according >>> to their implementations, configuration, or policy. >>> >>>> Comments on this: >>>> >>>> * Policy Profile: Your policy is acquired from LMA (after a regular PMIP >>>> * handover). This is actually the long path& slow procedure, so I don't >>>> * expect much acceleration here ... in particular, you cannot be faster >>>> * than unicast (slow) handover. Also: this policy management conflicts >>>> * with the routing scenario mentioned above. >>> >>> Regarding the access to policy profile, there is no difference from >>> rfc5213. See Fig.3 in rfc5213. >>> Only the multicast information kept in policy profile is newly defined >>> in this document. >>> >>>> * Extended Proxy Binding Update: This I actually cannot understand. You >>>> * inform the nMAG of multicast subscriptions prior to handover ... so >>>> * you do a predictive handover, but you don't define any prediction >>>> * mechanism. I cannot see how this works ... >>> >>> No prediction provided in the PBU/PBA extension approach. The PBU/PBA >>> procedure sequences are also not changed from rfc5213. >>> Only the multicast subscription information exchanged with PBU/PBA is >>> newly defined in this document. >>> >>>> * CXTP: This context transfer is de-synchronized from the unicast >>>> * handover, which does not really help in handover acceleration (cannot >>>> * be faster than unicast, complicates a synchronization later ...). >>>> >>>> CXTP handover may be interesting in the cases discussed after Prague >>>> (a new broadcast access link is selected solely for multicast >>>> reception ...). We believe its not the most suitable approach here. >>> >>> The detail specification is described in Dirk's draft. Our draft >>> raises that solution as one of the candidate mechanisms. >>> >>>> So far for the feedback - did we miss(s/s/ -understand) something? >>> >>> In summary, I cannot find any important discussion that should be >>> addressed in the revised draft from your comments, except >>> terminology. >>> >>> Regards, >>> -- >>> Hitoshi Asaeda >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B >> $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany $B!k(B >> $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B >> $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: >> +49-40-42875-8409 $B!k(B > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt $B!k(B Hamburg University of Applied Sciences Berliner Tor 7 $B!k(B $B!k(B Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany $B!k(B $B!k(B http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 $B!k(B $B!k(B http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 $B!k(B From schmidt@informatik.haw-hamburg.de Mon Jul 25 10:57:24 2011 Return-Path: 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 D2E9F5E8007 for ; Mon, 25 Jul 2011 10:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xooY+fhDxzHn for ; Mon, 25 Jul 2011 10:57:23 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBE25E8006 for ; Mon, 25 Jul 2011 10:57:23 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlPP7-0009U9-Uw; Mon, 25 Jul 2011 19:57:22 +0200 Message-ID: <4E2DAE80.9040207@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 13:57:20 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> In-Reply-To: <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: Behcet Sarikaya , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:57:24 -0000 Hi Behcet, On 25.07.2011 13:23, Behcet Sarikaya wrote: > > If MAG is deciding then there is only one choice, the LMA to which the MN is > associated. According to the draft, MAG runs PIM-SM. So PIM will decide according to its MFIB. Normally, this is derived from unicast routing - but as Stig pointed out in the meeting - one can configure an MFIB independent of the unicast routing. The more important problem here seems the PMIP routing behavior. As clarified in the discussion with Alexandru and Raj, PMIP routing does not work like "ordinary unicast routing". Depending on the MNs source ID, the default route is chosen to point to the appropriate MAG <-> LMA tunnel - a behavior which is outside the regular IP routing (and cannot be expressed in the standard routing table, I suppose). In particular, it's hard to imagine how a (modified) PIM protocol could interact with this irregular PMIP routing. If you just deployed a PIM daemon on a MAG, PMIP would most likely remain invisible to PIM and - as said earlier - PIM would plainly interact with the provider-internal basic unicast routing layer. Best regards, Thomas > Isn't this why you talk about M-tunnel? > > Behcet > >> Thomas, >> >>> before going into all the other details: >>> >>> Your draft describes (S,G) joins, only, and refers to and RPF >>> interface selection w.r.t. S. >> >> Figure 2 illustrates the MLD report message transmission for (S,G) >> join invoked by MNs. >> >>> To me, this is SSM with PIM-SSM. >>> >>> ASM with PIM-SM would perform an (*,G) join and the interface >>> selection would follow the direction of a per group configured RP. >> >> The draft says an RPF lookup for PIM-SM. This explanation does not >> eliminate ASM. >> >>> Let's first clarify what your draft *intends* to talk about. >> >> Again, the proposal supports both ASM and SSM. >> -- >> Hitoshi Asaeda >> >> >>> Thomas >>> >>> On 25.07.2011 01:16, Hitoshi Asaeda wrote: >>>> Thomas,Matthias >>>> >>>>> For the general, the draft seems to rephrase operations of GRE >>>>> tunneling, PIM and MLD in your own words which leaves unclear, what >>>>> actually is the standard protocol behavior (defined elsewhere), and >>>>> what is particular for your proposal. Understanding is also hindered >>>>> by observations that are correct, but unrelated to the specific >>>>> subject, and also statements that are incorrect. >>>> >>>> I was supprised that you almost misunderstood the document. >>>> Please carefully read the document and related RFCs. >>>> >>>>> In detail, we extracted the following contributions: >>>>> >>>>> 1.) Your proposal only addresses SSM (without ever mentioning this) >>>> >>>> Not true. ASM is also supported. >>>> >>>>> 2.) You span a full mesh of M-tunnels between all MAGs and all LMAs >>>>> (in addition to PMIP tunnels) >>>> >>>> Not correct. Full mesh tunnel is not required. >>>> >>>>> 3.) You deploy PIM-SSM on all MAGs and all LMAs >>>> >>>> Not PIM-SSM, but PIM-SM, as the ducument explains. >>>> >>>>> Since this scenario experiences the routing convergence problem >>>>> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which >>>>> you should reference, btw.), you define >>>>> >>>>> 4.) Some additional smoothing procedures for handover >>>> >>>> This is correct. >>>> >>>>> Did we understand this correctly? >>>> >>>> Unfortunately, you did not understand the document. >>>> I give you answer in detail as follows. >>>> >>>>> Our comments on this: >>>>> >>>>> Ad 1.): It is legitimate to define solutions solely for SSM, but this >>>>> should be mentioned right away (in title and abstract). >>>> >>>> It supports both ASM and SSM. >>>> I don't understand why you believe it is only for SSM. >>>> Your mistake comes because I use the words, "multicast channel" or >>>> "subscription", in the document? If so, I would add the following >>>> terminology in the terminology section; >>>> "This document supports both Any-Source Multicast and Source-Specific >>>> Multicast [SSM]. Nevertheless, regardless of whether a host specifies >>>> source address(es) with multicast address, we use "multicast channel" >>>> for multicast service identification and "subscription" for procedure >>>> to listen multicast channel. >>>> >>>> This terminology explanation resolves your misunderstanding? >>>> >>>>> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large >>>>> PMIP deployment, you will end up with hundreds to thousands of >>>>> multicast-induced tunnels at a single LMA. This raises severe scaling >>>>> & complexity issues, but most likely will be unfeasible for >>>>> cross-domain PMIP deployments. As these tunnels are static and beyond >>>>> the control of the PMIP prefix management, there may be issues arising >>>>> for unicast routing, as well. >>>> >>>> Mesh connection is not the requirement. I don't understand why you >>>> believe mesh is the requirement. >>>> The number of M-Tunnels MAG configures will be usually the same as >>>> that of the number of LMAs the MAG communicates with PBU/PBA. >>>> >>>>> Ad 3.): PIM-SSM should transparently work on such a dense router >>>>> mesh. However, multicast routes (selected from RPF) may not turn out >>>>> to be as described in your draft. After an MN joins (S,G), its MAG >>>>> selects the upstream according to the unicast route to S. What will >>>>> this be? Most likely, S is completely "unrelated" to the MN and to its >>>>> LMA, so the route to S may go wherever the (unicast) routing table of >>>>> the local MAG points to. In many cases this will be default. >>>> >>>> Both ASM and SSM are supported. >>>> Moreover, your claim is very strange. You are saying PIM is disabled >>>> on the upstream interface selected by an RPF. But PIM selects an >>>> upstream interface only from its PIM neigohbors. >>>> >>>>> In addition, once MN1 has established service of (S,G) at a MAG, a >>>>> newly arriving MN2 will inherit this service (which is >>>>> efficient). Now, if MN1 detaches, MN2 will continue to be served on >>>>> the same route as MN1 did. In the (unlikely) case that MN1 had been >>>>> subscribed to a "home service" (via its LMA, as suggested in your >>>>> draft), MN2 continues to consume the "home service" of MN1, even >>>>> though MN1 is gone. >>>> >>>> Selecting a single incoming interface solves the tunnel convergence >>>> problem. Allowing multiple incoming interfaces leads the tunnel >>>> convergence problem. That's all. >>>> >>>>> This leads to a picture which is complicated, disadvantageous in >>>>> policy-based conditions (btw. conflicts with your policy-store >>>>> solution) and contradicts the PMIP service model. >>>> >>>> Ditto. >>>> And information kept in policy profile is independent on the upstream >>>> interface selection. So no conflict. >>>> >>>>> As an intermediate summary: If we understood correctly, up until this >>>>> point you have defined only a deployment scenario, but no new protocol >>>>> operations or semantic. So this could simply be activated based on the >>>>> protocols available today ... but may lead to a quite unexpected >>>>> outcome ;) >>>> >>>> I think most of your claimes are incorrect. >>>> >>>>> Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing >>>>> dynamics, which may be too slow for smooth handoffs. That's why you >>>>> define three protocol extensions for smoothing the handover process >>>>> for multicast (isolated from unicast handover management). >>>> >>>> Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow >>>> handover will be happen, because no handover mechanism is provided in >>>> these standard protocols. Therefore we would propose three possible >>>> mechanisms for handover. Operators would select either one according >>>> to their implementations, configuration, or policy. >>>> >>>>> Comments on this: >>>>> >>>>> * Policy Profile: Your policy is acquired from LMA (after a regular > PMIP >>>>> * handover). This is actually the long path& slow procedure, so I >> don't >>>>> * expect much acceleration here ... in particular, you cannot be faster >>>>> * than unicast (slow) handover. Also: this policy management conflicts >>>>> * with the routing scenario mentioned above. >>>> >>>> Regarding the access to policy profile, there is no difference from >>>> rfc5213. See Fig.3 in rfc5213. >>>> Only the multicast information kept in policy profile is newly defined >>>> in this document. >>>> >>>>> * Extended Proxy Binding Update: This I actually cannot understand. > You >>>>> * inform the nMAG of multicast subscriptions prior to handover ... so >>>>> * you do a predictive handover, but you don't define any prediction >>>>> * mechanism. I cannot see how this works ... >>>> >>>> No prediction provided in the PBU/PBA extension approach. The PBU/PBA >>>> procedure sequences are also not changed from rfc5213. >>>> Only the multicast subscription information exchanged with PBU/PBA is >>>> newly defined in this document. >>>> >>>>> * CXTP: This context transfer is de-synchronized from the unicast >>>>> * handover, which does not really help in handover acceleration (cannot >>>>> * be faster than unicast, complicates a synchronization later ...). >>>>> >>>>> CXTP handover may be interesting in the cases discussed after Prague >>>>> (a new broadcast access link is selected solely for multicast >>>>> reception ...). We believe its not the most suitable approach here. >>>> >>>> The detail specification is described in Dirk's draft. Our draft >>>> raises that solution as one of the candidate mechanisms. >>>> >>>>> So far for the feedback - did we miss(s/s/ -understand) something? >>>> >>>> In summary, I cannot find any important discussion that should be >>>> addressed in the revised draft from your comments, except >>>> terminology. >>>> >>>> Regards, >>>> -- >>>> Hitoshi Asaeda >>> >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>> Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>> +49-40-42875-8409 ° >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Mon Jul 25 11:02:53 2011 Return-Path: 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 5AFBC21F8C03 for ; Mon, 25 Jul 2011 11:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 e+aayRP2ijuj for ; Mon, 25 Jul 2011 11:02:52 -0700 (PDT) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by ietfa.amsl.com (Postfix) with SMTP id 0113521F8C07 for ; Mon, 25 Jul 2011 11:02:51 -0700 (PDT) Received: from [98.139.91.66] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 18:02:51 -0000 Received: from [98.139.91.10] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 18:02:51 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 25 Jul 2011 18:02:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 918670.66658.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 4579 invoked by uid 60001); 25 Jul 2011 18:02:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311616971; bh=BU+I0qYNWc4mtPJC8KU8QsFzxrSLZoakmH6dzCxLpic=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FFRSZ/7hhWITt43dYBvb+mEO1Jp4qAacRILli2X+uadN3kLd7yuI+xqDnBuyU8l4PGe2IxawTWXPXCo9uJHMkmVsmrFEGrtOQanfSX4tz5Dwdk663A9LrMH3kI4hAZs7BiLRNqQSAWDWN0dHtDZDr1mQtPfvsXqKhJl4Izy8N4I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eQELy031RDJpk3TH2NCatwy+kJfdbDeiy3ft4dOdSum4nuULqSQJuLKURqeR4mAIAUXIvh4LtEKtKzmwNNo0dFlOhp1brLVSc5fr/73LzrxfQRkZ5pQ4NrZMhzdLXr04KbZF/Wn8VdTbkyW9YyX/kg1SiVqkOiELgjwr+QdNpVk=; X-YMail-OSG: gG8JXccVM1m3uDC1OlwSxTAh_VDFDugyp8NseJJukUXP0V4 tGlLZn5RdSab8zpnHy0XdUZtvk3YVGXqZntsDJLcSQPZmUZ7Qfwgbq7lFzF3 97vfOzPdXjMUlwa5rVleCpdcaeyPw5yxcjPvAymzXk8nS_zfHC.WA3Cb3feQ noZFlFxPGmdVdbc6kral9pkTuQu8oeldTqiNTwED.uok37b4IYYGah8ty4JR RqS_WUlm..9JbqV3IhIFp7XI0sZ4uze9BpROxP8Co9.d4MoHeI0FMKT2uks1 O1SRlt_eX.v5POERRq7JV1VzuFkLmL0lH3nqSo9GTSUArHEhq9TjGI0_EDCw q1h.xdE210asS0QuT3.cBpUtDgJvT8mg2jjCaxz0ZopTBewnO06_b_bgCRT4 XMjHeg4AOt.sbGmflP42uDZYlcYfsG2mG0FiXgWTR42ByGBkEq7Ix1vnE.Fh i1elpZ4RtUTZcwtf.4SsrvhbxejIY Received: from [130.129.87.243] by web111408.mail.gq1.yahoo.com via HTTP; Mon, 25 Jul 2011 11:02:51 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> <4E2DAE80.9040207@informatik.haw-hamburg.de> Message-ID: <1311616971.3930.YahooMailRC@web111408.mail.gq1.yahoo.com> Date: Mon, 25 Jul 2011 11:02:51 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4E2DAE80.9040207@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:02:53 -0000 Hi Thomas,=0A In case of 6224, we defined a proxy instance for each LMA fo= r upstream =0Atransmission.=0AMaybe PIM-SM draft should define something si= milar that is compatible with =0APIM-SM, like a specific MFIB that you ment= ioned in your previous mail.=0ASince we allow protocol extensions, it shoul= d be OK.=0A=0ABehcet=0A=0A=0A=0A> Hi Behcet,=0A> =0A> On 25.07.2011 13:23, = Behcet Sarikaya wrote:=0A> =0A> >=0A> > If MAG is deciding then there is o= nly one choice, the LMA to which the MN =0Ais=0A> > associated.=0A> =0A> A= ccording to the draft, MAG runs PIM-SM. So PIM will decide according to = =0A> its MFIB. Normally, this is derived from unicast routing - but as Sti= g =0A> pointed out in the meeting - one can configure an MFIB independent = of =0A> the unicast routing.=0A> =0A> The more important problem here seem= s the PMIP routing behavior. As =0A> clarified in the discussion with Alex= andru and Raj, PMIP routing does =0A> not work like "ordinary unicast rout= ing". Depending on the MNs source =0A> ID, the default route is chosen to = point to the appropriate MAG <-> LMA =0A> tunnel - a behavior which is out= side the regular IP routing (and cannot =0A> be expressed in the standard = routing table, I suppose). In particular, =0A> it's hard to imagine how a = (modified) PIM protocol could interact with =0A> this irregular PMIP routin= g. If you just deployed a PIM daemon on a MAG, =0A> PMIP would most likely= remain invisible to PIM and - as said earlier - =0A> PIM would plainly in= teract with the provider-internal basic unicast =0A> routing layer.=0A> = =0A> Best regards,=0A> =0A> Thomas=0A> =0A> > Isn't this why you talk abou= t M-tunnel?=0A> >=0A> > Behcet=0A> >=0A> >> Thomas,=0A> >>=0A> >>> before= going into all the other details:=0A> >>>=0A> >>> Your draft describes = (S,G) joins, only, and refers to and RPF=0A> >>> interface selection w= .r.t. S.=0A> >>=0A> >> Figure 2 illustrates the MLD report message transm= ission for (S,G)=0A> >> join invoked by MNs.=0A> >>=0A> >>> To me, this= is SSM with PIM-SSM.=0A> >>>=0A> >>> ASM with PIM-SM would perform an= (*,G) join and the interface=0A> >>> selection would follow the direct= ion of a per group configured RP.=0A> >>=0A> >> The draft says an RPF loo= kup for PIM-SM. This explanation does not=0A> >> eliminate ASM.=0A> >>=0A= > >>> Let's first clarify what your draft *intends* to talk about.=0A> >>= =0A> >> Again, the proposal supports both ASM and SSM.=0A> >> --=0A> >> H= itoshi Asaeda=0A> >>=0A> >>=0A> >>> Thomas=0A> >>>=0A> >>> On 25.07.2011 = 01:16, Hitoshi Asaeda wrote:=0A> >>>> Thomas,Matthias=0A> >>>>=0A> >>>>>= For the general, the draft seems to rephrase operations of GRE=0A> >>>>= > tunneling, PIM and MLD in your own words which leaves unclear, what= =0A> >>>>> actually is the standard protocol behavior (defined elsewhere)= , and=0A> >>>>> what is particular for your proposal. Understanding is a= lso hindered=0A> >>>>> by observations that are correct, but unrelated to= the specific=0A> >>>>> subject, and also statements that are incorrect.= =0A> >>>>=0A> >>>> I was supprised that you almost misunderstood the docu= ment.=0A> >>>> Please carefully read the document and related RFCs.=0A> = >>>>=0A> >>>>> In detail, we extracted the following contributions:=0A> = >>>>>=0A> >>>>> 1.) Your proposal only addresses SSM (without ever me= ntioning =0A>this)=0A> >>>>=0A> >>>> Not true. ASM is also supported.=0A= > >>>>=0A> >>>>> 2.) You span a full mesh of M-tunnels between all MA= Gs and all =0A>LMAs=0A> >>>>> (in addition to PMIP tunnels)=0A> >>>= >=0A> >>>> Not correct. Full mesh tunnel is not required.=0A> >>>>=0A> >>= >>> 3.) You deploy PIM-SSM on all MAGs and all LMAs=0A> >>>>=0A> >>>= > Not PIM-SSM, but PIM-SM, as the ducument explains.=0A> >>>>=0A> >>>>> S= ince this scenario experiences the routing convergence problem=0A> >>>>>= described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which=0A>= >>>>> you should reference, btw.), you define=0A> >>>>>=0A> >>>>> = 4.) Some additional smoothing procedures for handover=0A> >>>>=0A> >>>> = This is correct.=0A> >>>>=0A> >>>>> Did we understand this correctly?= =0A> >>>>=0A> >>>> Unfortunately, you did not understand the document.=0A= > >>>> I give you answer in detail as follows.=0A> >>>>=0A> >>>>> Our co= mments on this:=0A> >>>>>=0A> >>>>> Ad 1.): It is legitimate to define s= olutions solely for SSM, but this=0A> >>>>> should be mentioned right awa= y (in title and abstract).=0A> >>>>=0A> >>>> It supports both ASM and SS= M.=0A> >>>> I don't understand why you believe it is only for SSM.=0A> >>= >> Your mistake comes because I use the words, "multicast channel" or=0A>= >>>> "subscription", in the document? If so, I would add the following= =0A> >>>> terminology in the terminology section;=0A> >>>> "This document= supports both Any-Source Multicast and Source-Specific=0A> >>>> Multic= ast [SSM]. Nevertheless, regardless of whether a host =0Aspecifies=0A> >>= >> source address(es) with multicast address, we use "multicast channel"= =0A> >>>> for multicast service identification and "subscription" for pro= cedure=0A> >>>> to listen multicast channel.=0A> >>>>=0A> >>>> This term= inology explanation resolves your misunderstanding?=0A> >>>>=0A> >>>>> Ad= 2.): A mesh of permanent tunnels appears pretty ugly. In a large=0A> >>>= >> PMIP deployment, you will end up with hundreds to thousands of=0A> >>= >>> multicast-induced tunnels at a single LMA. This raises severe scaling= =0A> >>>>> & complexity issues, but most likely will be unfeasible for= =0A> >>>>> cross-domain PMIP deployments. As these tunnels are static an= d =0A>beyond=0A> >>>>> the control of the PMIP prefix management, there = may be issues arising=0A> >>>>> for unicast routing, as well.=0A> >>>>= =0A> >>>> Mesh connection is not the requirement. I don't understand why = you=0A> >>>> believe mesh is the requirement.=0A> >>>> The number of M-Tu= nnels MAG configures will be usually the same as=0A> >>>> that of the nu= mber of LMAs the MAG communicates with PBU/PBA.=0A> >>>>=0A> >>>>> Ad 3.)= : PIM-SSM should transparently work on such a dense router=0A> >>>>> mesh= . However, multicast routes (selected from RPF) may not turn out=0A> >>>= >> to be as described in your draft. After an MN joins (S,G), its MAG=0A>= >>>>> selects the upstream according to the unicast route to S. What wil= l=0A> >>>>> this be? Most likely, S is completely "unrelated" to the MN a= nd to =0Aits=0A> >>>>> LMA, so the route to S may go wherever the (unica= st) routing table of=0A> >>>>> the local MAG points to. In many cases thi= s will be default.=0A> >>>>=0A> >>>> Both ASM and SSM are supported.=0A> = >>>> Moreover, your claim is very strange. You are saying PIM is disabled= =0A> >>>> on the upstream interface selected by an RPF. But PIM selects = an=0A> >>>> upstream interface only from its PIM neigohbors.=0A> >>>>=0A>= >>>>> In addition, once MN1 has established service of (S,G) at a MAG, a= =0A> >>>>> newly arriving MN2 will inherit this service (which is=0A> >>>= >> efficient). Now, if MN1 detaches, MN2 will continue to be served on= =0A> >>>>> the same route as MN1 did. In the (unlikely) case that MN1 had= been=0A> >>>>> subscribed to a "home service" (via its LMA, as suggested= in your=0A> >>>>> draft), MN2 continues to consume the "home service" of= MN1, even=0A> >>>>> though MN1 is gone.=0A> >>>>=0A> >>>> Selecting a s= ingle incoming interface solves the tunnel convergence=0A> >>>> problem. = Allowing multiple incoming interfaces leads the tunnel=0A> >>>> converge= nce problem. That's all.=0A> >>>>=0A> >>>>> This leads to a picture which= is complicated, disadvantageous in=0A> >>>>> policy-based conditions (b= tw. conflicts with your policy-store=0A> >>>>> solution) and contradicts = the PMIP service model.=0A> >>>>=0A> >>>> Ditto.=0A> >>>> And informatio= n kept in policy profile is independent on the upstream=0A> >>>> interfac= e selection. So no conflict.=0A> >>>>=0A> >>>>> As an intermediate summa= ry: If we understood correctly, up until this=0A> >>>>> point you have de= fined only a deployment scenario, but no new =0Aprotocol=0A> >>>>> operat= ions or semantic. So this could simply be activated based on the=0A> >>>>= > protocols available today ... but may lead to a quite unexpected=0A> = >>>>> outcome ;)=0A> >>>>=0A> >>>> I think most of your claimes are in= correct.=0A> >>>>=0A> >>>>> Ad 4.): The scenario so far adapts to mobilit= y via the PIM-SSM =0Arouting=0A> >>>>> dynamics, which may be too slow fo= r smooth handoffs. That's why you=0A> >>>>> define three protocol extens= ions for smoothing the handover process=0A> >>>>> for multicast (isolated= from unicast handover management).=0A> >>>>=0A> >>>> Whether we use PIM-= SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow=0A> >>>> handover wil= l be happen, because no handover mechanism is provided in=0A> >>>> these = standard protocols. Therefore we would propose three possible=0A> >>>> m= echanisms for handover. Operators would select either one according=0A> >>= >> to their implementations, configuration, or policy.=0A> >>>>=0A> >>>= >> Comments on this:=0A> >>>>>=0A> >>>>> * Policy Profile: Your pol= icy is acquired from LMA (after a regular=0A> > PMIP=0A> >>>>> * hando= ver). This is actually the long path& slow procedure, so I=0A> >> don't= =0A> >>>>> * expect much acceleration here ... in particular, you cann= ot be =0A>faster=0A> >>>>> * than unicast (slow) handover. Also: this = policy management =0A>conflicts=0A> >>>>> * with the routing scenario = mentioned above.=0A> >>>>=0A> >>>> Regarding the access to policy profil= e, there is no difference from=0A> >>>> rfc5213. See Fig.3 in rfc5213.=0A= > >>>> Only the multicast information kept in policy profile is newly def= ined=0A> >>>> in this document.=0A> >>>>=0A> >>>>> * Extended Proxy B= inding Update: This I actually cannot understand.=0A> > You=0A> >>>>> *= inform the nMAG of multicast subscriptions prior to handover ... =0A>so= =0A> >>>>> * you do a predictive handover, but you don't define any = =0Aprediction=0A> >>>>> * mechanism. I cannot see how this works ...= =0A> >>>>=0A> >>>> No prediction provided in the PBU/PBA extension approa= ch. The PBU/PBA=0A> >>>> procedure sequences are also not changed from r= fc5213.=0A> >>>> Only the multicast subscription information exchanged wi= th PBU/PBA is=0A> >>>> newly defined in this document.=0A> >>>>=0A> >>>>>= * CXTP: This context transfer is de-synchronized from the unicast=0A= > >>>>> * handover, which does not really help in handover acceleratio= n =0A>(cannot=0A> >>>>> * be faster than unicast, complicates a synchr= onization later =0A>...).=0A> >>>>>=0A> >>>>> CXTP handover may be inter= esting in the cases discussed after Prague=0A> >>>>> (a new broadcast acc= ess link is selected solely for multicast=0A> >>>>> reception ...). We be= lieve its not the most suitable approach here.=0A> >>>>=0A> >>>> The det= ail specification is described in Dirk's draft. Our draft=0A> >>>> raises= that solution as one of the candidate mechanisms.=0A> >>>>=0A> >>>>> So = far for the feedback - did we miss(s/s/ -understand) something?=0A> >>>= >=0A> >>>> In summary, I cannot find any important discussion that should= be=0A> >>>> addressed in the revised draft from your comments, except=0A= > >>>> terminology.=0A> >>>>=0A> >>>> Regards,=0A> >>>> --=0A> >>>> Hit= oshi Asaeda=0A> >>>=0A> >>> --=0A> >>>=0A> >>> Prof. Dr. Thomas C. Schmid= t=0A> >>> =B0 Hamburg University of Applied Sciences Berliner Tor 7 =B0= =0A> >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg,= =0A> >>> Germany =B0=0A> >>> =B0 http://www.haw-hamburg.de/inet Fon: +49-= 40-42875-8452 =B0=0A> >>> =B0 http://www.informatik.haw-hamburg.de/~schmid= t Fax:=0A> >>> +49-40-42875-8409 =B0=0A> >> ___________________________= ____________________=0A> >> multimob mailing list=0A> >> multimob@ietf.or= g=0A> >> https://www.ietf.org/mailman/listinfo/multimob=0A> >>=0A> =0A> -- = =0A> =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0 Hamburg University of Applied= Sciences Berliner Tor 7 =B0=0A> =B0 Dept. Informatik, = Internet Technologies Group 20099 Hamburg, Germany =B0=0A> =B0 http://w= ww.haw-hamburg.de/inet Fon: +49-40-42875-8452 =B0=0A> = =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-840= 9 =B0=0A> From schmidt@informatik.haw-hamburg.de Mon Jul 25 11:31:35 2011 Return-Path: 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 5CEFE21F8BB6 for ; Mon, 25 Jul 2011 11:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 oZatNXKH7gaZ for ; Mon, 25 Jul 2011 11:31:34 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E721F8B17 for ; Mon, 25 Jul 2011 11:31:33 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlPw9-000FNP-05; Mon, 25 Jul 2011 20:31:29 +0200 Message-ID: <4E2DB67F.8020609@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 14:31:27 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <4E2C474A.5040401@informatik.haw-hamburg.de> <20110725.141603.192663909.asaeda@sfc.wide.ad.jp> <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> <4E2DAE80.9040207@informatik.haw-hamburg.de> <1311616971.3930.YahooMailRC@web111408.mail.gq1.yahoo.com> In-Reply-To: <1311616971.3930.YahooMailRC@web111408.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: Behcet Sarikaya , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:31:35 -0000 Hi Behcet, On 25.07.2011 14:02, Behcet Sarikaya wrote: > In case of 6224, we defined a proxy instance for each LMA for upstream > transmission. Yes, and that saves us from the need to interact with PMIP routing (except for the configuration of the proxy instance). > Maybe PIM-SM draft should define something similar that is compatible with > PIM-SM, like a specific MFIB that you mentioned in your previous mail. > Since we allow protocol extensions, it should be OK. > Yes, that could be done from a general point of view. The problem seems, it is not clear how to do this reasonably and how to end up with something better than the base solution. The (quite complex) PIM protocol allows for dynamic routing between various interfaces etc. I've no idea what actually would happen, if one changes PIM MFIBs externally triggered by PMIP handover operations. This sounds adventurous to me. I guess, we have to ask the PIM chair for a wise opinion on that :-) Best regards, Thomas On 25.07.2011 14:02, Behcet Sarikaya wrote: > Hi Thomas, > In case of 6224, we defined a proxy instance for each LMA for upstream > transmission. > Maybe PIM-SM draft should define something similar that is compatible with > PIM-SM, like a specific MFIB that you mentioned in your previous mail. > Since we allow protocol extensions, it should be OK. > > Behcet > > > >> Hi Behcet, >> >> On 25.07.2011 13:23, Behcet Sarikaya wrote: >> >>> >>> If MAG is deciding then there is only one choice, the LMA to which the MN > is >>> associated. >> >> According to the draft, MAG runs PIM-SM. So PIM will decide according to >> its MFIB. Normally, this is derived from unicast routing - but as Stig >> pointed out in the meeting - one can configure an MFIB independent of >> the unicast routing. >> >> The more important problem here seems the PMIP routing behavior. As >> clarified in the discussion with Alexandru and Raj, PMIP routing does >> not work like "ordinary unicast routing". Depending on the MNs source >> ID, the default route is chosen to point to the appropriate MAG<-> LMA >> tunnel - a behavior which is outside the regular IP routing (and cannot >> be expressed in the standard routing table, I suppose). In particular, >> it's hard to imagine how a (modified) PIM protocol could interact with >> this irregular PMIP routing. If you just deployed a PIM daemon on a MAG, >> PMIP would most likely remain invisible to PIM and - as said earlier - >> PIM would plainly interact with the provider-internal basic unicast >> routing layer. >> >> Best regards, >> >> Thomas >> >>> Isn't this why you talk about M-tunnel? >>> >>> Behcet >>> >>>> Thomas, >>>> >>>>> before going into all the other details: >>>>> >>>>> Your draft describes (S,G) joins, only, and refers to and RPF >>>>> interface selection w.r.t. S. >>>> >>>> Figure 2 illustrates the MLD report message transmission for (S,G) >>>> join invoked by MNs. >>>> >>>>> To me, this is SSM with PIM-SSM. >>>>> >>>>> ASM with PIM-SM would perform an (*,G) join and the interface >>>>> selection would follow the direction of a per group configured RP. >>>> >>>> The draft says an RPF lookup for PIM-SM. This explanation does not >>>> eliminate ASM. >>>> >>>>> Let's first clarify what your draft *intends* to talk about. >>>> >>>> Again, the proposal supports both ASM and SSM. >>>> -- >>>> Hitoshi Asaeda >>>> >>>> >>>>> Thomas >>>>> >>>>> On 25.07.2011 01:16, Hitoshi Asaeda wrote: >>>>>> Thomas,Matthias >>>>>> >>>>>>> For the general, the draft seems to rephrase operations of GRE >>>>>>> tunneling, PIM and MLD in your own words which leaves unclear, what >>>>>>> actually is the standard protocol behavior (defined elsewhere), and >>>>>>> what is particular for your proposal. Understanding is also hindered >>>>>>> by observations that are correct, but unrelated to the specific >>>>>>> subject, and also statements that are incorrect. >>>>>> >>>>>> I was supprised that you almost misunderstood the document. >>>>>> Please carefully read the document and related RFCs. >>>>>> >>>>>>> In detail, we extracted the following contributions: >>>>>>> >>>>>>> 1.) Your proposal only addresses SSM (without ever mentioning >> this) >>>>>> >>>>>> Not true. ASM is also supported. >>>>>> >>>>>>> 2.) You span a full mesh of M-tunnels between all MAGs and all >> LMAs >>>>>>> (in addition to PMIP tunnels) >>>>>> >>>>>> Not correct. Full mesh tunnel is not required. >>>>>> >>>>>>> 3.) You deploy PIM-SSM on all MAGs and all LMAs >>>>>> >>>>>> Not PIM-SSM, but PIM-SM, as the ducument explains. >>>>>> >>>>>>> Since this scenario experiences the routing convergence problem >>>>>>> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which >>>>>>> you should reference, btw.), you define >>>>>>> >>>>>>> 4.) Some additional smoothing procedures for handover >>>>>> >>>>>> This is correct. >>>>>> >>>>>>> Did we understand this correctly? >>>>>> >>>>>> Unfortunately, you did not understand the document. >>>>>> I give you answer in detail as follows. >>>>>> >>>>>>> Our comments on this: >>>>>>> >>>>>>> Ad 1.): It is legitimate to define solutions solely for SSM, but this >>>>>>> should be mentioned right away (in title and abstract). >>>>>> >>>>>> It supports both ASM and SSM. >>>>>> I don't understand why you believe it is only for SSM. >>>>>> Your mistake comes because I use the words, "multicast channel" or >>>>>> "subscription", in the document? If so, I would add the following >>>>>> terminology in the terminology section; >>>>>> "This document supports both Any-Source Multicast and Source-Specific >>>>>> Multicast [SSM]. Nevertheless, regardless of whether a host > specifies >>>>>> source address(es) with multicast address, we use "multicast channel" >>>>>> for multicast service identification and "subscription" for procedure >>>>>> to listen multicast channel. >>>>>> >>>>>> This terminology explanation resolves your misunderstanding? >>>>>> >>>>>>> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large >>>>>>> PMIP deployment, you will end up with hundreds to thousands of >>>>>>> multicast-induced tunnels at a single LMA. This raises severe scaling >>>>>>> & complexity issues, but most likely will be unfeasible for >>>>>>> cross-domain PMIP deployments. As these tunnels are static and >> beyond >>>>>>> the control of the PMIP prefix management, there may be issues arising >>>>>>> for unicast routing, as well. >>>>>> >>>>>> Mesh connection is not the requirement. I don't understand why you >>>>>> believe mesh is the requirement. >>>>>> The number of M-Tunnels MAG configures will be usually the same as >>>>>> that of the number of LMAs the MAG communicates with PBU/PBA. >>>>>> >>>>>>> Ad 3.): PIM-SSM should transparently work on such a dense router >>>>>>> mesh. However, multicast routes (selected from RPF) may not turn out >>>>>>> to be as described in your draft. After an MN joins (S,G), its MAG >>>>>>> selects the upstream according to the unicast route to S. What will >>>>>>> this be? Most likely, S is completely "unrelated" to the MN and to > its >>>>>>> LMA, so the route to S may go wherever the (unicast) routing table of >>>>>>> the local MAG points to. In many cases this will be default. >>>>>> >>>>>> Both ASM and SSM are supported. >>>>>> Moreover, your claim is very strange. You are saying PIM is disabled >>>>>> on the upstream interface selected by an RPF. But PIM selects an >>>>>> upstream interface only from its PIM neigohbors. >>>>>> >>>>>>> In addition, once MN1 has established service of (S,G) at a MAG, a >>>>>>> newly arriving MN2 will inherit this service (which is >>>>>>> efficient). Now, if MN1 detaches, MN2 will continue to be served on >>>>>>> the same route as MN1 did. In the (unlikely) case that MN1 had been >>>>>>> subscribed to a "home service" (via its LMA, as suggested in your >>>>>>> draft), MN2 continues to consume the "home service" of MN1, even >>>>>>> though MN1 is gone. >>>>>> >>>>>> Selecting a single incoming interface solves the tunnel convergence >>>>>> problem. Allowing multiple incoming interfaces leads the tunnel >>>>>> convergence problem. That's all. >>>>>> >>>>>>> This leads to a picture which is complicated, disadvantageous in >>>>>>> policy-based conditions (btw. conflicts with your policy-store >>>>>>> solution) and contradicts the PMIP service model. >>>>>> >>>>>> Ditto. >>>>>> And information kept in policy profile is independent on the upstream >>>>>> interface selection. So no conflict. >>>>>> >>>>>>> As an intermediate summary: If we understood correctly, up until this >>>>>>> point you have defined only a deployment scenario, but no new > protocol >>>>>>> operations or semantic. So this could simply be activated based on the >>>>>>> protocols available today ... but may lead to a quite unexpected >>>>>>> outcome ;) >>>>>> >>>>>> I think most of your claimes are incorrect. >>>>>> >>>>>>> Ad 4.): The scenario so far adapts to mobility via the PIM-SSM > routing >>>>>>> dynamics, which may be too slow for smooth handoffs. That's why you >>>>>>> define three protocol extensions for smoothing the handover process >>>>>>> for multicast (isolated from unicast handover management). >>>>>> >>>>>> Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow >>>>>> handover will be happen, because no handover mechanism is provided in >>>>>> these standard protocols. Therefore we would propose three possible >>>>>> mechanisms for handover. Operators would select either one according >>>>>> to their implementations, configuration, or policy. >>>>>> >>>>>>> Comments on this: >>>>>>> >>>>>>> * Policy Profile: Your policy is acquired from LMA (after a regular >>> PMIP >>>>>>> * handover). This is actually the long path& slow procedure, so I >>>> don't >>>>>>> * expect much acceleration here ... in particular, you cannot be >> faster >>>>>>> * than unicast (slow) handover. Also: this policy management >> conflicts >>>>>>> * with the routing scenario mentioned above. >>>>>> >>>>>> Regarding the access to policy profile, there is no difference from >>>>>> rfc5213. See Fig.3 in rfc5213. >>>>>> Only the multicast information kept in policy profile is newly defined >>>>>> in this document. >>>>>> >>>>>>> * Extended Proxy Binding Update: This I actually cannot understand. >>> You >>>>>>> * inform the nMAG of multicast subscriptions prior to handover ... >> so >>>>>>> * you do a predictive handover, but you don't define any > prediction >>>>>>> * mechanism. I cannot see how this works ... >>>>>> >>>>>> No prediction provided in the PBU/PBA extension approach. The PBU/PBA >>>>>> procedure sequences are also not changed from rfc5213. >>>>>> Only the multicast subscription information exchanged with PBU/PBA is >>>>>> newly defined in this document. >>>>>> >>>>>>> * CXTP: This context transfer is de-synchronized from the unicast >>>>>>> * handover, which does not really help in handover acceleration >> (cannot >>>>>>> * be faster than unicast, complicates a synchronization later >> ...). >>>>>>> >>>>>>> CXTP handover may be interesting in the cases discussed after Prague >>>>>>> (a new broadcast access link is selected solely for multicast >>>>>>> reception ...). We believe its not the most suitable approach here. >>>>>> >>>>>> The detail specification is described in Dirk's draft. Our draft >>>>>> raises that solution as one of the candidate mechanisms. >>>>>> >>>>>>> So far for the feedback - did we miss(s/s/ -understand) something? >>>>>> >>>>>> In summary, I cannot find any important discussion that should be >>>>>> addressed in the revised draft from your comments, except >>>>>> terminology. >>>>>> >>>>>> Regards, >>>>>> -- >>>>>> Hitoshi Asaeda >>>>> >>>>> -- >>>>> >>>>> Prof. Dr. Thomas C. Schmidt >>>>> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >>>>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>> Germany ° >>>>> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >>>>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>> +49-40-42875-8409 ° >>>> _______________________________________________ >>>> multimob mailing list >>>> multimob@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >> > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Mon Jul 25 11:45:08 2011 Return-Path: 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 8A7EB21F8C29 for ; Mon, 25 Jul 2011 11:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cl-7iiR0cftr for ; Mon, 25 Jul 2011 11:45:08 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D821F8C23 for ; Mon, 25 Jul 2011 11:45:07 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlQ9K-000Hej-Vk for multimob@ietf.org; Mon, 25 Jul 2011 20:45:07 +0200 Message-ID: <4E2DB9B3.7060800@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 14:45:07 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Subject: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:45:08 -0000 Hi all, unfortunately, we did not reach a conclusion or clear picture on the subject of context transfer during the meeting. It seems good to work on settling objectives first. Thus the question: Can we agree on the following two purposes of context transfer? 1. Accelerate handover / make handover seamless 2. Switch to dedicated multicast links in a vertical handover (e.g., select a cheap/high quality broadcast link ...) Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Dirk.von-Hugo@telekom.de Mon Jul 25 11:57:56 2011 Return-Path: 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 DB99C11E8091 for ; Mon, 25 Jul 2011 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 vc69vQvQ9E+9 for ; Mon, 25 Jul 2011 11:57:56 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id A9203228012 for ; Mon, 25 Jul 2011 11:57:55 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jul 2011 20:57:47 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.206]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 25 Jul 2011 20:57:47 +0200 From: To: , Date: Mon, 25 Jul 2011 20:57:45 +0200 Thread-Topic: [multimob] Multicast Context Transfer Thread-Index: AcxK+v2KF4JLzoHFQCySYH/Xqa/A6AAAH/wQ Message-ID: <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> In-Reply-To: <4E2DB9B3.7060800@informatik.haw-hamburg.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:57:57 -0000 Hi Thomas, So if one understands "seamless" to include being lossless and more reliabl= e, I would agree. Since multicast in contrast to unicast mostly is not acknowledged by each r= eceiver I would stress the options of context transfer to reduce loss of da= ta during handover thanks to storage at p-MAG and perhaps also including AA= A information or similar MN subscription details which could delay the comp= letion of subscription process after handover. And regarding synchronisation with unicast: cannot we imagine a combined co= ntext transfer of all uni- and multicast sessions? Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Thomas C. Schmidt Gesendet: Montag, 25. Juli 2011 20:45 An: multimob@ietf.org Betreff: [multimob] Multicast Context Transfer Hi all, unfortunately, we did not reach a conclusion or clear picture on the subject of context transfer during the meeting. It seems good to work on settling objectives first. Thus the question: Can we agree on the following two purposes of context transfer? 1. Accelerate handover / make handover seamless 2. Switch to dedicated multicast links in a vertical handover (e.g., select a cheap/high quality broadcast link ...) Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany= =B0 =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Mon Jul 25 13:05:42 2011 Return-Path: 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 345BD21F8B7B for ; Mon, 25 Jul 2011 13:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 JLGbeBfqLUG5 for ; Mon, 25 Jul 2011 13:05:41 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 97AA321F8B79 for ; Mon, 25 Jul 2011 13:05:40 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlRPH-00059y-I0; Mon, 25 Jul 2011 22:05:39 +0200 Message-ID: <4E2DCC94.1010704@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 16:05:40 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:05:42 -0000 Hi Dirk, I guess we need to carefully distinguish here: There is packet loss due to slow handovers (MN disconnect), and packet loss due to many other reasons (e.g., radio instability ...). The latter we cannot address at all, the first is mainly a result of handover performance. So this improves with accelerated unicast+multicast handover performance. Regarding context broadcasting: "cannot we imagine a combined context transfer of all uni- and multicast sessions?" What would this be good for? I guess, context is always interface-specific (otherwise multicast content will be delivered to all interfaces simultaneously ...) Cheers, Thomas On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: > Hi Thomas, > So if one understands "seamless" to include being lossless and more reliable, I would agree. > Since multicast in contrast to unicast mostly is not acknowledged by each receiver I would stress the options of context transfer to reduce loss of data during handover thanks to storage at p-MAG and perhaps also including AAA information or similar MN subscription details which could delay the completion of subscription process after handover. > > And regarding synchronisation with unicast: cannot we imagine a combined context transfer of all uni- and multicast sessions? > > Best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Thomas C. Schmidt > Gesendet: Montag, 25. Juli 2011 20:45 > An: multimob@ietf.org > Betreff: [multimob] Multicast Context Transfer > > Hi all, > > unfortunately, we did not reach a conclusion or clear picture on the > subject of context transfer during the meeting. > > It seems good to work on settling objectives first. > > Thus the question: Can we agree on the following two purposes of context > transfer? > > 1. Accelerate handover / make handover seamless > 2. Switch to dedicated multicast links in a vertical handover (e.g., > select a cheap/high quality broadcast link ...) > > Cheers, > > Thomas > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From waehlisch@ieee.org Mon Jul 25 15:58:14 2011 Return-Path: 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 6C0EC11E80E9 for ; Mon, 25 Jul 2011 15:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 35eJRLlBlN2P for ; Mon, 25 Jul 2011 15:58:13 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7FF11E80E4 for ; Mon, 25 Jul 2011 15:58:13 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.10.45] (helo=mw-PC.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlU6G-0003Is-1O; Tue, 26 Jul 2011 00:58:12 +0200 Date: Mon, 25 Jul 2011 18:58:11 -0400 (Eastern Sommerzeit) From: Matthias Waehlisch To: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano In-Reply-To: <1311607272.10685.28.camel@acorde.it.uc3m.es> Message-ID: References: <1311607272.10685.28.camel@acorde.it.uc3m.es> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="361895811-20420-1311619607=:4820" Content-ID: X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:58:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --361895811-20420-1311619607=:4820 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hi Carlos, I had a short look at your paper. Your numerical evaluation is based=20 on a rough topology model. Overall, you argue that the delay between the=20 MN and MAG is larger compared to the delay between MAG and LMA. Some comments: * The authors of [18] analyzed the time a packet spends in a router.=20 This is more related to router modeling instead of path delay modeling.=20 From=20this perspective this seems not the correct modeling step for your= =20 problem. * You assumed that MAG and LMA reside in the same Autonomous System,=20 right? This is a valid assumption but must not be true in general.=20 Obviously this would change the delay (cf., "An AS-level Study of=20 Internet Path Delay Characteristics" GLOBECOM'04). For a more=20 well-grounded evaluation you should model the relation between MAG and=20 LMA in more detail. This could be interesting. * For the backhaul delay you use 5 ms referring to the 3GPP standard.=20 I would doubt that this is realistic, in particular compared to the=20 LMA-MAG delay. First, the standard cannot define the delay between the=20 NodeB and the MAG. Second, the NodeB should be obviously in the=20 topological vicinity of the MAG. In other words, if you assume a=20 significant large delay between NodeB and MAG but a short delay between=20 MAG and LMA, you could 'directly' attach the NodeB to the LMA. * The comparison with RFC 6224 seems a bit unfair. It would=20 be more interesting to compare with the FMIP proposal, for example. Just to make sure that I'm not misunderstood: Your assumption=20 (reducing delay because MAG-LMA link is faster) is not uninteresting but=20 needs a more careful verification. You need a more detailed radio as=20 well as topology model to derive general protocol design insights. In=20 particular, you need more detailed information on current MAG/LMA=20 deployment within networks. Best regards matthias --=20 Matthias Waehlisch =2E Freie Universitaet Berlin, Inst. fuer Informatik, AG CST =2E Takustr. 9, D-14195 Berlin, Germany =2E. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Mon, 25 Jul 2011, Carlos Jes=FAs Bernardos Cano wrote: > Hi, >=20 > For those interested, here is the link of the paper I mention analyzing > the performance of our RAMS proposal: >=20 > http://www.jowua.org/index.php/jowua/article/view/66/56 >=20 > Comments would be more than welcome, of course. >=20 > Thanks, >=20 > Carlos >=20 >=20 --361895811-20420-1311619607=:4820-- From schmidt@informatik.haw-hamburg.de Mon Jul 25 16:29:58 2011 Return-Path: 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 D99BB21F8BB9 for ; Mon, 25 Jul 2011 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 eZUOevKtid7Y for ; Mon, 25 Jul 2011 16:29:58 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCD21F867F for ; Mon, 25 Jul 2011 16:29:57 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlUay-0005jU-1t; Tue, 26 Jul 2011 01:29:56 +0200 Message-ID: <4E2DFC73.8040809@informatik.haw-hamburg.de> Date: Mon, 25 Jul 2011 19:29:55 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: <1311607272.10685.28.camel@acorde.it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:29:59 -0000 Hi Juan Carlos, Carlos, IMO the reasonable comparison in the context transfer routing is (i) pMAG <-> nMAG versus (ii) pMAG <-> LMA <-> nMAG The corresponding links are all wired and pMAG is adjacent to nMAG. From all reasonable topologies I can imagine, (i) should be an order of magnitude shorter than (ii). Cheers, Thomas On 25.07.2011 18:58, Matthias Waehlisch wrote: > Hi Carlos, > > I had a short look at your paper. Your numerical evaluation is based > on a rough topology model. Overall, you argue that the delay between the > MN and MAG is larger compared to the delay between MAG and LMA. > > Some comments: > > * The authors of [18] analyzed the time a packet spends in a router. > This is more related to router modeling instead of path delay modeling. > From this perspective this seems not the correct modeling step for your > problem. > > * You assumed that MAG and LMA reside in the same Autonomous System, > right? This is a valid assumption but must not be true in general. > Obviously this would change the delay (cf., "An AS-level Study of > Internet Path Delay Characteristics" GLOBECOM'04). For a more > well-grounded evaluation you should model the relation between MAG and > LMA in more detail. This could be interesting. > > * For the backhaul delay you use 5 ms referring to the 3GPP standard. > I would doubt that this is realistic, in particular compared to the > LMA-MAG delay. First, the standard cannot define the delay between the > NodeB and the MAG. Second, the NodeB should be obviously in the > topological vicinity of the MAG. In other words, if you assume a > significant large delay between NodeB and MAG but a short delay between > MAG and LMA, you could 'directly' attach the NodeB to the LMA. > > * The comparison with RFC 6224 seems a bit unfair. It would > be more interesting to compare with the FMIP proposal, for example. > > > Just to make sure that I'm not misunderstood: Your assumption > (reducing delay because MAG-LMA link is faster) is not uninteresting but > needs a more careful verification. You need a more detailed radio as > well as topology model to derive general protocol design insights. In > particular, you need more detailed information on current MAG/LMA > deployment within networks. > > > > Best regards > matthias > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Osvaldo.Gonsa@eu.panasonic.com Tue Jul 26 01:29:43 2011 Return-Path: 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 B61E621F8BFC for ; Tue, 26 Jul 2011 01:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eMvjCg4dgLi9 for ; Tue, 26 Jul 2011 01:29:39 -0700 (PDT) Received: from cluster-h.mailcontrol.com (cluster-h.mailcontrol.com [208.87.234.190]) by ietfa.amsl.com (Postfix) with ESMTP id BB12921F8B67 for ; Tue, 26 Jul 2011 01:29:39 -0700 (PDT) Received: from eundsmtpout01.pan.eu ([168.87.60.202]) by rly24h.srv.mailcontrol.com (MailControl) with ESMTP id p6Q8TW22014171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 26 Jul 2011 09:29:38 +0100 Received: from eundadmi02.pan.eu ([10.109.33.23]) by eundsmtpout01.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2011072610293160-599296 ; Tue, 26 Jul 2011 10:29:31 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi02.pan.eu (Lotus Domino Release 8.5.1FP4) with ESMTP id 2011072610292186-956701 ; Tue, 26 Jul 2011 10:29:21 +0200 X-Footer: cGFuYXNvbmljLmRl Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for multimob@ietf.org; Tue, 26 Jul 2011 10:29:19 +0200 Received: from [10.10.150.94] ([10.10.150.94]) by lan-ex-02.panasonic.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 10:29:19 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: multimob@ietf.org References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> <4E2DCC94.1010704@informatik.haw-hamburg.de> In-Reply-To: <4E2DCC94.1010704@informatik.haw-hamburg.de> X-Enigmail-Version: 1.1.1 X-OriginalArrivalTime: 26 Jul 2011 08:29:19.0462 (UTC) FILETIME=[1D291860:01CC4B6E] X-TNEFEvaluated: 1 Message-ID: <4E2E7ADF.8090200@panasonic.de> Date: Tue, 26 Jul 2011 10:29:19 +0200 From: Osvaldo Gonsa X-MIMETrack: Itemize by SMTP Server on EUNDADMI02/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 26.07.2011 10:29:21, Serialize by Router on EUNDADMI02/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 26.07.2011 10:29:31, Serialize complete at 26.07.2011 10:29:31, Itemize by SMTP Server on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/26/2011 10:29:31 AM, Serialize by Router on EUNDSMTPOUT01/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/26/2011 10:29:38 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MailControl A-12-00-01 (www.mailcontrol.com) on 10.72.0.134 Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 08:29:43 -0000 Hello Gentlemen, just to ask for clarification on the actual "need" for context transfer in the multicast application. Normally in commercial/standardised systems there is no "handover" of the multicast stream. This was mainly done to simplify things. Now, another reason was that typical multicast applications like streaming TV/radio or PoC can tolerate very well the handover interruption due to radio instabilities. It was/is even possible to receive multicast/broadcast data while the terminal operates in Idle mode. Then my question to you is, what kind of applications do you have in mind that will benefit for having such context transfer for multicast. And if you allow me one more question, wouldn't be sufficient that higher layers take care of any retransmission if packet loss happens and would this be noticeable to the end-user? Best Regards Osvaldo On 25/07/2011 22:05, Thomas C. Schmidt wrote: > Hi Dirk, > > I guess we need to carefully distinguish here: There is packet loss > due to slow handovers (MN disconnect), and packet loss due to many > other reasons (e.g., radio instability ...). > > The latter we cannot address at all, the first is mainly a result of > handover performance. So this improves with accelerated > unicast+multicast handover performance. > > Regarding context broadcasting: "cannot we imagine a combined context > transfer of all uni- and multicast sessions?" > > What would this be good for? I guess, context is always > interface-specific (otherwise multicast content will be delivered to > all interfaces simultaneously ...) > > Cheers, > > Thomas > > On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: >> Hi Thomas, >> So if one understands "seamless" to include being lossless and more >> reliable, I would agree. >> Since multicast in contrast to unicast mostly is not acknowledged by >> each receiver I would stress the options of context transfer to >> reduce loss of data during handover thanks to storage at p-MAG and >> perhaps also including AAA information or similar MN subscription >> details which could delay the completion of subscription process >> after handover. >> >> And regarding synchronisation with unicast: cannot we imagine a >> combined context transfer of all uni- and multicast sessions? >> >> Best regards >> Dirk >> >> -----Urspr=FCngliche Nachricht----- >> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >> Auftrag von Thomas C. Schmidt >> Gesendet: Montag, 25. Juli 2011 20:45 >> An: multimob@ietf.org >> Betreff: [multimob] Multicast Context Transfer >> >> Hi all, >> >> unfortunately, we did not reach a conclusion or clear picture on the >> subject of context transfer during the meeting. >> >> It seems good to work on settling objectives first. >> >> Thus the question: Can we agree on the following two purposes of context >> transfer? >> >> 1. Accelerate handover / make handover seamless >> 2. Switch to dedicated multicast links in a vertical handover (e.g., >> select a cheap/high quality broadcast link ...) >> >> Cheers, >> >> Thomas >> --=20 >> >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner >> Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >> +49-40-42875-8409 =B0 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > --=20 Dr-Ing. Osvaldo Gonsa (ECE) Panasonic Frankfurt Laboratory Panasonic R&D Center Germany GmbH D-63225 Langen, Germany Tel.:+49-6103-766-250 Fax :+49-6103-766-166 Email: osvaldo.gonsa@eu.panasonic.com --------------------------------- The problem with the future is that it keeps turning into the present.... ---------------------------------- Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke From asaeda@sfc.wide.ad.jp Tue Jul 26 01:54:06 2011 Return-Path: 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 8C6C821F8A55 for ; Tue, 26 Jul 2011 01:54:06 -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 MaxCK+rmdqNp for ; Tue, 26 Jul 2011 01:54:06 -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 DA41F21F8A23 for ; Tue, 26 Jul 2011 01:54:05 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 300E1278242; Tue, 26 Jul 2011 17:53:33 +0900 (JST) Date: Tue, 26 Jul 2011 17:53:32 +0900 (JST) Message-Id: <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E2DAABE.7010404@informatik.haw-hamburg.de> References: <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <4E2DAABE.7010404@informatik.haw-hamburg.de> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 08:54:06 -0000 Thomas, >>> Let's first clarify what your draft *intends* to talk about. >> >> Again, the proposal supports both ASM and SSM. > > O.k., I guess this should be clarified in the writing. Also it is > unclear why the draft puts MLDv2 as a requirement. PIM-SM is a multicast routing protocol providing router-to-router communication. MLDv2 is a protocol providing host-to-router communication. It is very obvious that "multicast router" usually supports both communications, but if it is better to describe this condition in the document, I'll add some text in it. > Now following your answers and the presentation/discussion in the group, > the following seems to be clarified: > > * You span static tunnels between all LMA-MAG pairs that are in the > deployment scenario you consider. (This is what we called a mesh, but > mesh is only a word.) In typical cases, you will add some hundreds of > multicast-initiated tunnel end points to a single LMA ... As I said, it is not necessary to create static M-Tunnels to all LMA-MAG pairs. How many M-tunnels is set up is operators decision; it would be same to or less than the number of association between LMA-MAG. It can be adjusted by operators. > * These M-tunnels are not used for PMIP unicast routing. Normally, they > shouldn't be used for the non-PMIP unicast routing either. So if you > just activate PIM-SM on the MAGs and LMAs, these tunnels will *not* be > used for multicast routing, as well (remember: RPF uses inverse unicast > routes). Ok, now I understand your thought. PIM-SM uses MRIB for RPF lookup. The MRIB could be same of the unicast routing table, or could be provided by a separate routing protocol. It seems that the current draft only mentions that MRIB is provided by a separate routing protocol implicitly. But it is true that only using a single unicast routing protocol can work with PIM-SM. If only the regular unicast routing table is used for MRIB, the regular IPv6-IPv6 tunnel for PMIPv6 is used. If operators want to populate routes for specific multicast channels over M-Tunnel into MRIB, M-Tunnel is used. As well, if a separate routing protocol is used for MRIB, M-Tunnel is used. Does this make sense? I'll describe these conditions and the relation between MRIB and M-Tunnel in the revised version. Thanks. > * If you plainly activate PIM-SM, the routing will follow the non-PMIP > unicast routing scheme deployed in the operator network. This is a > matter of individual deployment (not specified in PMIP or elsewhere) and > would most likely result in a straight-forward local routing solution > that ignores PMIP and the M-tunnels. As you see now, PIM-SM uses MRIB which could be taken from the unicast routing table or a separate routing protocol. M-Tunnel contributes to providing the path toward (*,G) or (S,G) without dependency of unicast route in PMIPv6, if prefered. BTW, specifying how MRIB is constructed in a network is out of scope of this document because it is in general multicast operational schema. But of couese, if it's useful, I'll add some text about MRIB consideration in PMIPv6 in the revised draft. > * What you might do (but this is not described in your draft): > configure a separate PIM routing (MFIBs) that do use the tunnels. Above answers your question? > However, this approach does not seem to have an obvious solution, since > multicast routing follows (S,G) or (*,G) states, i.e., builds up on > group addresses and sources, but PMIP (in particular: home > subscriptions) is build upon MN <-> LMA bindings. There seems to be no > obvious relation between a Group Channel and an LMA/MN, unless there is > a multicast address scheme that associates G <-> LMA. Multicast routing is established with (*,G) or (S,G). No receiver involvement. What is your concern? Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Tue Jul 26 02:12:51 2011 Return-Path: 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 9F60B21F8B2B for ; Tue, 26 Jul 2011 02:12:51 -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=[AWL=-0.000, 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 PRJOBbZCTTnJ for ; Tue, 26 Jul 2011 02:12:51 -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 0622521F8B20 for ; Tue, 26 Jul 2011 02:12:50 -0700 (PDT) Received: from localhost (dhcp-143-228.sfc.wide.ad.jp [203.178.143.228]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0D9AC2781F3; Tue, 26 Jul 2011 18:12:20 +0900 (JST) Date: Tue, 26 Jul 2011 18:12:19 +0900 (JST) Message-Id: <20110726.181219.168602339.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E2DAE80.9040207@informatik.haw-hamburg.de> References: <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> <4E2DAE80.9040207@informatik.haw-hamburg.de> 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: behcetsarikaya@yahoo.com, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 09:12:51 -0000 Hi, >> If MAG is deciding then there is only one choice, the LMA to which the >> MN is >> associated. > > According to the draft, MAG runs PIM-SM. So PIM will decide according > to its MFIB. Normally, this is derived from unicast routing - but as > Stig pointed out in the meeting - one can configure an MFIB > independent of the unicast routing. Right. PIM-SM works with MRIB, and MRIB is organized from unicast routing protocol or separate protocol. (BTW, you have been saying MFIB, but I expect MRIB is correct in your contexts.) > The more important problem here seems the PMIP routing behavior. As > clarified in the discussion with Alexandru and Raj, PMIP routing does > not work like "ordinary unicast routing". Depending on the MNs source > ID, the default route is chosen to point to the appropriate MAG <-> > LMA tunnel - a behavior which is outside the regular IP routing (and > cannot be expressed in the standard routing table, I suppose). In > particular, it's hard to imagine how a (modified) PIM protocol could > interact with this irregular PMIP routing. Yes. PMIPv6 may be unlike ordinal unicast routing protocol. Separating RIB and MRIB is already the standard behavior in many routing protocols. PIM-SM just refers to MRIB derived from RIB organized for PMIPv6. I don't imagine any problem, if PIM-SM is implemented along with the RFC correctly. > If you just deployed a PIM > daemon on a MAG, PMIP would most likely remain invisible to PIM and - > as said earlier - PIM would plainly interact with the > provider-internal basic unicast routing layer. PMIPv6 itself does not need to communicate with PIM-SM, if PMIPv6 organizes RIB correctly. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Jul 26 07:57:08 2011 Return-Path: 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 6423811E80A3 for ; Tue, 26 Jul 2011 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aRiplKz44XVl for ; Tue, 26 Jul 2011 07:57:07 -0700 (PDT) Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with SMTP id BACA221F855C for ; Tue, 26 Jul 2011 07:57:07 -0700 (PDT) Received: from [98.139.91.70] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jul 2011 14:57:07 -0000 Received: from [98.139.91.3] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 26 Jul 2011 14:57:07 -0000 Received: from [127.0.0.1] by omp1003.mail.sp2.yahoo.com with NNFMP; 26 Jul 2011 14:57:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 692304.31022.bm@omp1003.mail.sp2.yahoo.com Received: (qmail 50262 invoked by uid 60001); 26 Jul 2011 14:57:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311692227; bh=GxZeRx4kUU8x7hGUgp06RdJj5VUEi3lG5CJZLjISF8Y=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=auTb+j8RuUnYdyipM2aFG97BUn3gaGOrXCczQLbNjDWYkmiEPoHX1NcEKRiGFca29mSr5Y8a+I3JeZyzhQ3F2zJXP/479xpp4pwo78xPqL5dg9DXgMYq/nU8hGeICJzz6bpJav6WNPy58RRp6j1eaS83aXAb5KD+CWBuUQ27Sjc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0t9VQpM6HwHrPDTBNK6uIiEn7uT5cjnvknoFUuyR/7Bhwe6K6agqleN5fNsmz6k7+NIiTjHEtqqXkUfiLIlec0m590qBvQtjRUE1n9cC+PY3TPZ2oHHY4TncmIxoT/EUHElcQeRJfTRD7GCvh2bImKMXeh5A1vcKCqAD8JN0nMM=; X-YMail-OSG: iDtt79YVM1m3LgRIh9a4efG9Rj4GgCovHEVs3GJHs1XEgt2 iclJII.Wh7ApgNAB0Qp6o5EeBKSeYWQnNbBOX1V2D1gt5bYji56ZEF8whW_w axWKv47x2FG8HVIKcTSwP.3EsKoNRgtLtqlPshMJmeEHB0ciKHpGxakdZQ8T UyuPa1THKk8EQpHps_zJZZKtW8q7OCFHz329NzC39onJbDIFv9ArAOtn4BPp MzCjbR6EYkRv8uChmuJMrPeErw8OVeJ6yFkLK7wTN6u6cgaIAHlOxuHOcfC. t2zEYTU5GVqfN6mWCYtj_0.dAbMwBR4m97hKZy93hPBwF.OhVBcGwoWfqxQN XoPC6sw8oi.5Ko1Rm7bgdgWIToQit8GD9wngCqO6mLZ1L88H9LfwVeKKLyk9 mw4Fe448.RttqTA-- Received: from [130.129.19.51] by web111401.mail.gq1.yahoo.com via HTTP; Tue, 26 Jul 2011 07:57:07 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <4E2DAABE.7010404@informatik.haw-hamburg.de> <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> Message-ID: <1311692227.65634.YahooMailRC@web111401.mail.gq1.yahoo.com> Date: Tue, 26 Jul 2011 07:57:07 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , schmidt@informatik.haw-hamburg.de In-Reply-To: <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:57:08 -0000 > Thomas, > > >>> Let's first clarify what your draft *intends* to talk about. > >> > >> Again, the proposal supports both ASM and SSM. > > > > O.k., I guess this should be clarified in the writing. Also it is > > unclear why the draft puts MLDv2 as a requirement. > > PIM-SM is a multicast routing protocol providing router-to-router > communication. > MLDv2 is a protocol providing host-to-router communication. > > It is very obvious that "multicast router" usually supports both > communications, but if it is better to describe this condition in the > document, I'll add some text in it. > > > Now following your answers and the presentation/discussion in the group, > > the following seems to be clarified: > > > > * You span static tunnels between all LMA-MAG pairs that are in the > > deployment scenario you consider. (This is what we called a mesh, but > > mesh is only a word.) In typical cases, you will add some hundreds of > > multicast-initiated tunnel end points to a single LMA ... > > As I said, it is not necessary to create static M-Tunnels to all > LMA-MAG pairs. How many M-tunnels is set up is operators decision; it > would be same to or less than the number of association between > LMA-MAG. It can be adjusted by operators. > > > * These M-tunnels are not used for PMIP unicast routing. Normally, they > > shouldn't be used for the non-PMIP unicast routing either. So if you > > just activate PIM-SM on the MAGs and LMAs, these tunnels will *not* be > > used for multicast routing, as well (remember: RPF uses inverse unicast > > routes). > > Ok, now I understand your thought. > PIM-SM uses MRIB for RPF lookup. The MRIB could be same of the unicast > routing table, or could be provided by a separate routing protocol. > It seems that the current draft only mentions that MRIB is provided by > a separate routing protocol implicitly. But it is true that only using > a single unicast routing protocol can work with PIM-SM. > > If only the regular unicast routing table is used for MRIB, the > regular IPv6-IPv6 tunnel for PMIPv6 is used. If operators want to > populate routes for specific multicast channels over M-Tunnel into > MRIB, M-Tunnel is used. As well, if a separate routing protocol is > used for MRIB, M-Tunnel is used. So, use PMIP tunnel normally, establish M-tunnel for additional connections like for local routing. Is this what you are saying? I suggest clear explanation of how PIM-SM will avoid the tunnel convergence problem in case regular PMIP tunnel is used. Thanks, Behcet From schmidt@informatik.haw-hamburg.de Tue Jul 26 07:59:14 2011 Return-Path: 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 68BA911E808E for ; Tue, 26 Jul 2011 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 8f7gdIwkjqgJ for ; Tue, 26 Jul 2011 07:59:13 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C921F874E for ; Tue, 26 Jul 2011 07:59:13 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qlj6F-000HNh-Rc; Tue, 26 Jul 2011 16:59:12 +0200 Message-ID: <4E2ED640.3020900@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 10:59:12 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Osvaldo Gonsa References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> <4E2DCC94.1010704@informatik.haw-hamburg.de> <4E2E7ADF.8090200@panasonic.de> In-Reply-To: <4E2E7ADF.8090200@panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:59:14 -0000 Dear Osvaldo, thanks for the feedback. On 26.07.2011 04:29, Osvaldo Gonsa wrote: > just to ask for clarification on the actual "need" for context transfer > in the multicast application. Normally in commercial/standardised > systems there is no "handover" of the multicast stream. This was mainly > done to simplify things. Question: What kind of "commercial/standardised systems" do you have in mind? > Now, another reason was that typical multicast > applications like streaming TV/radio or PoC can tolerate very well the > handover interruption due to radio instabilities. This basically depends on the handover delay/interruption (and the tolerance of the codec), I believe. Still, in a typical soccer game, the hot period of goal hitting is very brief. If your receiver looses the critical packets due to handover, the user will miss the exciting moments. >It was/is even > possible to receive multicast/broadcast data while the terminal operates > in Idle mode. I suppose you're talking about a non-IP world here: an IP node is not able to receive IP streams without an IP interface configured. > Then my question to you is, what kind of applications do you have in > mind that will benefit for having such context transfer for multicast. > And if you allow me one more question, wouldn't be sufficient that > higher layers take care of any retransmission if packet loss happens and > would this be noticeable to the end-user? > There are many higher layer solutions that can compensate packet loss (on the multicast transport or the coding side). There are two limitations with it 1. They need to be in place (and the IP layer is intended to work fine without special compensations at higher layers) 2. They impose (partly significant) delays which make retransmissions etc. infeasible for real-time traffic s.u. conversational/interactive services (conferencing, games, ...). Best regards, Thomas > On 25/07/2011 22:05, Thomas C. Schmidt wrote: >> Hi Dirk, >> >> I guess we need to carefully distinguish here: There is packet loss >> due to slow handovers (MN disconnect), and packet loss due to many >> other reasons (e.g., radio instability ...). >> >> The latter we cannot address at all, the first is mainly a result of >> handover performance. So this improves with accelerated >> unicast+multicast handover performance. >> >> Regarding context broadcasting: "cannot we imagine a combined context >> transfer of all uni- and multicast sessions?" >> >> What would this be good for? I guess, context is always >> interface-specific (otherwise multicast content will be delivered to >> all interfaces simultaneously ...) >> >> Cheers, >> >> Thomas >> >> On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: >>> Hi Thomas, >>> So if one understands "seamless" to include being lossless and more >>> reliable, I would agree. >>> Since multicast in contrast to unicast mostly is not acknowledged by >>> each receiver I would stress the options of context transfer to >>> reduce loss of data during handover thanks to storage at p-MAG and >>> perhaps also including AAA information or similar MN subscription >>> details which could delay the completion of subscription process >>> after handover. >>> >>> And regarding synchronisation with unicast: cannot we imagine a >>> combined context transfer of all uni- and multicast sessions? >>> >>> Best regards >>> Dirk >>> >>> -----Ursprüngliche Nachricht----- >>> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >>> Auftrag von Thomas C. Schmidt >>> Gesendet: Montag, 25. Juli 2011 20:45 >>> An: multimob@ietf.org >>> Betreff: [multimob] Multicast Context Transfer >>> >>> Hi all, >>> >>> unfortunately, we did not reach a conclusion or clear picture on the >>> subject of context transfer during the meeting. >>> >>> It seems good to work on settling objectives first. >>> >>> Thus the question: Can we agree on the following two purposes of context >>> transfer? >>> >>> 1. Accelerate handover / make handover seamless >>> 2. Switch to dedicated multicast links in a vertical handover (e.g., >>> select a cheap/high quality broadcast link ...) >>> >>> Cheers, >>> >>> Thomas >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences Berliner >>> Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>> Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: >>> +49-40-42875-8452 ° >>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>> +49-40-42875-8409 ° >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >> > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Tue Jul 26 08:21:49 2011 Return-Path: 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 C6D4F11E8106 for ; Tue, 26 Jul 2011 08:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 P81XoZ4tObWb for ; Tue, 26 Jul 2011 08:21:49 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id CC33E11E80D3 for ; Tue, 26 Jul 2011 08:21:48 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QljS7-000LWR-KO; Tue, 26 Jul 2011 17:21:48 +0200 Message-ID: <4E2EDB8A.6080305@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 11:21:46 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <4E2DAABE.7010404@informatik.haw-hamburg.de> <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:21:49 -0000 Hi Hitoshi, please see my answers inline (marked with Thomas>): On 26.07.2011 04:53, Hitoshi Asaeda wrote: >>>> Let's first clarify what your draft *intends* to talk about. >>> >>> Again, the proposal supports both ASM and SSM. >> >> O.k., I guess this should be clarified in the writing. Also it is >> unclear why the draft puts MLDv2 as a requirement. > > PIM-SM is a multicast routing protocol providing router-to-router > communication. > MLDv2 is a protocol providing host-to-router communication. Thomas> Sure, but PIM-SM (ASM) works fine with MLDv1. So I don't see a reason to exclude it. >> Now following your answers and the presentation/discussion in the group, >> the following seems to be clarified: >> >> * You span static tunnels between all LMA-MAG pairs that are in the >> deployment scenario you consider. (This is what we called a mesh, but >> mesh is only a word.) In typical cases, you will add some hundreds of >> multicast-initiated tunnel end points to a single LMA ... > > As I said, it is not necessary to create static M-Tunnels to all > LMA-MAG pairs. How many M-tunnels is set up is operators decision; it > would be same to or less than the number of association between > LMA-MAG. It can be adjusted by operators. > Thomas> Well, your solution builds on this M x N tunnel mesh. Of course, an operator can choose not to deploy it :-) >> * These M-tunnels are not used for PMIP unicast routing. Normally, they >> shouldn't be used for the non-PMIP unicast routing either. So if you >> just activate PIM-SM on the MAGs and LMAs, these tunnels will *not* be >> used for multicast routing, as well (remember: RPF uses inverse unicast >> routes). > > Ok, now I understand your thought. > PIM-SM uses MRIB for RPF lookup. The MRIB could be same of the unicast > routing table, or could be provided by a separate routing protocol. Thomas> What other routing protocols than for unicast routing do you have in mind? Anyway, PIM-SM commonly uses the underlying unicast routing protocol (except for inter-domain routing). If you don't use this, you need to provide a mechanism that explores the topology independently and provides a consistent view on (join/prune) routes all over the network. You can provide MRIBs manually (thats like in the early days of the Internet), but if you define an alternate unicast routing protocol for building the MRIB, the world gets really complicated. > It seems that the current draft only mentions that MRIB is provided by > a separate routing protocol implicitly. Thomas> I did not see any mentioning of this. > If only the regular unicast routing table is used for MRIB, the > regular IPv6-IPv6 tunnel for PMIPv6 is used. Thomas> I guess it's not: as mentioned earlier, PMIP routing does not work like ordinary unicast routing, but with source-dependent flapping of routing tables. I don't think PIM could live with this. > If operators want to > populate routes for specific multicast channels over M-Tunnel into > MRIB, M-Tunnel is used. As well, if a separate routing protocol is > used for MRIB, M-Tunnel is used. > > Does this make sense? Thomas> In general, yes. One can populate the M-tunnels with specific MRIBs. My problem with this idea is that I don't see any reasonable way to do this - because these routes will be permanent and cannot flip with the Mobile Subscriber that initiates the multicast forwarding. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Tue Jul 26 08:31:48 2011 Return-Path: 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 79E8811E8112 for ; Tue, 26 Jul 2011 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9h-xzAwniwVF for ; Tue, 26 Jul 2011 08:31:47 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id B858011E810B for ; Tue, 26 Jul 2011 08:31:47 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qljbm-000NJ9-Ab; Tue, 26 Jul 2011 17:31:47 +0200 Message-ID: <4E2EDDE1.3040501@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 11:31:45 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <1311614610.55768.YahooMailRC@web111416.mail.gq1.yahoo.com> <4E2DAE80.9040207@informatik.haw-hamburg.de> <20110726.181219.168602339.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110726.181219.168602339.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: behcetsarikaya@yahoo.com, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:31:48 -0000 Hi, On 26.07.2011 05:12, Hitoshi Asaeda wrote: >>> If MAG is deciding then there is only one choice, the LMA to which the >>> MN is >>> associated. >> >> According to the draft, MAG runs PIM-SM. So PIM will decide according >> to its MFIB. Normally, this is derived from unicast routing - but as >> Stig pointed out in the meeting - one can configure an MFIB >> independent of the unicast routing. > > Right. PIM-SM works with MRIB, and MRIB is organized from unicast > routing protocol or separate protocol. > (BTW, you have been saying MFIB, but I expect MRIB is correct in your > contexts.) > Thomas> pardon, this is BGP language. In PIM, (M)FIB = (M)RIB ... so no need to distinguish. >> The more important problem here seems the PMIP routing behavior. As >> clarified in the discussion with Alexandru and Raj, PMIP routing does >> not work like "ordinary unicast routing". Depending on the MNs source >> ID, the default route is chosen to point to the appropriate MAG<-> >> LMA tunnel - a behavior which is outside the regular IP routing (and >> cannot be expressed in the standard routing table, I suppose). In >> particular, it's hard to imagine how a (modified) PIM protocol could >> interact with this irregular PMIP routing. > > Yes. PMIPv6 may be unlike ordinal unicast routing protocol. > Separating RIB and MRIB is already the standard behavior in many > routing protocols. PIM-SM just refers to MRIB derived from RIB > organized for PMIPv6. > I don't imagine any problem, if PIM-SM is implemented along with the > RFC correctly. Thomas> As mentioned above: the problem is PMIP routing. You cannot express PMIP routing within a standard-conformal PIM MRIB. There is an open request to the PIM WG chair whether he can imagine any way to introduce a PMIP-type routing table flapping into PIM-SM :-) > >> If you just deployed a PIM >> daemon on a MAG, PMIP would most likely remain invisible to PIM and - >> as said earlier - PIM would plainly interact with the >> provider-internal basic unicast routing layer. > > PMIPv6 itself does not need to communicate with PIM-SM, if PMIPv6 > organizes RIB correctly. Thomas> The problem is: it cannot "organize RIB correctly". And implementations most likely will not use standard-type RIBs. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From contreras.uc3m@gmail.com Tue Jul 26 12:45:39 2011 Return-Path: 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 3671D21F8508 for ; Tue, 26 Jul 2011 12:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VIFDRpddIJ9t for ; Tue, 26 Jul 2011 12:45:37 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2427D21F8500 for ; Tue, 26 Jul 2011 12:45:37 -0700 (PDT) Received: by pzk6 with SMTP id 6so1266011pzk.26 for ; Tue, 26 Jul 2011 12:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3z9ajQqCa7rcVunYFstw8e1JdWnSySWDvXXFmX9KbmA=; b=lqCiIAYak7f+IwFzQD4TZ1axHENoCgRDzq9HoGbE2uHPZ5fQx2kO4WjO3EZ2CweMvq gP1xm44YBFKgbSS9DBCn9b9mtkQNOu1Gih7caue5srBI49ZY0en5HKBU5n+6MbiXPfO4 5ENPvYu9O1VsCidin6PcPbsjOgvYF7mfG0waA= MIME-Version: 1.0 Received: by 10.68.34.227 with SMTP id c3mr11063844pbj.346.1311709536647; Tue, 26 Jul 2011 12:45:36 -0700 (PDT) Received: by 10.68.40.67 with HTTP; Tue, 26 Jul 2011 12:45:36 -0700 (PDT) In-Reply-To: References: <1311607272.10685.28.camel@acorde.it.uc3m.es> Date: Tue, 26 Jul 2011 21:45:36 +0200 Message-ID: From: "Luis M. Contreras" To: Matthias Waehlisch Content-Type: multipart/alternative; boundary=bcaec520f23ffaf80504a8fe2ce9 Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 19:45:39 -0000 --bcaec520f23ffaf80504a8fe2ce9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Matthias, thanks for your comments. This paper tries to be a prospective insight abou= t the feasability of an internal signalling protocol to acelerate multicast delivery to a MN after handover. It is based on public references to establish the potential benefits of this proposal, assuming the best performace case in some situations (for instance, no MLD response time by the MN, etc) to highlight that even in such case there is room for improvement with our proposal. A more precise analysis is however required to precisely obtain the improvements claimed. Please, find my answer in your mail: El 26 de julio de 2011 00:58, Matthias Waehlisch escrib= i=F3: > Hi Carlos, > > I had a short look at your paper. Your numerical evaluation is based > on a rough topology model. Overall, you argue that the delay between the > MN and MAG is larger compared to the delay between MAG and LMA. > > Some comments: > > * The authors of [18] analyzed the time a packet spends in a router. > This is more related to router modeling instead of path delay modeling. > From this perspective this seems not the correct modeling step for your > problem. > I assume you refer to reference [21] Papagiannaki et al. You are correct when stating that it is related to the time spent in one hop of an operator's network. The missing piece for considering path delay is the delay contribution due to the transmission part linking the routers of the operator's network. As per ITU-T G.114 spec, the contribution due to optical fiber can be considered to be 5 microseconds per km. That is, a contribution of 1ms implies a distance of 200 km between both ends. So, the impact of this contribution is clearly dependant on network size and topology. These two elements are difficult to handle in a general way. The topology under consideration in the paper assumes that both MAG and LMA are closer elements, not distant nodes (i.e., the distance among them is no= t as large as 200 km) . This is clearly an hypothesis, and it is based on current trends observed in real 3G networks, where the location of both SGS= N and GGSN tend to be close for both small networks (entities centralization) and medium-to.large networks (entities regionalization). We have taken this hypothesis in our considerations, in such a way that transmission contribution is negligible. Even if we center our analysis in a network deployment with extremal settings, for instance 1000km among MAG and LMA, the total contribution due to the transmission layer would be around 5 ms. This does not change the essence of the paper, which highlights a faster communnication internal to the network regarding to one relaying on the radio part, due to framing and other radio intrinsic properties which makes wireless part slower than wire= d part. > * You assumed that MAG and LMA reside in the same Autonomous System, > right? This is a valid assumption but must not be true in general. > Obviously this would change the delay (cf., "An AS-level Study of > Internet Path Delay Characteristics" GLOBECOM'04). For a more > well-grounded evaluation you should model the relation between MAG and > LMA in more detail. This could be interesting. > You are right, we are considering taht bot MAG and LMA are part of the same AS. In fact, I think this is the natural setting when talking of multicast in PMIPv6. You should be aware that IGMP/MLD are multicast membership protocols, that is, they are protocols among a host part and a router part. I wonder how a host (MLD proxy in MAG) can inetract with a router (LMA) any of them being lloacted in different ASs.Normal interdomain multicast is carried out among routers running some interdomain routing protocol. The situation of a host and a router in different AS appears to me as the exception, not as the normal deployment. Note for instance that an IGMP/MLD report coming from the MAG would be send with an IP address of a different AS towards the LMA. How the LMA learn suc= h address? Is there BGP among MAG and LMA? Is there some static route being advertised through BGP for the tunnel links? Can the LMA reach the MAG IP address via another way different to the tunnel? (with BGP running among both ASs I assume yes). In summary, we assume that both entities are in the same AS. This appears t= o us as the natural deployment, at least for multicast service. > > * For the backhaul delay you use 5 ms referring to the 3GPP standard. > I would doubt that this is realistic, in particular compared to the > LMA-MAG delay. First, the standard cannot define the delay between the > NodeB and the MAG. Second, the NodeB should be obviously in the > topological vicinity of the MAG. In other words, if you assume a > significant large delay between NodeB and MAG but a short delay between > MAG and LMA, you could 'directly' attach the NodeB to the LMA. > I agree that the 3GPP standard can not define the delay. It is only an indication, a reasonable value to be considered as reference, as the one also proposed by the NGMN Alliance. We use them because also in this case the value to be assumed is dependant of network size, topology and technology. A good survey of backhaul landscape can be found at the paper b= y Humai Raza "A Brief Survey of Radio Access Network Backhaul Evolution: Part I" in the IEEE Communications Magazine of June 2011. The backhaul networks are generally characterized by a large number of small/medium sites connected to centralised aggregation points in charge of concentrating traffic towards the core network. There are several solutions for such connection from the network architecture point of view (rings, nested rings, stars, chains, point-to-point, etc). Each of them has a different impact on the end-to-end delay budget. Several technologies can b= e used for backhaul: point-to-point (packet) microwave transmission, optical fiber, xDSL technologies (such as VDSL), etc. Those different technologies have distinct particularities in terms of performance, reliability and delay. All of them typically coexist in a real mobile network, in such a wa= y that a MN changing the point of attachment can pass smoothly from one solution to another. So, we take such value as reference considering it as an average of the delays that can be found in a real network, from the best case (optic fiber= , <1ms) to the worst case (xDSL, > 10ms). Once again, a hugher or lower value does not change the essence of the paper, in my opinion. > > * The comparison with RFC 6224 seems a bit unfair. It would > be more interesting to compare with the FMIP proposal, for example. > RAMS proposes an improvement regarding the base solution, so that is the reason of comparing it with the base solution. The comparisson with FPMIPv6 has to be done yet. > > Just to make sure that I'm not misunderstood: Your assumption > (reducing delay because MAG-LMA link is faster) is not uninteresting but > needs a more careful verification. You need a more detailed radio as > well as topology model to derive general protocol design insights. In > particular, you need more detailed information on current MAG/LMA > deployment within networks. > I agree that a more powerful characterization is needed, maybe by simulatio= n or by establishing a reference scenario. As I mentioned before, the aim of the paper is to be prospectivea bout the benefits of signalling internally to the network. We have used reference in the literature to prospect the interest of this protocol. Now it is time of performing an in depth characterization, once we conclude that it is interesting to explore this way to accelerate multicast delivery after handover. > > Best regards > matthias > > -- > Matthias Waehlisch > . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . Takustr. 9, D-14195 Berlin, Germany > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > > On Mon, 25 Jul 2011, Carlos Jes=FAs Bernardos Cano wrote: > > > Hi, > > > > For those interested, here is the link of the paper I mention analyzing > > the performance of our RAMS proposal: > > > > http://www.jowua.org/index.php/jowua/article/view/66/56 > > > > Comments would be more than welcome, of course. > > > > Thanks, > > > > Carlos > > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > --bcaec520f23ffaf80504a8fe2ce9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Matthias,
=A0
thanks for your comments. This paper tries to be a prospective insight= about the feasability of an internal signalling protocol to acelerate mult= icast delivery to a MN after handover. It is based on public references to = establish the potential benefits of this proposal, assuming the best perfor= mace case in some situations (for instance, no MLD response time by the MN,= etc) to highlight that even in such case there is room for improvement wit= h our proposal. A more precise analysis is however required to precisely ob= tain the improvements claimed.
=A0
Please, find=A0my answer=A0in your mail:

El 26 de julio de 2011 00:58, Matthias Waehlisch= <waehlisch@ieee.org> escribi=F3:
Hi Carlos,

=A0I had a sho= rt look at your paper. Your numerical evaluation is based
on a rough top= ology model. Overall, you argue that the delay between the
MN and MAG is larger compared to the delay between MAG and LMA.

=A0S= ome comments:

=A0* The authors of [18] analyzed the time a packet sp= ends in a router.
This is more related to router modeling instead of pat= h delay modeling.
>From this perspective this seems not the correct modeling step for your
= problem.
=A0
=A0I assume you refer to reference [21] Papagiannaki et al. You are co= rrect when stating that it is related to the time spent in one hop of an op= erator's network. The=A0missing piece for considering path delay is the= delay contribution due to the transmission part linking the routers of the= operator's network.
As per ITU-T G.114 spec, the contribution due to optical fiber can be = considered to be 5 microseconds per km. That is, a contribution of 1ms impl= ies a distance of 200 km between both ends. So, the impact of this contribu= tion is clearly dependant on network size and topology. These two elements = are difficult to handle in a general way.
The topology under consideration in the paper assumes that both MAG an= d LMA are closer elements, not distant nodes (i.e., the distance among them= is not as large as 200 km) . This is clearly an hypothesis, and it is=A0ba= sed on current trends observed in real 3G networks, where the location of b= oth SGSN and GGSN tend to be close for both small networks (entities centra= lization) and medium-to.large networks (entities regionalization). We have = taken this hypothesis in our considerations, in such a way that transmissio= n contribution is negligible.
Even if we center our analysis in a network deployment with extremal s= ettings, for instance 1000km among MAG and LMA, the total contribution due = to the transmission layer would be around 5 ms. This does not change the es= sence of the paper, which highlights a faster communnication internal to th= e network regarding to one relaying on the radio part, due to framing and o= ther radio intrinsic properties which makes wireless part slower than wired= part.
=A0
=A0* You assumed that MAG and LM= A reside in the same Autonomous System,
right? This is a valid assumptio= n but must not be true in general.
Obviously this would change the delay (cf., "An AS-level Study of
I= nternet Path Delay Characteristics" GLOBECOM'04). For a more
we= ll-grounded evaluation you should model the relation between MAG and
LMA in more detail. This could be interesting.
=A0
You are right, we are considering taht bot MAG and LMA are part of the= same AS. In fact, I think this is the natural setting when talking of mult= icast in PMIPv6. You should be aware that IGMP/MLD are multicast membership= protocols, that is, they are protocols among a host part and a router part= . I wonder how a host (MLD proxy in MAG) can inetract with a router (LMA) a= ny of them being lloacted in different ASs.Normal interdomain multicast is = carried out among routers running some interdomain routing protocol. The si= tuation of a host and a router in different AS appears to me as the excepti= on, not as the normal deployment.
Note for instance that an IGMP/MLD report coming from the MAG would be= send with an IP address of a different AS towards the LMA. How the LMA lea= rn such address? Is there BGP among MAG and LMA? Is there some static route= being advertised through BGP for the tunnel links? Can the LMA reach the M= AG IP address via another way different to the tunnel? (with BGP running am= ong both ASs I assume yes).
In summary, we assume that both entities are in the same AS. This appe= ars to us as the natural deployment, at least for multicast service.
=A0

=A0* For the backhaul delay = you use 5 ms referring to the 3GPP standard.
I would doubt that this is = realistic, in particular compared to the
LMA-MAG delay. First, the standard cannot define the delay between the
N= odeB and the MAG. Second, the NodeB should be obviously in the
topologic= al vicinity of the MAG. In other words, if you assume a
significant larg= e delay between NodeB and MAG but a short delay between
MAG and LMA, you could 'directly' attach the NodeB to the LMA.
<= /blockquote>
=A0
I agree that the 3GPP standard can not define the delay. It is only an= indication, a reasonable value to be considered as reference, as the one a= lso proposed by the NGMN Alliance.=A0We use them because also in this case = the value to be assumed is dependant of network size, topology and technolo= gy. A good survey of backhaul landscape can be found at the paper by Humai = Raza "A Brief Survey of Radio Access Network Backhaul Evolution: Part = I" in the IEEE Communications Magazine of June 2011.
The backhaul networks are generally characterized by a large number of= small/medium sites connected to centralised aggregation points in charge o= f concentrating traffic towards the core network. There are several solutio= ns for such connection from the network architecture point of view (rings, = nested rings, stars, chains, point-to-point, etc). Each of them has a diffe= rent impact on the end-to-end delay budget. Several technologies can be use= d for backhaul: point-to-point (packet) microwave transmission, optical fib= er, xDSL technologies (such as VDSL), etc. Those different technologies hav= e distinct particularities in terms of performance, reliability and delay. = All of them typically coexist in a real mobile network, in such a way that = a MN changing the point of attachment can pass smoothly from one solution t= o another.
So, we take such value as reference considering it as an average of th= e delays that can be found in a real network, from=A0the best case (optic f= iber, <1ms) to the worst case (xDSL, > 10ms). Once again, a hugher or= lower value does not change the essence of the paper, in my opinion.
=A0
=A0

=A0* The comparison with RFC= 6224 seems a bit unfair. It would
be more interesting to compare with t= he FMIP proposal, for example.
RAMS proposes an improvement regarding the base solution, so that is t= he reason of comparing it with the base solution. The comparisson with FPMI= Pv6 has to be done yet.
=A0

=A0Just to make sure that I&= #39;m not misunderstood: Your assumption
(reducing delay because MAG-LMA= link is faster) is not uninteresting but
needs a more careful verification. You need a more detailed radio as
wel= l as topology model to derive general protocol design insights. In
parti= cular, you need more detailed information on current MAG/LMA
deployment = within networks.
I agree that a more powerful characterization is needed, maybe by simu= lation or by establishing a reference scenario. As I mentioned before, the = aim of the paper is to be prospectivea bout the benefits of signalling inte= rnally to the network.=A0 We have used reference in the literature to prosp= ect the interest of this protocol. Now it is time of performing an in depth= characterization, once we conclude that it is interesting to explore this = way to accelerate multicast delivery after handover.
=A0

Best regards
=A0matthias<= br>
--
Matthias Waehlisch
. =A0Freie Unive= rsitaet Berlin, Inst. fuer Informatik, AG CST
. =A0Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin= .de/~waehl
:. Also: http= ://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Mon, 25 Jul 2011, Carlos Jes=FAs Bernardos Cano wrote:

&= gt; Hi,
>
> For those interested, here is the link of the paper= I mention analyzing
> the performance of our RAMS proposal:
><= br> > http://www.jowua.org/index.php/jowua/article/view/66/56=
>
> Comments would be more than welcome, of course.
> > Thanks,
>
> Carlos
>
>

_______= ________________________________________
multimob mailing list
multimob@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/multimob" target=3D"_blank"= >https://www.ietf.org/mailman/listinfo/multimob


--bcaec520f23ffaf80504a8fe2ce9-- From contreras.uc3m@gmail.com Tue Jul 26 12:54:12 2011 Return-Path: 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 78C5F11E8094 for ; Tue, 26 Jul 2011 12:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 aqSNwLweQncP for ; Tue, 26 Jul 2011 12:54:11 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8197C11E8088 for ; Tue, 26 Jul 2011 12:54:11 -0700 (PDT) Received: by pzk6 with SMTP id 6so1275939pzk.26 for ; Tue, 26 Jul 2011 12:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1i8izB9jUPViFiO/q+lLBSuH/y+v8rzm9QAw3vNRxDo=; b=bRG86TFy9BC/9uq9X/GA2gGjBKlzfngLCyaRMdSREs9Wcf2pjotnINWsnfVmwbFMU2 nKdGRHJ1mCBYK7lbmxxbXcfPaW1wSDzT4NLHdVpLJ3FnSeE/PoYZhXuZpOob+Ma8fpl7 8/nFn9vo/QnseRlyk5mtTLbp+8v+YgkH+rhfE= MIME-Version: 1.0 Received: by 10.68.46.99 with SMTP id u3mr11170644pbm.78.1311710049598; Tue, 26 Jul 2011 12:54:09 -0700 (PDT) Received: by 10.68.40.67 with HTTP; Tue, 26 Jul 2011 12:54:09 -0700 (PDT) In-Reply-To: <4E2DFC73.8040809@informatik.haw-hamburg.de> References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 21:54:09 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=bcaec5396bd28dfee404a8fe4bb2 Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 19:54:12 -0000 --bcaec5396bd28dfee404a8fe4bb2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LMA <-= > nMAG message, but not necessarily if you need more than 1 message in the pMAG <-> nMAG dialogue. I think the key point is that you are relaying in L2 capabilities to create the pMAG <-> nMAG dialogue. But those capabilities are not the general case= . However, the path pMAG <-> LMA <-> nMAG is naturally available, independently of the L2 capabilities. Best regards, Luis 2011/7/26 Thomas C. Schmidt > Hi Juan Carlos, Carlos, > > IMO the reasonable comparison in the context transfer routing is > > (i) pMAG <-> nMAG versus > > (ii) pMAG <-> LMA <-> nMAG > > The corresponding links are all wired and pMAG is adjacent to nMAG. > > From all reasonable topologies I can imagine, (i) should be an order of > magnitude shorter than (ii). > > Cheers, > > Thomas > > > On 25.07.2011 18:58, Matthias Waehlisch wrote: > >> Hi Carlos, >> >> I had a short look at your paper. Your numerical evaluation is based >> on a rough topology model. Overall, you argue that the delay between the >> MN and MAG is larger compared to the delay between MAG and LMA. >> >> Some comments: >> >> * The authors of [18] analyzed the time a packet spends in a router. >> This is more related to router modeling instead of path delay modeling. >> From this perspective this seems not the correct modeling step for your >> problem. >> >> * You assumed that MAG and LMA reside in the same Autonomous System, >> right? This is a valid assumption but must not be true in general. >> Obviously this would change the delay (cf., "An AS-level Study of >> Internet Path Delay Characteristics" GLOBECOM'04). For a more >> well-grounded evaluation you should model the relation between MAG and >> LMA in more detail. This could be interesting. >> >> * For the backhaul delay you use 5 ms referring to the 3GPP standard. >> I would doubt that this is realistic, in particular compared to the >> LMA-MAG delay. First, the standard cannot define the delay between the >> NodeB and the MAG. Second, the NodeB should be obviously in the >> topological vicinity of the MAG. In other words, if you assume a >> significant large delay between NodeB and MAG but a short delay between >> MAG and LMA, you could 'directly' attach the NodeB to the LMA. >> >> * The comparison with RFC 6224 seems a bit unfair. It would >> be more interesting to compare with the FMIP proposal, for example. >> >> >> Just to make sure that I'm not misunderstood: Your assumption >> (reducing delay because MAG-LMA link is faster) is not uninteresting but >> needs a more careful verification. You need a more detailed radio as >> well as topology model to derive general protocol design insights. In >> particular, you need more detailed information on current MAG/LMA >> deployment within networks. >> >> >> >> Best regards >> matthias >> >> >> >> >> ______________________________**_________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/**listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-**hamburg.de/~schmidt Fax: +49-40-42875-8409 =B0 > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --bcaec5396bd28dfee404a8fe4bb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
this holds if you compare 1 pMAG <-> nMAG=A0message against 1 pM= AG <-> LMA <-> nMAG message, but not necessarily if you need mo= re than 1 message in the pMAG <-> nMAG dialogue.
=A0
I think the key point is that you are relaying in L2 capabilities to c= reate the pMAG <-> nMAG dialogue. But those capabilities are not the = general case. However, the path pMAG <-> LMA <-> nMAG is natura= lly available, independently of the L2 capabilities.
=A0
Best regards,
=A0
Luis


2011/7/26 Thomas C. Schmidt &l= t;schmidt@informatik.h= aw-hamburg.de>
Hi Juan Carlos, Carlos,

= =A0IMO the reasonable comparison in the context transfer routing is

= =A0(i) =A0 pMAG <-> nMAG versus

=A0(ii) =A0pMAG <-> LMA <-> nMAG

The corresponding l= inks are all wired and pMAG is adjacent to nMAG.

From all reasonable= topologies I can imagine, (i) should be an order of magnitude shorter than= (ii).

Cheers,

Thomas=20


On 25.07.2011 18:58, Matthias Waehlisch wrote:
Hi Carlos,

=A0 I had a short look at your paper. Y= our numerical evaluation is based
on a rough topology model. Overall, yo= u argue that the delay between the
MN and MAG is larger compared to the = delay between MAG and LMA.

=A0 Some comments:

=A0 * The authors of [18] analyzed the time a= packet spends in a router.
This is more related to router modeling inst= ead of path delay modeling.
=A0From this perspective this seems not the = correct modeling step for your
problem.

=A0 * You assumed that MAG and LMA reside in the same Auton= omous System,
right? This is a valid assumption but must not be true in = general.
Obviously this would change the delay (cf., "An AS-level S= tudy of
Internet Path Delay Characteristics" GLOBECOM'04). For a more
w= ell-grounded evaluation you should model the relation between MAG and
LM= A in more detail. This could be interesting.

=A0 * For the backhaul = delay you use 5 ms referring to the 3GPP standard.
I would doubt that this is realistic, in particular compared to the
LMA-= MAG delay. First, the standard cannot define the delay between the
NodeB= and the MAG. Second, the NodeB should be obviously in the
topological v= icinity of the MAG. In other words, if you assume a
significant large delay between NodeB and MAG but a short delay between
= MAG and LMA, you could 'directly' attach the NodeB to the LMA.
<= br>=A0 * The comparison with RFC 6224 seems a bit unfair. It would
be mo= re interesting to compare with the FMIP proposal, for example.


=A0 Just to make sure that I'm not misunderstood: Your assumpti= on
(reducing delay because MAG-LMA link is faster) is not uninteresting = but
needs a more careful verification. You need a more detailed radio as=
well as topology model to derive general protocol design insights. In
pa= rticular, you need more detailed information on current MAG/LMA
deployme= nt within networks.



Best regards
=A0 matthias




_______________________________________________<= br>multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/list= info/multimob

--

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg Univ= ersity of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berliner Tor= 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Ha= mburg, Germany =B0
=B0 http://www.haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Fon: +49-40-42875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax: += 49-40-42875-8409 =B0
____________________________________________= ___
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--bcaec5396bd28dfee404a8fe4bb2-- From schmidt@informatik.haw-hamburg.de Tue Jul 26 13:25:33 2011 Return-Path: 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 1DCF721F86C0 for ; Tue, 26 Jul 2011 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 y70WBt6RVl+v for ; Tue, 26 Jul 2011 13:25:32 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0714C21F86C3 for ; Tue, 26 Jul 2011 13:25:32 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [130.129.83.194] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QloC2-000ODL-Qw; Tue, 26 Jul 2011 22:25:31 +0200 Message-ID: <4E2F22BC.8090106@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 16:25:32 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Luis M. Contreras" References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:25:33 -0000 Hi Luis, two answers: (i) The network distance is *always* independent of the # of messages. (ii) In the (P)FMIP approach, only one message is exchanged for unicast (that includes the multicast option). So we actually have "zero" messages induced by multicast. The main point here is: The (P)FMIP draft produces an overall optimized handover, for unicast and synchronously for multicast (recall: you cannot overtake unicast. If unicast handover is slow, you cannot fix this on the multicast side). Regarding your L2 objection: (P)FMIP uses L2 information to predict the nMAG, otherwise it doesn't (remember: you called your approach predictive in the absence of a prediction ;) ). The transfer from pMAG to nMAG does not depend on special "L2 capabilities" ... this is ordinary IP routing which is present in most Inter-Networks ... Btw.: If you look at current WG activities in Netext http://tools.ietf.org/html/draft-ietf-netext-pmip-lr, you'll see that inter-MAG routing is used for traffic optimization. So there is not only common understanding that MAGs mutually participate in Internet routing, but also that the shortest distance from pMAG to nMAG must be expected to be the direct route. In a well-designed provider network, direct routes *are optimal*. (In the global Internet, this is not always true as we know about violations of the triangle inequality, but it is always the best guess.) Returning to the comparison: An approach that uses messaging sent on triangular routes cannot be as fast as the directly routed transfer. Cheers, Thomas On 26.07.2011 15:54, Luis M. Contreras wrote: > Hi Thomas, > this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LMA > <-> nMAG message, but not necessarily if you need more than 1 message in > the pMAG <-> nMAG dialogue. > I think the key point is that you are relaying in L2 capabilities to > create the pMAG <-> nMAG dialogue. But those capabilities are not the > general case. However, the path pMAG <-> LMA <-> nMAG is naturally > available, independently of the L2 capabilities. > Best regards, > Luis > > > 2011/7/26 Thomas C. Schmidt > > > Hi Juan Carlos, Carlos, > > IMO the reasonable comparison in the context transfer routing is > > (i) pMAG <-> nMAG versus > > (ii) pMAG <-> LMA <-> nMAG > > The corresponding links are all wired and pMAG is adjacent to nMAG. > > From all reasonable topologies I can imagine, (i) should be an > order of magnitude shorter than (ii). > > Cheers, > > Thomas > > > On 25.07.2011 18:58, Matthias Waehlisch wrote: > > Hi Carlos, > > I had a short look at your paper. Your numerical evaluation > is based > on a rough topology model. Overall, you argue that the delay > between the > MN and MAG is larger compared to the delay between MAG and LMA. > > Some comments: > > * The authors of [18] analyzed the time a packet spends in a > router. > This is more related to router modeling instead of path delay > modeling. > From this perspective this seems not the correct modeling step > for your > problem. > > * You assumed that MAG and LMA reside in the same Autonomous > System, > right? This is a valid assumption but must not be true in general. > Obviously this would change the delay (cf., "An AS-level Study of > Internet Path Delay Characteristics" GLOBECOM'04). For a more > well-grounded evaluation you should model the relation between > MAG and > LMA in more detail. This could be interesting. > > * For the backhaul delay you use 5 ms referring to the 3GPP > standard. > I would doubt that this is realistic, in particular compared to the > LMA-MAG delay. First, the standard cannot define the delay > between the > NodeB and the MAG. Second, the NodeB should be obviously in the > topological vicinity of the MAG. In other words, if you assume a > significant large delay between NodeB and MAG but a short delay > between > MAG and LMA, you could 'directly' attach the NodeB to the LMA. > > * The comparison with RFC 6224 seems a bit unfair. It would > be more interesting to compare with the FMIP proposal, for example. > > > Just to make sure that I'm not misunderstood: Your assumption > (reducing delay because MAG-LMA link is faster) is not > uninteresting but > needs a more careful verification. You need a more detailed radio as > well as topology model to derive general protocol design > insights. In > particular, you need more detailed information on current MAG/LMA > deployment within networks. > > > > Best regards > matthias > > > > > _________________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/__listinfo/multimob > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner > Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany ° > ° http://www.haw-hamburg.de/inet Fon: > +49-40-42875-8452 ° > ° http://www.informatik.haw-__hamburg.de/~schmidt > Fax: > +49-40-42875-8409 ° > _________________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/__listinfo/multimob > > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From cjbc@it.uc3m.es Tue Jul 26 13:49:09 2011 Return-Path: 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 D297511E80A1 for ; Tue, 26 Jul 2011 13:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_BACKHAIR_34=1, J_BACKHAIR_43=1, J_BACKHAIR_44=1, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 ydFu+gZUddUj for ; Tue, 26 Jul 2011 13:49:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 75AEC11E8097 for ; Tue, 26 Jul 2011 13:49:08 -0700 (PDT) X-uc3m-safe: yes Received: from [130.129.83.185] (dhcp-53b9.meeting.ietf.org [130.129.83.185]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 2B1D3C285F5; Tue, 26 Jul 2011 22:49:06 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" In-Reply-To: <4E2F22BC.8090106@informatik.haw-hamburg.de> References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> <4E2F22BC.8090106@informatik.haw-hamburg.de> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-onT2VckTnJPXs8vhAnoD" Organization: Universidad Carlos III de Madrid Date: Tue, 26 Jul 2011 22:49:03 +0200 Message-ID: <1311713344.12969.24.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18286.000 Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:49:09 -0000 --=-onT2VckTnJPXs8vhAnoD Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Thomas, On Tue, 2011-07-26 at 16:25 -0400, Thomas C. Schmidt wrote: > Hi Luis, >=20 > two answers: >=20 > (i) The network distance is *always* independent of the # of messages. You are quite right on that statement, but the comparison Luis was making was "1 message pMAG<-->LMA<-->nMAG vs n messages pMAG<-->nMAG" :D > (ii) In the (P)FMIP approach, only one message is exchanged for=20 > unicast (that includes the multicast option). So we actually have "zero"= =20 > messages induced by multicast. Multicast traffic nature should also be analyzed. Is it worth optimizing that much the performance for traffic that typically is not critical if one message is lost? Our draft tries to make a simple optimization, by making information about the subscription interests of the MN as soon as possible. Nothing more. no strong requirement needed (no security between MAGs, no FPMIP signalling, etc.). >=20 > The main point here is: The (P)FMIP draft produces an overall optimized= =20 > handover, for unicast and synchronously for multicast (recall: you=20 > cannot overtake unicast. If unicast handover is slow, you cannot fix=20 > this on the multicast side). Do we need that much complexity for multicast? We may have the scenario in which the "slow" unicast handover is perfectly fine (we have prototype implementations with quite low handovers delays in a local scenario) and still want to optimiza multicast. >=20 > Regarding your L2 objection: (P)FMIP uses L2 information to predict the= =20 > nMAG, otherwise it doesn't (remember: you called your approach=20 > predictive in the absence of a prediction ;) ). The transfer from pMAG= =20 > to nMAG does not depend on special "L2 capabilities" ... this is=20 > ordinary IP routing which is present in most Inter-Networks ... Yes, ordinary IP routing, but you assume that there always exist an shorter route between pMAG and nMAG, which might not be always the case. >=20 > Btw.: If you look at current WG activities in Netext=20 > http://tools.ietf.org/html/draft-ietf-netext-pmip-lr, you'll see that=20 > inter-MAG routing is used for traffic optimization. So there is not only= =20 > common understanding that MAGs mutually participate in Internet routing,= =20 > but also that the shortest distance from pMAG to nMAG must be expected= =20 > to be the direct route. In a well-designed provider network, direct=20 > routes *are optimal*. (In the global Internet, this is not always true= =20 > as we know about violations of the triangle inequality, but it is always= =20 > the best guess.) True, though the scope of that draft is not only MAG to MAG optimizations. >=20 > Returning to the comparison: An approach that uses messaging sent on=20 > triangular routes cannot be as fast as the directly routed transfer. And an approach that requires security associations between every pair of MAGs is not as simple to deploy as one that doesn't. Carlos >=20 > Cheers, >=20 > Thomas >=20 > On 26.07.2011 15:54, Luis M. Contreras wrote: > > Hi Thomas, > > this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LM= A > > <-> nMAG message, but not necessarily if you need more than 1 message i= n > > the pMAG <-> nMAG dialogue. > > I think the key point is that you are relaying in L2 capabilities to > > create the pMAG <-> nMAG dialogue. But those capabilities are not the > > general case. However, the path pMAG <-> LMA <-> nMAG is naturally > > available, independently of the L2 capabilities. > > Best regards, > > Luis > > > > > > 2011/7/26 Thomas C. Schmidt > > > > > > Hi Juan Carlos, Carlos, > > > > IMO the reasonable comparison in the context transfer routing is > > > > (i) pMAG <-> nMAG versus > > > > (ii) pMAG <-> LMA <-> nMAG > > > > The corresponding links are all wired and pMAG is adjacent to nMAG. > > > > From all reasonable topologies I can imagine, (i) should be an > > order of magnitude shorter than (ii). > > > > Cheers, > > > > Thomas > > > > > > On 25.07.2011 18:58, Matthias Waehlisch wrote: > > > > Hi Carlos, > > > > I had a short look at your paper. Your numerical evaluation > > is based > > on a rough topology model. Overall, you argue that the delay > > between the > > MN and MAG is larger compared to the delay between MAG and LMA. > > > > Some comments: > > > > * The authors of [18] analyzed the time a packet spends in a > > router. > > This is more related to router modeling instead of path delay > > modeling. > > From this perspective this seems not the correct modeling ste= p > > for your > > problem. > > > > * You assumed that MAG and LMA reside in the same Autonomous > > System, > > right? This is a valid assumption but must not be true in gener= al. > > Obviously this would change the delay (cf., "An AS-level Study = of > > Internet Path Delay Characteristics" GLOBECOM'04). For a more > > well-grounded evaluation you should model the relation between > > MAG and > > LMA in more detail. This could be interesting. > > > > * For the backhaul delay you use 5 ms referring to the 3GPP > > standard. > > I would doubt that this is realistic, in particular compared to= the > > LMA-MAG delay. First, the standard cannot define the delay > > between the > > NodeB and the MAG. Second, the NodeB should be obviously in the > > topological vicinity of the MAG. In other words, if you assume = a > > significant large delay between NodeB and MAG but a short delay > > between > > MAG and LMA, you could 'directly' attach the NodeB to the LMA. > > > > * The comparison with RFC 6224 seems a bit unfair. It would > > be more interesting to compare with the FMIP proposal, for exam= ple. > > > > > > Just to make sure that I'm not misunderstood: Your assumptio= n > > (reducing delay because MAG-LMA link is faster) is not > > uninteresting but > > needs a more careful verification. You need a more detailed rad= io as > > well as topology model to derive general protocol design > > insights. In > > particular, you need more detailed information on current MAG/L= MA > > deployment within networks. > > > > > > > > Best regards > > matthias > > > > > > > > > > _________________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > > > -- > > > > Prof. Dr. Thomas C. Schmidt > > =B0 Hamburg University of Applied Sciences Berlin= er > > Tor 7 =B0 > > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > > Germany =B0 > > =B0 http://www.haw-hamburg.de/inet Fon: > > +49-40-42875-8452 =B0 > > =B0 http://www.informatik.haw-__hamburg.de/~schmidt > > Fax: > > +49-40-42875-8409 =B0 > > _________________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-onT2VckTnJPXs8vhAnoD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4vKD8ACgkQNdy6TdFwT2dP1gCglyox0syK3mPTXZO4y5Z/WUZy 2scAn3nJtl72Q2mIdbPZ4rO5MF8rlqFU =YDOz -----END PGP SIGNATURE----- --=-onT2VckTnJPXs8vhAnoD-- From schmidt@informatik.haw-hamburg.de Tue Jul 26 14:04:04 2011 Return-Path: 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 6C54411E80B6 for ; Tue, 26 Jul 2011 14:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zvAQNFCMACdn for ; Tue, 26 Jul 2011 14:04:03 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88221F86BE for ; Tue, 26 Jul 2011 14:04:03 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-53c2.meeting.ietf.org ([130.129.83.194]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QlonK-0003bp-6O; Tue, 26 Jul 2011 23:04:02 +0200 Message-ID: <4E2F2BC3.2060204@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 17:04:03 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> <4E2F22BC.8090106@informatik.haw-hamburg.de> <1311713344.12969.24.camel@acorde.it.uc3m.es> In-Reply-To: <1311713344.12969.24.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:04:04 -0000 Hi Luis, On 26.07.2011 16:49, Carlos Jesús Bernardos Cano wrote: > >> (ii) In the (P)FMIP approach, only one message is exchanged for >> unicast (that includes the multicast option). So we actually have "zero" >> messages induced by multicast. > > Multicast traffic nature should also be analyzed. Is it worth optimizing > that much the performance for traffic that typically is not critical if > one message is lost? Our draft tries to make a simple optimization, by > making information about the subscription interests of the MN as soon as > possible. Nothing more. no strong requirement needed (no security > between MAGs, no FPMIP signalling, etc.). > Yes, I agree: your approach is simpler. However, it does not optimize (only slightly improve) the handover. The question is about the objective. My understanding is (which I questioned in the meeting and on the list yesterday) that we aim at optimizing mobility management to perform seamless handovers. And the answer we are trying to give is: A solution to minimize handover delays for unicast + multicast in *one* synchronized operation. >> >> The main point here is: The (P)FMIP draft produces an overall optimized >> handover, for unicast and synchronously for multicast (recall: you >> cannot overtake unicast. If unicast handover is slow, you cannot fix >> this on the multicast side). > > Do we need that much complexity for multicast? We may have the scenario > in which the "slow" unicast handover is perfectly fine (we have > prototype implementations with quite low handovers delays in a local > scenario) and still want to optimiza multicast. > This is a valid question. But if we don't need seamless handover, we can stay with the base solution and don't need extra context transfer. (As you could extract from the mail of Matthias: taking realistic numbers leads to an about equal performance of the base solution and your approach). >> >> Regarding your L2 objection: (P)FMIP uses L2 information to predict the >> nMAG, otherwise it doesn't (remember: you called your approach >> predictive in the absence of a prediction ;) ). The transfer from pMAG >> to nMAG does not depend on special "L2 capabilities" ... this is >> ordinary IP routing which is present in most Inter-Networks ... > > Yes, ordinary IP routing, but you assume that there always exist an > shorter route between pMAG and nMAG, which might not be always the case. > As mentioned before: direct routes within a provider network should be optimal. Cheers, Thomas >> On 26.07.2011 15:54, Luis M. Contreras wrote: >>> Hi Thomas, >>> this holds if you compare 1 pMAG<-> nMAG message against 1 pMAG<-> LMA >>> <-> nMAG message, but not necessarily if you need more than 1 message in >>> the pMAG<-> nMAG dialogue. >>> I think the key point is that you are relaying in L2 capabilities to >>> create the pMAG<-> nMAG dialogue. But those capabilities are not the >>> general case. However, the path pMAG<-> LMA<-> nMAG is naturally >>> available, independently of the L2 capabilities. >>> Best regards, >>> Luis >>> >>> >>> 2011/7/26 Thomas C. Schmidt>> > >>> >>> Hi Juan Carlos, Carlos, >>> >>> IMO the reasonable comparison in the context transfer routing is >>> >>> (i) pMAG<-> nMAG versus >>> >>> (ii) pMAG<-> LMA<-> nMAG >>> >>> The corresponding links are all wired and pMAG is adjacent to nMAG. >>> >>> From all reasonable topologies I can imagine, (i) should be an >>> order of magnitude shorter than (ii). >>> >>> Cheers, >>> >>> Thomas >>> >>> >>> On 25.07.2011 18:58, Matthias Waehlisch wrote: >>> >>> Hi Carlos, >>> >>> I had a short look at your paper. Your numerical evaluation >>> is based >>> on a rough topology model. Overall, you argue that the delay >>> between the >>> MN and MAG is larger compared to the delay between MAG and LMA. >>> >>> Some comments: >>> >>> * The authors of [18] analyzed the time a packet spends in a >>> router. >>> This is more related to router modeling instead of path delay >>> modeling. >>> From this perspective this seems not the correct modeling step >>> for your >>> problem. >>> >>> * You assumed that MAG and LMA reside in the same Autonomous >>> System, >>> right? This is a valid assumption but must not be true in general. >>> Obviously this would change the delay (cf., "An AS-level Study of >>> Internet Path Delay Characteristics" GLOBECOM'04). For a more >>> well-grounded evaluation you should model the relation between >>> MAG and >>> LMA in more detail. This could be interesting. >>> >>> * For the backhaul delay you use 5 ms referring to the 3GPP >>> standard. >>> I would doubt that this is realistic, in particular compared to the >>> LMA-MAG delay. First, the standard cannot define the delay >>> between the >>> NodeB and the MAG. Second, the NodeB should be obviously in the >>> topological vicinity of the MAG. In other words, if you assume a >>> significant large delay between NodeB and MAG but a short delay >>> between >>> MAG and LMA, you could 'directly' attach the NodeB to the LMA. >>> >>> * The comparison with RFC 6224 seems a bit unfair. It would >>> be more interesting to compare with the FMIP proposal, for example. >>> >>> >>> Just to make sure that I'm not misunderstood: Your assumption >>> (reducing delay because MAG-LMA link is faster) is not >>> uninteresting but >>> needs a more careful verification. You need a more detailed radio as >>> well as topology model to derive general protocol design >>> insights. In >>> particular, you need more detailed information on current MAG/LMA >>> deployment within networks. >>> >>> >>> >>> Best regards >>> matthias >>> >>> >>> >>> >>> _________________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/__listinfo/multimob >>> >>> >>> >>> -- >>> >>> Prof. Dr. Thomas C. Schmidt >>> ° Hamburg University of Applied Sciences Berliner >>> Tor 7 ° >>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>> Germany ° >>> ° http://www.haw-hamburg.de/inet Fon: >>> +49-40-42875-8452 ° >>> ° http://www.informatik.haw-__hamburg.de/~schmidt >>> Fax: >>> +49-40-42875-8409 ° >>> _________________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/__listinfo/multimob >>> >>> >>> >> > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From contreras.uc3m@gmail.com Tue Jul 26 14:42:25 2011 Return-Path: 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 CB93B5E8008 for ; Tue, 26 Jul 2011 14:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 cQbumYN+SCf1 for ; Tue, 26 Jul 2011 14:42:24 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF15E8002 for ; Tue, 26 Jul 2011 14:42:24 -0700 (PDT) Received: by pzk6 with SMTP id 6so1417410pzk.26 for ; Tue, 26 Jul 2011 14:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bRBmuiKkWJ+Jyd+tyDRXamcKQ0ALhZem08QIPe+G/a0=; b=NkW1GGTwClyJkr3t9gGBNJu3Chv8ElN/eqdiNKFdFUPsBcT3mpASsatszDACBfR2D2 EqD/nF6YKFiPJC2xhDIRd/x5ynMxDz6SPzDyh1duRgLC8QhPVdMnBk0dWQZkk6sCMuaD ujI8Tb13sL1/6y7i3cwQ6AQYOi0AKrJaaGcT8= MIME-Version: 1.0 Received: by 10.68.58.197 with SMTP id t5mr9688655pbq.480.1311716543373; Tue, 26 Jul 2011 14:42:23 -0700 (PDT) Received: by 10.68.40.67 with HTTP; Tue, 26 Jul 2011 14:42:23 -0700 (PDT) In-Reply-To: <4E2F22BC.8090106@informatik.haw-hamburg.de> References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> <4E2F22BC.8090106@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 23:42:23 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=bcaec544ea0c9d232c04a8ffceb4 Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:42:25 -0000 --bcaec544ea0c9d232c04a8ffceb4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, some comments below: 2011/7/26 Thomas C. Schmidt > Hi Luis, > > two answers: > > (i) The network distance is *always* independent of the # of messages. > Totally true. I mean the delay is not only dependant on the network distance, but on the times such distance is used to transfer the required information. > (ii) In the (P)FMIP approach, only one message is exchanged for unicast > (that includes the multicast option). So we actually have "zero" messages > induced by multicast. > In a similar scenario, in RAMS the multicast subscription information is piggybacked in the DeReg (pMAG) - Reg (nMAG) sequence, so no additional messages are needed. No messages induced by multicast, nor by handover support. This is applicable for the scenario we call (badly, of course) predictive case. > > The main point here is: The (P)FMIP draft produces an overall optimized > handover, for unicast and synchronously for multicast (recall: you cannot > overtake unicast. If unicast handover is slow, you cannot fix this on the > multicast side). > I have the multimob charter in mind, where the focus is multicast. Why don'= t unicast traffic can suffer an slower delay. It is easier to handle, as well as less sensitive to delay, in many cases. I think that a faster unicast handover is desirable, but in my opinion it can not force a solution for multicast. > > Regarding your L2 objection: (P)FMIP uses L2 information to predict the > nMAG, otherwise it doesn't (remember: you called your approach predictive= in > the absence of a prediction ;) ). The transfer from pMAG to nMAG does not > depend on special "L2 capabilities" ... this is ordinary IP routing which= is > present in most Inter-Networks ... > Ok, the name "predictive" is not well applied. It is used as the opposite t= o the reactive case, but I agree it is not well suited. I think that the transfer from pMAG to nMAG depends on special capabilities of L2 because those capabilities have to correctly identify nMAG. If such identification is not provided by L2, it is not possible to route the traffic to nMAG. Furthermore, those L2 capabilities will be dependant on th= e underlying radio technology. So generalization is not easy. > > Btw.: If you look at current WG activities in Netext > http://tools.ietf.org/html/**draft-ietf-netext-pmip-lr, > you'll see that inter-MAG routing is used for traffic optimization. So th= ere > is not only common understanding that MAGs mutually participate in Intern= et > routing, but also that the shortest distance from pMAG to nMAG must be > expected to be the direct route. In a well-designed provider network, dir= ect > routes *are optimal*. (In the global Internet, this is not always true as= we > know about violations of the triangle inequality, but it is always the be= st > guess.) > Here the point is the delay employed in finding such optimal routes. Wherea= s in a normal communication procedure (such as the one you reference) the tim= e is not critical, in the handover case it can become an important issue (eve= n more for multicast case). If we relay in radio dependant procedures, we wil= l experience a non uniform behavior (it depends on the underlaying radio technology), besides considering that not all the possible radio technologies can support the needed mechanisms to implement PFMIP. > > Returning to the comparison: An approach that uses messaging sent on > triangular routes cannot be as fast as the directly routed transfer. > The triangular route is intrinsic to the registration procedures defined in RFC5213. We take profit of that to augment the scope of such procedure to accelerate the acquisition of the subscription information. Important aspects such as the security associations (as highlighted by Carlos), the multicast groups acceptable by the nMAG, the capacity of nMAG to support multicast, etc resultis in a more lightweigth protocol > > Cheers, > > Thomas Best regards, Luis > > > On 26.07.2011 15:54, Luis M. Contreras wrote: > >> Hi Thomas, >> this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <-> LMA >> <-> nMAG message, but not necessarily if you need more than 1 message in >> the pMAG <-> nMAG dialogue. >> I think the key point is that you are relaying in L2 capabilities to >> create the pMAG <-> nMAG dialogue. But those capabilities are not the >> general case. However, the path pMAG <-> LMA <-> nMAG is naturally >> available, independently of the L2 capabilities. >> Best regards, >> Luis >> >> >> 2011/7/26 Thomas C. Schmidt >> >> >> >> >> >> Hi Juan Carlos, Carlos, >> >> IMO the reasonable comparison in the context transfer routing is >> >> (i) pMAG <-> nMAG versus >> >> (ii) pMAG <-> LMA <-> nMAG >> >> The corresponding links are all wired and pMAG is adjacent to nMAG. >> >> From all reasonable topologies I can imagine, (i) should be an >> order of magnitude shorter than (ii). >> >> Cheers, >> >> Thomas >> >> >> On 25.07.2011 18:58, Matthias Waehlisch wrote: >> >> Hi Carlos, >> >> I had a short look at your paper. Your numerical evaluation >> is based >> on a rough topology model. Overall, you argue that the delay >> between the >> MN and MAG is larger compared to the delay between MAG and LMA. >> >> Some comments: >> >> * The authors of [18] analyzed the time a packet spends in a >> router. >> This is more related to router modeling instead of path delay >> modeling. >> From this perspective this seems not the correct modeling step >> for your >> problem. >> >> * You assumed that MAG and LMA reside in the same Autonomous >> System, >> right? This is a valid assumption but must not be true in general= . >> Obviously this would change the delay (cf., "An AS-level Study of >> Internet Path Delay Characteristics" GLOBECOM'04). For a more >> well-grounded evaluation you should model the relation between >> MAG and >> LMA in more detail. This could be interesting. >> >> * For the backhaul delay you use 5 ms referring to the 3GPP >> standard. >> I would doubt that this is realistic, in particular compared to t= he >> LMA-MAG delay. First, the standard cannot define the delay >> between the >> NodeB and the MAG. Second, the NodeB should be obviously in the >> topological vicinity of the MAG. In other words, if you assume a >> significant large delay between NodeB and MAG but a short delay >> between >> MAG and LMA, you could 'directly' attach the NodeB to the LMA. >> >> * The comparison with RFC 6224 seems a bit unfair. It would >> be more interesting to compare with the FMIP proposal, for exampl= e. >> >> >> Just to make sure that I'm not misunderstood: Your assumption >> (reducing delay because MAG-LMA link is faster) is not >> uninteresting but >> needs a more careful verification. You need a more detailed radio >> as >> well as topology model to derive general protocol design >> insights. In >> particular, you need more detailed information on current MAG/LMA >> deployment within networks. >> >> >> >> Best regards >> matthias >> >> >> >> >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org >> >> https://www.ietf.org/mailman/_**_listinfo/multimob >> >> > >> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner >> Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-__**hamburg.de/~schmidt >> > >> Fax: >> +49-40-42875-8409 =B0 >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org >> >> https://www.ietf.org/mailman/_**_listinfo/multimob >> >> > >> >> >> > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-**hamburg.de/~schmidt Fax: +49-40-42875-8409 =B0 > --bcaec544ea0c9d232c04a8ffceb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

some comments below:

20= 11/7/26 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de><= br>
Hi Luis,

two answers:

=A0(i) The network distance is *always* independent of the # of messages.

Totally true. I mean the delay is not only dependan= t on the network distance, but on the times such distance is used to transf= er the required information.
=A0
=A0(ii) In the (P)FMIP approach, only one message is exchanged for unicast = (that includes the multicast option). So we actually have "zero" = messages induced by multicast.

In a similar scenar= io, in RAMS the multicast subscription information is piggybacked in the De= Reg (pMAG) - Reg (nMAG) sequence, so no additional messages are needed. No = messages induced by multicast, nor by handover support. This is applicable = for the scenario we call (badly, of course) predictive case.
=A0

The main point here is: The (P)FMIP draft produces an overall optimized han= dover, for unicast and synchronously for multicast (recall: you cannot over= take unicast. If unicast handover is slow, you cannot fix this on the multi= cast side).

I have the multimob charter in mind, where the focus = is multicast. Why don't unicast traffic can suffer an slower delay. It = is easier to handle, as well as less sensitive to delay, in many cases. I t= hink that a faster unicast handover is desirable, but in my opinion it can = not force a solution for multicast.
=A0

Regarding your L2 objection: (P)FMIP uses L2 information to predict the nMA= G, otherwise it doesn't (remember: you called your approach predictive = in the absence of a prediction ;) ). The transfer from pMAG to nMAG does no= t depend on special "L2 capabilities" ... this is ordinary IP rou= ting which is present in most Inter-Networks ...

Ok, the name "predictive" is not well appli= ed. It is used as the opposite to the reactive case, but I agree it is not = well suited.
I think that the transfer from pMAG to nMAG depends on spec= ial capabilities of L2 because those capabilities have to correctly identif= y nMAG. If such identification is not provided by L2, it is not possible to= route the traffic to nMAG. Furthermore, those L2 capabilities will be depe= ndant on the underlying radio technology. So generalization is not easy. =A0

Btw.: If you look at current WG activities in Netext http://tools.i= etf.org/html/draft-ietf-netext-pmip-lr, you'll see that inte= r-MAG routing is used for traffic optimization. So there is not only common= understanding that MAGs mutually participate in Internet routing, but also= that the shortest distance from pMAG to nMAG must be expected to be the di= rect route. In a well-designed provider network, direct routes *are optimal= *. (In the global Internet, this is not always true as we know about violat= ions of the triangle inequality, but it is always the best guess.)

Here the point is the delay employed in finding such = optimal routes. Whereas in a normal communication procedure (such as the on= e you reference) the time is not critical, in the handover case it can beco= me an important issue (even more for multicast case). If we relay in radio = dependant procedures, we will experience a non uniform behavior (it depends= on the underlaying radio technology), besides considering that not all the= possible radio technologies can support the needed mechanisms to implement= PFMIP.
=A0

Returning to the comparison: An approach that uses messaging sent on triang= ular routes cannot be as fast as the directly routed transfer.

The triangular route is intrinsic to the registration procedur= es defined in RFC5213. We take profit of that to augment the scope of such = procedure to accelerate the acquisition of the subscription information. Im= portant aspects such as the security associations (as highlighted by Carlos= ), the multicast groups acceptable by the nMAG, the capacity of nMAG to sup= port multicast, etc resultis in a more lightweigth protocol
=A0

Cheers,

Thomas

Best regards,

Luis


On 26.07.2011 15:54, Luis M. Contreras wrote:
Hi Thomas,
this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG <= -> LMA
<-> nMAG message, but not necessarily if you need more than 1 message= in
the pMAG <-> nMAG dialogue.
I think the key point is that you are relaying in L2 capabilities to
create the pMAG <-> nMAG dialogue. But those capabilities are not the=
general case. However, the path pMAG <-> LMA <-> nMAG is natura= lly
available, independently of the L2 capabilities.
Best regards,
Luis


2011/7/26 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
<mailto:schmidt@informatik.haw-hamburg.de>>
=


=A0 =A0Hi Juan Carlos, Carlos,

=A0 =A0 =A0IMO the reasonable comparison in the context transfer routing i= s

=A0 =A0 =A0(i) =A0 pMAG <-> nMAG versus

=A0 =A0 =A0(ii) =A0pMAG <-> LMA <-> nMAG

=A0 =A0The corresponding links are all wired and pMAG is adjacent to nMAG.=

=A0 =A0 From all reasonable topologies I can imagine, (i) should be an
=A0 =A0order of magnitude shorter than (ii).

=A0 =A0Cheers,

=A0 =A0Thomas


=A0 =A0On 25.07.2011 18:58, Matthias Waehlisch wrote:

=A0 =A0 =A0 =A0Hi Carlos,

=A0 =A0 =A0 =A0 =A0 I had a short look at your paper. Your numerical evalu= ation
=A0 =A0 =A0 =A0is based
=A0 =A0 =A0 =A0on a rough topology model. Overall, you argue that the dela= y
=A0 =A0 =A0 =A0between the
=A0 =A0 =A0 =A0MN and MAG is larger compared to the delay between MAG and = LMA.

=A0 =A0 =A0 =A0 =A0 Some comments:

=A0 =A0 =A0 =A0 =A0 * The authors of [18] analyzed the time a packet spend= s in a
=A0 =A0 =A0 =A0router.
=A0 =A0 =A0 =A0This is more related to router modeling instead of path del= ay
=A0 =A0 =A0 =A0modeling.
=A0 =A0 =A0 =A0 =A0From this perspective this seems not the correct modeli= ng step
=A0 =A0 =A0 =A0for your
=A0 =A0 =A0 =A0problem.

=A0 =A0 =A0 =A0 =A0 * You assumed that MAG and LMA reside in the same Auto= nomous
=A0 =A0 =A0 =A0System,
=A0 =A0 =A0 =A0right? This is a valid assumption but must not be true in g= eneral.
=A0 =A0 =A0 =A0Obviously this would change the delay (cf., "An AS-lev= el Study of
=A0 =A0 =A0 =A0Internet Path Delay Characteristics" GLOBECOM'04).= For a more
=A0 =A0 =A0 =A0well-grounded evaluation you should model the relation betw= een
=A0 =A0 =A0 =A0MAG and
=A0 =A0 =A0 =A0LMA in more detail. This could be interesting.

=A0 =A0 =A0 =A0 =A0 * For the backhaul delay you use 5 ms referring to the= 3GPP
=A0 =A0 =A0 =A0standard.
=A0 =A0 =A0 =A0I would doubt that this is realistic, in particular compare= d to the
=A0 =A0 =A0 =A0LMA-MAG delay. First, the standard cannot define the delay<= br> =A0 =A0 =A0 =A0between the
=A0 =A0 =A0 =A0NodeB and the MAG. Second, the NodeB should be obviously in= the
=A0 =A0 =A0 =A0topological vicinity of the MAG. In other words, if you ass= ume a
=A0 =A0 =A0 =A0significant large delay between NodeB and MAG but a short d= elay
=A0 =A0 =A0 =A0between
=A0 =A0 =A0 =A0MAG and LMA, you could 'directly' attach the NodeB = to the LMA.

=A0 =A0 =A0 =A0 =A0 * The comparison with RFC 6224 seems a bit unfair. It = would
=A0 =A0 =A0 =A0be more interesting to compare with the FMIP proposal, for = example.


=A0 =A0 =A0 =A0 =A0 Just to make sure that I'm not misunderstood: Your= assumption
=A0 =A0 =A0 =A0(reducing delay because MAG-LMA link is faster) is not
=A0 =A0 =A0 =A0uninteresting but
=A0 =A0 =A0 =A0needs a more careful verification. You need a more detailed= radio as
=A0 =A0 =A0 =A0well as topology model to derive general protocol design =A0 =A0 =A0 =A0insights. In
=A0 =A0 =A0 =A0particular, you need more detailed information on current M= AG/LMA
=A0 =A0 =A0 =A0deployment within networks.



=A0 =A0 =A0 =A0Best regards
=A0 =A0 =A0 =A0 =A0 matthias




=A0 =A0 =A0 =A0_________________________________________________ =A0 =A0 =A0 =A0multimob mailing list
=A0 =A0 =A0 =A0mult= imob@ietf.org <mailto:multimob@ietf.org>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/__listinfo/multimob=
=A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/multimob= >


=A0 =A0--

=A0 =A0Prof. Dr. Thomas C. Schmidt
=A0 =A0=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Berliner
=A0 =A0Tor 7 =B0
=A0 =A0=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamb= urg,
=A0 =A0Germany =B0
=A0 =A0=B0 ht= tp://www.haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: =A0 =A0+49-40-42875-8452 =B0
=A0 =A0=B0 http://www.informatik.haw-__hamburg.de/~schmidt=
=A0 =A0<http://www.informatik.haw-hamburg.de/~schmidt>= =A0 =A0Fax:
=A0 =A0+49-40-42875-8409 =B0
=A0 =A0_________________________________________________
=A0 =A0multimob mailing list
=A0 =A0multimob@iet= f.org <mailto:multimob@ietf.org>

=A0 =A0https://www.ietf.org/mailman/__listinfo/multimob
=A0 =A0<https://www.ietf.org/mailman/listinfo/multimob>=



--

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Berliner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamburg, Ger= many =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42= 875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax:= +49-40-42875-8409 =B0

--bcaec544ea0c9d232c04a8ffceb4-- From schmidt@informatik.haw-hamburg.de Tue Jul 26 14:56:32 2011 Return-Path: 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 84C1F11E80B3 for ; Tue, 26 Jul 2011 14:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DuvPS3ugGSAw for ; Tue, 26 Jul 2011 14:56:31 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 03F7211E8093 for ; Tue, 26 Jul 2011 14:56:30 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-53c2.meeting.ietf.org ([130.129.83.194]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qlpc5-0009on-Fg; Tue, 26 Jul 2011 23:56:29 +0200 Message-ID: <4E2F380E.6010600@informatik.haw-hamburg.de> Date: Tue, 26 Jul 2011 17:56:30 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Luis M. Contreras" References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> <4E2F22BC.8090106@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:56:32 -0000 Hi Luis, On 26.07.2011 17:42, Luis M. Contreras wrote: > > The main point here is: The (P)FMIP draft produces an overall > optimized handover, for unicast and synchronously for multicast > (recall: you cannot overtake unicast. If unicast handover is slow, > you cannot fix this on the multicast side). > > > I have the multimob charter in mind, where the focus is multicast. Why > don't unicast traffic can suffer an slower delay. It is easier to > handle, as well as less sensitive to delay, in many cases. I think that > a faster unicast handover is desirable, but in my opinion it can not > force a solution for multicast. > Sure, but I'm arguing the other way round: Multicast cannot be better than the unicast configuration and seamless handover for multicast can only go with seamless unicast handover. For this it makes a lot of sense to me to plug into a standardized solution for unicast. > > Regarding your L2 objection: (P)FMIP uses L2 information to predict > the nMAG, otherwise it doesn't (remember: you called your approach > predictive in the absence of a prediction ;) ). The transfer from > pMAG to nMAG does not depend on special "L2 capabilities" ... this > is ordinary IP routing which is present in most Inter-Networks ... > > > Ok, the name "predictive" is not well applied. It is used as the > opposite to the reactive case, but I agree it is not well suited. > I think that the transfer from pMAG to nMAG depends on special > capabilities of L2 because those capabilities have to correctly identify > nMAG. If such identification is not provided by L2, it is not possible > to route the traffic to nMAG. Furthermore, those L2 capabilities will be > dependant on the underlying radio technology. So generalization is not easy. > You point to the predictive case: (P)FMIP does both, predictive and reactive handover. As far as I know, predictions always rely on L2 information (actually on L1 sensing). > > Btw.: If you look at current WG activities in Netext > http://tools.ietf.org/html/__draft-ietf-netext-pmip-lr > , you'll see > that inter-MAG routing is used for traffic optimization. So there is > not only common understanding that MAGs mutually participate in > Internet routing, but also that the shortest distance from pMAG to > nMAG must be expected to be the direct route. In a well-designed > provider network, direct routes *are optimal*. (In the global > Internet, this is not always true as we know about violations of the > triangle inequality, but it is always the best guess.) > > > Here the point is the delay employed in finding such optimal routes. > Whereas in a normal communication procedure (such as the one you > reference) the time is not critical, in the handover case it can become > an important issue (even more for multicast case). If we relay in radio > dependant procedures, we will experience a non uniform behavior (it > depends on the underlaying radio technology), besides considering that > not all the possible radio technologies can support the needed > mechanisms to implement PFMIP. > Which radio technologies do you refer to? (My understanding: you can always do radio sensing, even though this may be done at different places (MN or base station). > > Returning to the comparison: An approach that uses messaging sent on > triangular routes cannot be as fast as the directly routed transfer. > > > The triangular route is intrinsic to the registration procedures defined > in RFC5213. We take profit of that to augment the scope of such > procedure to accelerate the acquisition of the subscription information. > Important aspects such as the security associations (as highlighted by > Carlos), the multicast groups acceptable by the nMAG, the capacity of > nMAG to support multicast, etc resultis in a more lightweigth protocol > Yes, RFC5213 does it the triangular way. That's why I argue that doing better requires more than 5213 unicast. Cheers, Thomas > > > On 26.07.2011 15:54, Luis M. Contreras wrote: > > Hi Thomas, > this holds if you compare 1 pMAG <-> nMAG message against 1 pMAG > <-> LMA > <-> nMAG message, but not necessarily if you need more than 1 > message in > the pMAG <-> nMAG dialogue. > I think the key point is that you are relaying in L2 capabilities to > create the pMAG <-> nMAG dialogue. But those capabilities are > not the > general case. However, the path pMAG <-> LMA <-> nMAG is naturally > available, independently of the L2 capabilities. > Best regards, > Luis > > > 2011/7/26 Thomas C. Schmidt > >> > > > Hi Juan Carlos, Carlos, > > IMO the reasonable comparison in the context transfer > routing is > > (i) pMAG <-> nMAG versus > > (ii) pMAG <-> LMA <-> nMAG > > The corresponding links are all wired and pMAG is adjacent > to nMAG. > > From all reasonable topologies I can imagine, (i) should be an > order of magnitude shorter than (ii). > > Cheers, > > Thomas > > > On 25.07.2011 18:58, Matthias Waehlisch wrote: > > Hi Carlos, > > I had a short look at your paper. Your numerical > evaluation > is based > on a rough topology model. Overall, you argue that the delay > between the > MN and MAG is larger compared to the delay between MAG > and LMA. > > Some comments: > > * The authors of [18] analyzed the time a packet > spends in a > router. > This is more related to router modeling instead of path > delay > modeling. > From this perspective this seems not the correct > modeling step > for your > problem. > > * You assumed that MAG and LMA reside in the same > Autonomous > System, > right? This is a valid assumption but must not be true > in general. > Obviously this would change the delay (cf., "An AS-level > Study of > Internet Path Delay Characteristics" GLOBECOM'04). For a > more > well-grounded evaluation you should model the relation > between > MAG and > LMA in more detail. This could be interesting. > > * For the backhaul delay you use 5 ms referring to > the 3GPP > standard. > I would doubt that this is realistic, in particular > compared to the > LMA-MAG delay. First, the standard cannot define the delay > between the > NodeB and the MAG. Second, the NodeB should be obviously > in the > topological vicinity of the MAG. In other words, if you > assume a > significant large delay between NodeB and MAG but a > short delay > between > MAG and LMA, you could 'directly' attach the NodeB to > the LMA. > > * The comparison with RFC 6224 seems a bit unfair. It > would > be more interesting to compare with the FMIP proposal, > for example. > > > Just to make sure that I'm not misunderstood: Your > assumption > (reducing delay because MAG-LMA link is faster) is not > uninteresting but > needs a more careful verification. You need a more > detailed radio as > well as topology model to derive general protocol design > insights. In > particular, you need more detailed information on > current MAG/LMA > deployment within networks. > > > > Best regards > matthias > > > > > ___________________________________________________ > multimob mailing list > multimob@ietf.org > > > > https://www.ietf.org/mailman/____listinfo/multimob > > > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences > Berliner > Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 > Hamburg, > Germany ° > ° http://www.haw-hamburg.de/inet Fon: > +49-40-42875-8452 ° > ° http://www.informatik.haw-____hamburg.de/~schmidt > > > Fax: > +49-40-42875-8409 ° > ___________________________________________________ > multimob mailing list > multimob@ietf.org > > > > https://www.ietf.org/mailman/____listinfo/multimob > > > > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner > Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany ° > ° http://www.haw-hamburg.de/inet Fon: > +49-40-42875-8452 ° > ° http://www.informatik.haw-__hamburg.de/~schmidt > Fax: > +49-40-42875-8409 ° > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From contreras.uc3m@gmail.com Tue Jul 26 15:03:52 2011 Return-Path: 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 A712511E80A2 for ; Tue, 26 Jul 2011 15:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SuYGaI5j7Lmm for ; Tue, 26 Jul 2011 15:03:52 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id E397C11E8093 for ; Tue, 26 Jul 2011 15:03:51 -0700 (PDT) Received: by pzk6 with SMTP id 6so1441865pzk.26 for ; Tue, 26 Jul 2011 15:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B/A0uDaKsuW0bthKShIZO2ac7jjwtw7LYUUi7Bhk2Q8=; b=xLvmk5Yr96wAmGds/tHF6U/Vs2KcQF5WwJKsBMTpAZut3z54VOdYGHG9a67bbApyqh ukl1xfvjBqpReu9lM1VfqD5S9/yy3RpaM9Rmz8YCMA38jTy1Jtz4Q/M+4glaYjMhr7t6 Claob5cUuH8p7Tp3uhhVpp3Unafbcxe+9L50I= MIME-Version: 1.0 Received: by 10.68.30.97 with SMTP id r1mr11136375pbh.413.1311717831464; Tue, 26 Jul 2011 15:03:51 -0700 (PDT) Received: by 10.68.40.67 with HTTP; Tue, 26 Jul 2011 15:03:51 -0700 (PDT) In-Reply-To: <4E2F2BC3.2060204@informatik.haw-hamburg.de> References: <1311607272.10685.28.camel@acorde.it.uc3m.es> <4E2DFC73.8040809@informatik.haw-hamburg.de> <4E2F22BC.8090106@informatik.haw-hamburg.de> <1311713344.12969.24.camel@acorde.it.uc3m.es> <4E2F2BC3.2060204@informatik.haw-hamburg.de> Date: Wed, 27 Jul 2011 00:03:51 +0200 Message-ID: From: "Luis M. Contreras" To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=bcaec51dd08563d66b04a9001be4 Cc: multimob@ietf.org Subject: Re: [multimob] Performance analysis paper mentioned during the session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:03:52 -0000 --bcaec51dd08563d66b04a9001be4 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, some extra comments below 2011/7/26 Thomas C. Schmidt > >> > > Yes, I agree: your approach is simpler. However, it does not optimize (only > slightly improve) the handover. > Well, RAMS provides the multicast subscription information to nMAG at registration time, once the MN certainly attaches to nMAG. If the MN finally does not attach the nMAG there is no impact in the network (no extra signalling, nor tunnels, nor authentication, nor L2 procedures, etc). The subscription information is obtained without extra signalling when the MN is firstly de-registrated from pMAG, and only with a pair of messages between LMA and pMAG in the reactive case. I think it is something better than an slight improve. > > The question is about the objective. My understanding is (which I > questioned in the meeting and on the list yesterday) that we aim at > optimizing mobility management to perform seamless handovers. And the answer > we are trying to give is: A solution to minimize handover delays for unicast > + multicast in *one* synchronized operation. > > > I'm not sure if it is the objective of the Multimob wg, but to optimise multicast handover. Even in such case, one synchornized operation for both, your point of view is to adapt unicast-suited procedures to multicast. Maybe the way is to think on multicast-suited procedures and then to extend them to unicast. We can not drop any solution for multicast only due that in the unicast case there is now a solution. > >>> The main point here is: The (P)FMIP draft produces an overall optimized >>> handover, for unicast and synchronously for multicast (recall: you >>> cannot overtake unicast. If unicast handover is slow, you cannot fix >>> this on the multicast side). >>> >> >> Do we need that much complexity for multicast? We may have the scenario >> in which the "slow" unicast handover is perfectly fine (we have >> prototype implementations with quite low handovers delays in a local >> scenario) and still want to optimiza multicast. >> >> > This is a valid question. But if we don't need seamless handover, we can > stay with the base solution and don't need extra context transfer. (As you > could extract from the mail of Matthias: taking realistic numbers leads to > an about equal performance of the base solution and your approach). Sorry, I disagree. Only considering the framing of the radio technology, and the MLD response time taken by the MN (set to 0 in our paper, being between 0 and 1 s in current vendors operating systems) it is clear that RAMS is superior. > > > >>> > Cheers, > > Thomas > > Best regards, Luis --bcaec51dd08563d66b04a9001be4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

some extra comments below

2011/7/26 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>



Yes, I agree: your approach is simpler. However, it does not optimize (only= slightly improve) the handover.

Well, RAMS provid= es the multicast subscription information to nMAG at registration time, onc= e the MN certainly attaches to nMAG. If the MN finally does not attach the = nMAG there is no impact in the network (no extra signalling, nor tunnels, n= or authentication, nor L2 procedures, etc). The subscription information is= obtained without extra signalling when the MN is firstly de-registrated fr= om pMAG, and only with a pair of messages between LMA and pMAG in the react= ive case. I think it is something better than an slight improve.
=A0

The question is about the objective. My understanding is (which I questione= d in the meeting and on the list yesterday) that we aim at optimizing mobil= ity management to perform seamless handovers. And the answer we are trying = to give is: A solution to minimize handover delays for unicast + multicast = in *one* synchronized operation.



I'm not sure if it is the objective of = the Multimob wg, but to optimise multicast handover. Even in such case, one= synchornized operation for both, your point of view is to adapt unicast-su= ited procedures to multicast. Maybe the way is to think on multicast-suited= procedures and then to extend them to unicast. We can not drop any solutio= n for multicast only due that in the unicast case there is now a solution.<= br> =A0

The main point here is: The (P)FMIP draft produces an overall optimized
handover, for unicast and synchronously for multicast (recall: you
cannot overtake unicast. If unicast handover is slow, you cannot fix
this on the multicast side).

Do we need that much complexity for multicast? We may have the scenario
in which the "slow" unicast handover is perfectly fine (we have prototype implementations with quite low handovers delays in a local
scenario) and still want to optimiza multicast.


This is a valid question. But if we don't need seamless handover, we ca= n stay with the base solution and don't need extra context transfer. (A= s you could extract from the mail of Matthias: taking realistic numbers lea= ds to an about equal performance of the base solution and your approach).

Sorry, I disagree. Only considering the framing of the radio techn= ology, and the MLD response time taken by the MN (set to 0 in our paper, be= ing between 0 and 1 s in current vendors operating systems) it is clear tha= t RAMS is superior.
=A0




Cheers,

Thomas


Best regards,

Luis
<= /div> --bcaec51dd08563d66b04a9001be4-- From Osvaldo.Gonsa@eu.panasonic.com Wed Jul 27 00:19:01 2011 Return-Path: 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 03AC611E8087 for ; Wed, 27 Jul 2011 00:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vyAMEJsciCHP for ; Wed, 27 Jul 2011 00:18:58 -0700 (PDT) Received: from cluster-j.mailcontrol.com (cluster-j.mailcontrol.com [85.115.54.190]) by ietfa.amsl.com (Postfix) with ESMTP id CF4DA11E807A for ; Wed, 27 Jul 2011 00:18:54 -0700 (PDT) Received: from rly27j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly27j.srv.mailcontrol.com (MailControl) with ESMTP id p6R7IWLM017256 for ; Wed, 27 Jul 2011 08:18:52 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly27j.srv.mailcontrol.com (MailControl) id p6R7I864011262 for ; Wed, 27 Jul 2011 08:18:08 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly27j-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id p6R7I6Or010672 (TLS bits=128 verify=NO); Wed, 27 Jul 2011 08:18:07 +0100 (BST) Received: from eundadmi01.pan.eu ([10.109.33.22]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2011072709180474-974283 ; Wed, 27 Jul 2011 09:18:04 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 8.5.1FP4) with ESMTP id 2011072709160850-219912 ; Wed, 27 Jul 2011 09:16:08 +0200 X-Footer: cGFuYXNvbmljLmRl Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 27 Jul 2011 09:16:04 +0200 Received: from [10.10.150.94] ([10.10.150.94]) by lan-ex-02.panasonic.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 09:09:45 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> <4E2DCC94.1010704@informatik.haw-hamburg.de> <4E2E7ADF.8090200@panasonic.de> <4E2ED640.3020900@informatik.haw-hamburg.de> In-Reply-To: <4E2ED640.3020900@informatik.haw-hamburg.de> X-Enigmail-Version: 1.1.1 X-OriginalArrivalTime: 27 Jul 2011 07:09:45.0538 (UTC) FILETIME=[2A17DA20:01CC4C2C] X-TNEFEvaluated: 1 Message-ID: <4E2FB9B9.1070603@panasonic.de> Date: Wed, 27 Jul 2011 09:09:45 +0200 From: Osvaldo Gonsa X-MIMETrack: Itemize by SMTP Server on EUNDADMI01/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 27.07.2011 09:16:08, Serialize by Router on EUNDADMI01/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 27.07.2011 09:18:04, Serialize complete at 27.07.2011 09:18:04, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/27/2011 09:18:04 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/27/2011 09:18:07 AM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MailControl A-12-00-01 (www.mailcontrol.com) on 10.74.1.137 Cc: multimob@ietf.org Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 07:19:01 -0000 Hello Thomas and many thanks for your reply. Although I wouldn't like to argue about the cases you write below (goal missing, etc), I would like to point to the fact that the multicast broadcast systems that have been standardised (3GPP MBMS) do not utilise any context transfer for the multicast. But as I also said, that was done mainly to simplify the system. Obviously on those days the scenario you mention about football was also considered and also discussed that with the appropriate buffer levels this discomfort of missing the key play will be minimised. Some more comments below, On 26/07/2011 16:59, Thomas C. Schmidt wrote: > Dear Osvaldo, > > thanks for the feedback. > > On 26.07.2011 04:29, Osvaldo Gonsa wrote: > >> just to ask for clarification on the actual "need" for context transfer >> in the multicast application. Normally in commercial/standardised >> systems there is no "handover" of the multicast stream. This was mainly >> done to simplify things. > > Question: What kind of "commercial/standardised systems" do you have > in mind? > >> Now, another reason was that typical multicast >> applications like streaming TV/radio or PoC can tolerate very well the >> handover interruption due to radio instabilities. > > This basically depends on the handover delay/interruption (and the > tolerance of the codec), I believe. Still, in a typical soccer game, > the hot period of goal hitting is very brief. If your receiver looses > the critical packets due to handover, the user will miss the exciting > moments. > >> It was/is even >> possible to receive multicast/broadcast data while the terminal operates >> in Idle mode. > > I suppose you're talking about a non-IP world here: an IP node is not > able to receive IP streams without an IP interface configured. A terminal that is in Idle mode still is configured at the IP level, only its radio was configured to wake up at specific times when the downlink multicast data were supposed to arrive. But nevertheless the terminal had always its IP interface configured. Sorry for the confusion. > >> Then my question to you is, what kind of applications do you have in >> mind that will benefit for having such context transfer for multicast. >> And if you allow me one more question, wouldn't be sufficient that >> higher layers take care of any retransmission if packet loss happens and >> would this be noticeable to the end-user? >> > > There are many higher layer solutions that can compensate packet loss > (on the multicast transport or the coding side). There are two > limitations with it > > 1. They need to be in place (and the IP layer is intended to work > fine without special compensations at higher layers) > 2. They impose (partly significant) delays which make retransmissions > etc. infeasible for real-time traffic s.u. conversational/interactive > services (conferencing, games, ...). > > Best regards, > > Thomas My thinking of higher layer solutions was thinking that TCP flows (which IMHO are always "in place") have their re-transmission mechanism or UDP flows could be well handled with appropriate buffering. Interactive real-time communications (except for gaming) have less strict requirements for delay and packet loss. I must admit that for mobile multi-player gaming there may be a good case due to the strict requirements on delay and packet loss, but besides that (and the commercial viability of it) I couldn't think of a valid case requiring the context transfer in multicast scenario, therefore my initial question. Thank you very much for your time with my Best Regards Osvaldo > >> On 25/07/2011 22:05, Thomas C. Schmidt wrote: >>> Hi Dirk, >>> >>> I guess we need to carefully distinguish here: There is packet loss >>> due to slow handovers (MN disconnect), and packet loss due to many >>> other reasons (e.g., radio instability ...). >>> >>> The latter we cannot address at all, the first is mainly a result of >>> handover performance. So this improves with accelerated >>> unicast+multicast handover performance. >>> >>> Regarding context broadcasting: "cannot we imagine a combined context >>> transfer of all uni- and multicast sessions?" >>> >>> What would this be good for? I guess, context is always >>> interface-specific (otherwise multicast content will be delivered to >>> all interfaces simultaneously ...) >>> >>> Cheers, >>> >>> Thomas >>> >>> On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: >>>> Hi Thomas, >>>> So if one understands "seamless" to include being lossless and more >>>> reliable, I would agree. >>>> Since multicast in contrast to unicast mostly is not acknowledged by >>>> each receiver I would stress the options of context transfer to >>>> reduce loss of data during handover thanks to storage at p-MAG and >>>> perhaps also including AAA information or similar MN subscription >>>> details which could delay the completion of subscription process >>>> after handover. >>>> >>>> And regarding synchronisation with unicast: cannot we imagine a >>>> combined context transfer of all uni- and multicast sessions? >>>> >>>> Best regards >>>> Dirk >>>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >>>> Auftrag von Thomas C. Schmidt >>>> Gesendet: Montag, 25. Juli 2011 20:45 >>>> An: multimob@ietf.org >>>> Betreff: [multimob] Multicast Context Transfer >>>> >>>> Hi all, >>>> >>>> unfortunately, we did not reach a conclusion or clear picture on the >>>> subject of context transfer during the meeting. >>>> >>>> It seems good to work on settling objectives first. >>>> >>>> Thus the question: Can we agree on the following two purposes of >>>> context >>>> transfer? >>>> >>>> 1. Accelerate handover / make handover seamless >>>> 2. Switch to dedicated multicast links in a vertical handover >>>> (e.g., >>>> select a cheap/high quality broadcast link ...) >>>> >>>> Cheers, >>>> >>>> Thomas >>>> --=20 >>>> >>>> Prof. Dr. Thomas C. Schmidt >>>> =B0 Hamburg University of Applied Sciences Berliner >>>> Tor 7 =B0 >>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>> Germany =B0 >>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>> +49-40-42875-8452 =B0 >>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>> +49-40-42875-8409 =B0 >>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>>> multimob mailing list >>>> multimob@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > --=20 Dr-Ing. Osvaldo Gonsa (ECE) Panasonic Frankfurt Laboratory Panasonic R&D Center Germany GmbH D-63225 Langen, Germany Tel.:+49-6103-766-250 Fax :+49-6103-766-166 Email: osvaldo.gonsa@eu.panasonic.com --------------------------------- The problem with the future is that it keeps turning into the present.... ---------------------------------- Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke From schmidt@informatik.haw-hamburg.de Wed Jul 27 10:29:55 2011 Return-Path: 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 B0A8D21F8779 for ; Wed, 27 Jul 2011 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3KLlLCtdUKql for ; Wed, 27 Jul 2011 10:29:54 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA7A21F8777 for ; Wed, 27 Jul 2011 10:29:53 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-53c2.meeting.ietf.org ([130.129.83.194]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qm7vT-0005vb-4Z; Wed, 27 Jul 2011 19:29:52 +0200 Message-ID: <4E304B08.5070404@informatik.haw-hamburg.de> Date: Wed, 27 Jul 2011 13:29:44 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Osvaldo Gonsa References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> <4E2DCC94.1010704@informatik.haw-hamburg.de> <4E2E7ADF.8090200@panasonic.de> <4E2ED640.3020900@informatik.haw-hamburg.de> <4E2FB9B9.1070603@panasonic.de> In-Reply-To: <4E2FB9B9.1070603@panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: multimob@ietf.org Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:29:55 -0000 Dear Osvaldo, thanks for adding to the discussion! On 27.07.2011 03:09, Osvaldo Gonsa wrote: > Hello Thomas and many thanks for your reply. > Although I wouldn't like to argue about the cases you write below (goal > missing, etc), I would like to point to the fact that the multicast > broadcast systems that have been standardised (3GPP MBMS) do not utilise > any context transfer for the multicast. But as I also said, that was > done mainly to simplify the system. Well, we are currently looking ahead of MBMS ... also, IETF claims to take the lead in developing L2.5++ protocols ; > Some more comments below, > >>> It was/is even >>> possible to receive multicast/broadcast data while the terminal operates >>> in Idle mode. >> >> I suppose you're talking about a non-IP world here: an IP node is not >> able to receive IP streams without an IP interface configured. > > A terminal that is in Idle mode still is configured at the IP level, > only its radio was configured to wake up at specific times when the > downlink multicast data were supposed to arrive. But nevertheless the > terminal had always its IP interface configured. Sorry for the confusion. > Thanks, I was confused. You are talking about L1/2 energy saving. I guess this is unrelated to context transfer, but interesting: which L2 technologies can support multicast reception in idle mode? (802.11 does not, I suppose). > > My thinking of higher layer solutions was thinking that TCP flows (which > IMHO are always "in place") have their re-transmission mechanism or UDP > flows could be well handled with appropriate buffering. > Interactive real-time communications (except for gaming) have less > strict requirements for delay and packet loss. I must admit that for > mobile multi-player gaming there may be a good case due to the strict > requirements on delay and packet loss, but besides that (and the > commercial viability of it) I couldn't think of a valid case requiring > the context transfer in multicast scenario, therefore my initial question. > I guess conferencing is such a use case, as well. Conversational audio in particular is quite sensitive to disruptions and delays. Best regards, Thomas >> >>> On 25/07/2011 22:05, Thomas C. Schmidt wrote: >>>> Hi Dirk, >>>> >>>> I guess we need to carefully distinguish here: There is packet loss >>>> due to slow handovers (MN disconnect), and packet loss due to many >>>> other reasons (e.g., radio instability ...). >>>> >>>> The latter we cannot address at all, the first is mainly a result of >>>> handover performance. So this improves with accelerated >>>> unicast+multicast handover performance. >>>> >>>> Regarding context broadcasting: "cannot we imagine a combined context >>>> transfer of all uni- and multicast sessions?" >>>> >>>> What would this be good for? I guess, context is always >>>> interface-specific (otherwise multicast content will be delivered to >>>> all interfaces simultaneously ...) >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: >>>>> Hi Thomas, >>>>> So if one understands "seamless" to include being lossless and more >>>>> reliable, I would agree. >>>>> Since multicast in contrast to unicast mostly is not acknowledged by >>>>> each receiver I would stress the options of context transfer to >>>>> reduce loss of data during handover thanks to storage at p-MAG and >>>>> perhaps also including AAA information or similar MN subscription >>>>> details which could delay the completion of subscription process >>>>> after handover. >>>>> >>>>> And regarding synchronisation with unicast: cannot we imagine a >>>>> combined context transfer of all uni- and multicast sessions? >>>>> >>>>> Best regards >>>>> Dirk >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >>>>> Auftrag von Thomas C. Schmidt >>>>> Gesendet: Montag, 25. Juli 2011 20:45 >>>>> An: multimob@ietf.org >>>>> Betreff: [multimob] Multicast Context Transfer >>>>> >>>>> Hi all, >>>>> >>>>> unfortunately, we did not reach a conclusion or clear picture on the >>>>> subject of context transfer during the meeting. >>>>> >>>>> It seems good to work on settling objectives first. >>>>> >>>>> Thus the question: Can we agree on the following two purposes of >>>>> context >>>>> transfer? >>>>> >>>>> 1. Accelerate handover / make handover seamless >>>>> 2. Switch to dedicated multicast links in a vertical handover >>>>> (e.g., >>>>> select a cheap/high quality broadcast link ...) >>>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> -- >>>>> >>>>> Prof. Dr. Thomas C. Schmidt >>>>> ° Hamburg University of Applied Sciences Berliner >>>>> Tor 7 ° >>>>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>> Germany ° >>>>> ° http://www.haw-hamburg.de/inet Fon: >>>>> +49-40-42875-8452 ° >>>>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>> +49-40-42875-8409 ° >>>>> _______________________________________________ >>>>> multimob mailing list >>>>> multimob@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >>> >> > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Dirk.von-Hugo@telekom.de Wed Jul 27 12:49:02 2011 Return-Path: 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 DDE8611E8075 for ; Wed, 27 Jul 2011 12:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 oE2BIYGecy42 for ; Wed, 27 Jul 2011 12:49:01 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8953A11E8073 for ; Wed, 27 Jul 2011 12:49:00 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jul 2011 21:48:52 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.241]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 27 Jul 2011 21:48:52 +0200 From: To: , Date: Wed, 27 Jul 2011 21:48:50 +0200 Thread-Topic: [multimob] Multicast Context Transfer Thread-Index: AcxMgtB1s4FSeJxVSoql4aopQLEPRAADzcQg Message-ID: <05C81A773E48DD49B181B04BA21A342A263E9AA9F1@HE113484.emea1.cds.t-internal.com> References: <4E2DB9B3.7060800@informatik.haw-hamburg.de> <05C81A773E48DD49B181B04BA21A342A25BC5644F7@HE113484.emea1.cds.t-internal.com> <4E2DCC94.1010704@informatik.haw-hamburg.de> <4E2E7ADF.8090200@panasonic.de> <4E2ED640.3020900@informatik.haw-hamburg.de> <4E2FB9B9.1070603@panasonic.de> <4E304B08.5070404@informatik.haw-hamburg.de> In-Reply-To: <4E304B08.5070404@informatik.haw-hamburg.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Multicast Context Transfer X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:49:03 -0000 Dear all, Thanks! For me the discussion emphasizes that it is important to detail the= actual use cases and applications for the multicast scenario: Whereas there are applications which are very sensitive to delay (and sligh= tly less to loss) as the conferencing mentioned by Thomas others are less s= ensitive to HO latency thanks to built in buffering mode, but can't cope wi= th data loss (I think that applies for web AV streaming) and others can cop= e with both (e.g. multicast download of software updates for multitude of t= erminals) ... Just as examples. To a certain extent such context may also be exchanged between MAGs and LMA= as Carlos proposes. Similarily application specifics were also discussed in the MEXT-related ad= -hoc meeting this morning where an according prefix coloring and mapping to= different application QoS constraints was proposed ... AFAIRC by Sri Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Thomas C. Schmidt Gesendet: Mittwoch, 27. Juli 2011 19:30 An: Osvaldo Gonsa Cc: multimob@ietf.org Betreff: Re: [multimob] Multicast Context Transfer Dear Osvaldo, thanks for adding to the discussion! On 27.07.2011 03:09, Osvaldo Gonsa wrote: > Hello Thomas and many thanks for your reply. > Although I wouldn't like to argue about the cases you write below (goal > missing, etc), I would like to point to the fact that the multicast > broadcast systems that have been standardised (3GPP MBMS) do not utilise > any context transfer for the multicast. But as I also said, that was > done mainly to simplify the system. Well, we are currently looking ahead of MBMS ... also, IETF claims to take the lead in developing L2.5++ protocols ; > Some more comments below, > >>> It was/is even >>> possible to receive multicast/broadcast data while the terminal operate= s >>> in Idle mode. >> >> I suppose you're talking about a non-IP world here: an IP node is not >> able to receive IP streams without an IP interface configured. > > A terminal that is in Idle mode still is configured at the IP level, > only its radio was configured to wake up at specific times when the > downlink multicast data were supposed to arrive. But nevertheless the > terminal had always its IP interface configured. Sorry for the confusion. > Thanks, I was confused. You are talking about L1/2 energy saving. I guess this is unrelated to context transfer, but interesting: which L2 technologies can support multicast reception in idle mode? (802.11 does not, I suppose). > > My thinking of higher layer solutions was thinking that TCP flows (which > IMHO are always "in place") have their re-transmission mechanism or UDP > flows could be well handled with appropriate buffering. > Interactive real-time communications (except for gaming) have less > strict requirements for delay and packet loss. I must admit that for > mobile multi-player gaming there may be a good case due to the strict > requirements on delay and packet loss, but besides that (and the > commercial viability of it) I couldn't think of a valid case requiring > the context transfer in multicast scenario, therefore my initial question= . > I guess conferencing is such a use case, as well. Conversational audio in particular is quite sensitive to disruptions and delays. Best regards, Thomas >> >>> On 25/07/2011 22:05, Thomas C. Schmidt wrote: >>>> Hi Dirk, >>>> >>>> I guess we need to carefully distinguish here: There is packet loss >>>> due to slow handovers (MN disconnect), and packet loss due to many >>>> other reasons (e.g., radio instability ...). >>>> >>>> The latter we cannot address at all, the first is mainly a result of >>>> handover performance. So this improves with accelerated >>>> unicast+multicast handover performance. >>>> >>>> Regarding context broadcasting: "cannot we imagine a combined context >>>> transfer of all uni- and multicast sessions?" >>>> >>>> What would this be good for? I guess, context is always >>>> interface-specific (otherwise multicast content will be delivered to >>>> all interfaces simultaneously ...) >>>> >>>> Cheers, >>>> >>>> Thomas >>>> >>>> On 25.07.2011 14:57, Dirk.von-Hugo@telekom.de wrote: >>>>> Hi Thomas, >>>>> So if one understands "seamless" to include being lossless and more >>>>> reliable, I would agree. >>>>> Since multicast in contrast to unicast mostly is not acknowledged by >>>>> each receiver I would stress the options of context transfer to >>>>> reduce loss of data during handover thanks to storage at p-MAG and >>>>> perhaps also including AAA information or similar MN subscription >>>>> details which could delay the completion of subscription process >>>>> after handover. >>>>> >>>>> And regarding synchronisation with unicast: cannot we imagine a >>>>> combined context transfer of all uni- and multicast sessions? >>>>> >>>>> Best regards >>>>> Dirk >>>>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im >>>>> Auftrag von Thomas C. Schmidt >>>>> Gesendet: Montag, 25. Juli 2011 20:45 >>>>> An: multimob@ietf.org >>>>> Betreff: [multimob] Multicast Context Transfer >>>>> >>>>> Hi all, >>>>> >>>>> unfortunately, we did not reach a conclusion or clear picture on the >>>>> subject of context transfer during the meeting. >>>>> >>>>> It seems good to work on settling objectives first. >>>>> >>>>> Thus the question: Can we agree on the following two purposes of >>>>> context >>>>> transfer? >>>>> >>>>> 1. Accelerate handover / make handover seamless >>>>> 2. Switch to dedicated multicast links in a vertical handover >>>>> (e.g., >>>>> select a cheap/high quality broadcast link ...) >>>>> >>>>> Cheers, >>>>> >>>>> Thomas >>>>> -- >>>>> >>>>> Prof. Dr. Thomas C. Schmidt >>>>> =B0 Hamburg University of Applied Sciences Berliner >>>>> Tor 7 =B0 >>>>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >>>>> Germany =B0 >>>>> =B0 http://www.haw-hamburg.de/inet Fon: >>>>> +49-40-42875-8452 =B0 >>>>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: >>>>> +49-40-42875-8409 =B0 >>>>> _______________________________________________ >>>>> multimob mailing list >>>>> multimob@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >>> >> > -- Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner Tor 7= =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany= =B0 =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452= =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409= =B0 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Thu Jul 28 19:54:55 2011 Return-Path: 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 A15C021F85A7 for ; Thu, 28 Jul 2011 19:54:55 -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 v3cU8EN9ktUu for ; Thu, 28 Jul 2011 19:54:55 -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 1AEA621F85A3 for ; Thu, 28 Jul 2011 19:54:54 -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 5801E2780A1; Fri, 29 Jul 2011 11:54:23 +0900 (JST) Date: Fri, 29 Jul 2011 11:54:22 +0900 (JST) Message-Id: <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E2EDDE1.3040501@informatik.haw-hamburg.de> References: <4E2DAE80.9040207@informatik.haw-hamburg.de> <20110726.181219.168602339.asaeda@sfc.wide.ad.jp> <4E2EDDE1.3040501@informatik.haw-hamburg.de> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 02:54:55 -0000 Hi Thomas, >>> Again, the proposal supports both ASM and SSM. >> >> O.k., I guess this should be clarified in the writing. Also it is >> unclear why the draft puts MLDv2 as a requirement. > > PIM-SM is a multicast routing protocol providing router-to-router > communication. > MLDv2 is a protocol providing host-to-router communication. Thomas> Sure, but PIM-SM (ASM) works fine with MLDv1. So I don't see a reason to exclude it. I said again, the proposal supports both ASM and SSM. Not only ASM, not only SSM. >>> According to the draft, MAG runs PIM-SM. So PIM will decide according >>> to its MFIB. Normally, this is derived from unicast routing - but as >>> Stig pointed out in the meeting - one can configure an MFIB >>> independent of the unicast routing. >> >> Right. PIM-SM works with MRIB, and MRIB is organized from unicast >> routing protocol or separate protocol. >> (BTW, you have been saying MFIB, but I expect MRIB is correct in your >> contexts.) >> > Thomas> pardon, this is BGP language. In PIM, (M)FIB = (M)RIB ... so > no need to distinguish. Not true. MRIB and MFIB are different in PIM-SM. But, ok, it's not important in this discussion. Thomas> As mentioned above: the problem is PMIP routing. You cannot express PMIP routing within a standard-conformal PIM MRIB. It may be possible that MAG would forward MN's packets to associated LMAs without RIB. But in the general PMIPv6 implementation, MAG has a routing table, and the routing table is maintained by IGP or statically configured. In case of IGP, LMA injects aggregated prefixes into IGP LMA and MAG speaks. This is our assumption. I will ask to vendors and operators whether my assumption is correct or not for the general PMIPv6 implementation. But imagine what happens if routing table is not installed on MAG? How direct routing can be implemented without a routing table? In PMIPv6 domain, there are many routers or nodes other than LMA and MAG, and LMA and MAG would need to communicate them not for mobile nodes in some cases. MAG should have a routing table. Thomas> There is an open request to the PIM WG chair whether he can imagine any way to introduce a PMIP-type routing table flapping into PIM-SM :-) What is "PMIP-type routing table"? I cannot imagine PIM WG needs to do something for our proposal at this moment. >>> If you just deployed a PIM >>> daemon on a MAG, PMIP would most likely remain invisible to PIM and - >>> as said earlier - PIM would plainly interact with the >>> provider-internal basic unicast routing layer. >> >> PMIPv6 itself does not need to communicate with PIM-SM, if PMIPv6 >> organizes RIB correctly. > > Thomas> The problem is: it cannot "organize RIB correctly". And > implementations most likely will not use standard-type RIBs. Why do you insist this? What is your source? I cannot find any statement about this in rfc5213. Regards, -- Hitoshi Asaeda From pierrick.seite@orange-ftgroup.com Fri Jul 29 00:51:52 2011 Return-Path: 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 1376A21F8B1B for ; Fri, 29 Jul 2011 00:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 XNL+wH76RrFv for ; Fri, 29 Jul 2011 00:51:51 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7CB21F8B19 for ; Fri, 29 Jul 2011 00:51:51 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3D07FC4010; Fri, 29 Jul 2011 09:51:49 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C734BFC4006; Fri, 29 Jul 2011 09:51:49 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 09:51:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jul 2011 09:51:48 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] PMIPv6 extension for multicast Thread-Index: AcxNmufBtC5G7O2LQCavjq9SPKHD+gAJeRog References: <4E2DAE80.9040207@informatik.haw-hamburg.de><20110726.181219.168602339.asaeda@sfc.wide.ad.jp><4E2EDDE1.3040501@informatik.haw-hamburg.de> <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> From: To: , X-OriginalArrivalTime: 29 Jul 2011 07:51:49.0660 (UTC) FILETIME=[5F69CDC0:01CC4DC4] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:51:52 -0000 Hi, Let me react to the following: >=20 > I will ask to vendors and operators whether my assumption is correct > or not for the general PMIPv6 implementation. But imagine what happens > if routing table is not installed on MAG? How direct routing can be > implemented without a routing table? In PMIPv6 domain, there are many > routers or nodes other than LMA and MAG, and LMA and MAG would need to > communicate them not for mobile nodes in some cases. MAG should have a > routing table. >=20 In our current PMIP implementation, MAG and LMA are mobility functions supported by routers, as such, they both have routing table. Besides, quoting RFC5213: "The mobile access gateway is a function that typically runs on an access router." Moreover, when implementing localized routing, MAG MUST acts as routers. Quting draft-ietf-netext-pmip-lr): "packets are routed between the MAGs locally, without traversing the LMA." Anyway, I think that assuming MAG corresponds to realistic deployment models. Actually, PMIPv6 is mainly foreseen for 3GPP/non-3GPP mobility management (i.e. S2a/S2b interfaces in 3GPP/EPC architecture) where non-3GPP MAGs are current access routers with additional mobility capabilities. In other words, in real life, a MAG is not just a MAG, it's also an access router in charge of managing non-mobile host with standard routing mechanism. My two cents, Pierrick From schmidt@informatik.haw-hamburg.de Fri Jul 29 11:22:24 2011 Return-Path: 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 BCA7F21F8B0C for ; Fri, 29 Jul 2011 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FFQKrfM6SMWf for ; Fri, 29 Jul 2011 11:22:24 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id C471821F874B for ; Fri, 29 Jul 2011 11:22:23 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from dhcp-53c2.meeting.ietf.org ([130.129.83.194]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QmrhW-000115-FO; Fri, 29 Jul 2011 20:22:22 +0200 Message-ID: <4E32FA60.1070105@informatik.haw-hamburg.de> Date: Fri, 29 Jul 2011 14:22:24 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pierrick.seite@orange-ftgroup.com References: <4E2DAE80.9040207@informatik.haw-hamburg.de><20110726.181219.168602339.asaeda@sfc.wide.ad.jp><4E2EDDE1.3040501@informatik.haw-hamburg.de> <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:22:24 -0000 Hi Pierrick, Hitoshi, there are actually two different subjects mixed here. This confuses the points: 1) MAG is an Access*Router* - of course (I was arguing this here and in another thread). It has ordinary routing capabilities in the access network. Nobody objects this, so I fully agree with your statement, Pierrick. 2) PMIP mobility routing, however, works differently and is *not* the regular access routing function you describe. Quoting from RFC5213: "On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bi- directional tunnel established between itself and the mobile node's local mobility anchor. " This means: Depending on the identity of the MN (i.e. the source address / incoming interface), the default route at the MAG is chosen to be MN's LMA. This is *not* regular IP routing and cannot be expressed in a standard routing table (but in the PMIP binding tables). As repeated over and over again: When you deploy PIM-SM on a MAG without a dedicated MRIB, you will just use the regular IP unicast routing in the access network for JOIN/LEAVE operations and multicast will simply ignore the PMIP mobility management (as well as the M-tunnels). In the converse, you cannot define a persistent MRIB for PIM that reflects PMIP mobility management, as PMIP unicast routes depend on the source address of the MN (and in addition changes with handovers). That's all I'm trying to clarify since Sunday :-( Thomas On 29.07.2011 03:51, pierrick.seite@orange-ftgroup.com wrote: > Let me react to the following: > >> >> I will ask to vendors and operators whether my assumption is correct >> or not for the general PMIPv6 implementation. But imagine what happens >> if routing table is not installed on MAG? How direct routing can be >> implemented without a routing table? In PMIPv6 domain, there are many >> routers or nodes other than LMA and MAG, and LMA and MAG would need to >> communicate them not for mobile nodes in some cases. MAG should have a >> routing table. >> > > In our current PMIP implementation, MAG and LMA are mobility functions > supported by routers, as such, they both have routing table. Besides, > quoting RFC5213: > > > "The mobile access gateway is a function that typically runs on an > access router." > > Moreover, when implementing localized routing, MAG MUST acts as routers. > Quting draft-ietf-netext-pmip-lr): > > "packets are routed between the MAGs locally, without traversing the > LMA." > > Anyway, I think that assuming MAG corresponds to realistic deployment > models. Actually, PMIPv6 is mainly foreseen for 3GPP/non-3GPP mobility > management (i.e. S2a/S2b interfaces in 3GPP/EPC architecture) where > non-3GPP MAGs are current access routers with additional mobility > capabilities. In other words, in real life, a MAG is not just a MAG, > it's also an access router in charge of managing non-mobile host with > standard routing mechanism. > > My two cents, > Pierrick -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Fri Jul 29 11:40:51 2011 Return-Path: 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 839F621F8757 for ; Fri, 29 Jul 2011 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599] 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 tdXRK5vlzs0s for ; Fri, 29 Jul 2011 11:40:50 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id BCDDC21F86DC for ; Fri, 29 Jul 2011 11:40:50 -0700 (PDT) Received: from [98.139.91.70] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 18:40:47 -0000 Received: from [98.139.91.23] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 18:40:47 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 18:40:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 109047.93572.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 87645 invoked by uid 60001); 29 Jul 2011 18:40:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311964846; bh=o2RYDClutoZf6+Ski0DsaPAAovmdGFtxkgBDpOzJhuM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bEStz+Jp66ZUORfcKGEXLjmPftAOci7TdJ+Ff0tuEwcrYyVRv4zpHiqqhbxGNH9LMPwBPFNDbqqFPQndAm4hz7S2Y+Pyek/LVBkdG18YHpB2bz6x5ccAWExTHn2S4NPYaLQME3a1rbPAfQ2LZA4OnBMmzH9AT3gNStRQfGihoCU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FoRBlg/VHUwfODt/IMB4cH1/ySmCtxHqPXp4GjyYD/I5XcPeH0khTJ4ClTuENnoY5IxhY/zOVoZoRggImbm8muiDxQ5V5KHuxnOrk4Rv4vdSrnyHWJsP7ckwqw2b6Fd7RMeHtpDIo97T2Gp8cxVa+JbQ/nnSy6Vyt1+CZM+iqyM=; X-YMail-OSG: NnElDSoVM1nxhV3jNB4TAqMS6BKuN4YqWPKEz8RCFTD9U95 E7JPgsexVgcW_0wRHQljvFopVFMqHez3KVEwTHG_GAfos1wCYh0H90wHeU0P IYqKnyt4SrZGXMYT_NhKsKx1kVktSqiko3VFeizu4IqwpQiWZ_mxvMXBd6Rg TbsTETPzc9LAivG_ijXtlmaOFza2bPKI7CmiKH3VMiQ..50yNk9KA3PieIF0 zNWlLvJ0I_2F4hUSKX.L36b7QgoS.Ri0.T7N51bzviMhB1AsZht7xlFXQDnm McSlxNeTKkjDaPWpeTp7291BbN_oohC3q0HqRhYSPUnUDRo2ZfOXCzol90U. jwQbr4eB8EvLEEC3xmDF3YO0fDPpl5amkBRhYkOP57VqgMk1djQZuGPW8FgH Ci1If2YnEYNYeh8dW1SHw.Lxu69mFgnmllyHQHC8n1pzOJt9kFI3OabZK8Zc fKcOw_QOYQZjbUtmk8CDq0kOtaOqx Received: from [130.129.87.243] by web111404.mail.gq1.yahoo.com via HTTP; Fri, 29 Jul 2011 11:40:46 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <4E2DAE80.9040207@informatik.haw-hamburg.de><20110726.181219.168602339.asaeda@sfc.wide.ad.jp><4E2EDDE1.3040501@informatik.haw-hamburg.de> <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> <4E32FA60.1070105@informatik.haw-hamburg.de> Message-ID: <1311964846.87587.YahooMailRC@web111404.mail.gq1.yahoo.com> Date: Fri, 29 Jul 2011 11:40:46 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , pierrick.seite@orange-ftgroup.com In-Reply-To: <4E32FA60.1070105@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:40:51 -0000 Hi Thomas,=0A In RFC 6224 Section 4.2, you describe that a proxy instance = is selected: =0A=0AThe MAG decides on the mapping of downstream links to= a proxy instance (and =0Ahence an upstream link to an LMA) based on the= regular Binding Update List as =0Amaintained by PMIPv6 standard operati= ons why do you think that something similar =0Acan not be achieved with PIM= -SM?=0A=0ARegards,=0A=0ABehcet=0A=0A> Hi Pierrick, Hitoshi,=0A> =0A> there = are actually two different subjects mixed here. This confuses the =0A>poin= ts:=0A> =0A> 1) MAG is an Access*Router* - of course (I was arguing this = here and in =0A>another thread). It has ordinary routing capabilities in t= he access network. =0A>Nobody objects this, so I fully agree with your sta= tement, Pierrick.=0A> =0A> 2) PMIP mobility routing, however, works diffe= rently and is *not* the regular =0A>access routing function you describe. = Quoting from RFC5213:=0A> "On receiving a packet from a mobile node c= onnected to its access=0A> link, to a destination that is not direct= ly connected, the packet=0A> MUST be forwarded to the local mobility= anchor through the bi-=0A> directional tunnel established between i= tself and the mobile=0A> node's local mobility anchor. "=0A> =0A> Th= is means: Depending on the identity of the MN (i.e. the source address / = =0A>incoming interface), the default route at the MAG is chosen to be MN's= LMA. =0A>This is *not* regular IP routing and cannot be expressed in a st= andard routing =0A>table (but in the PMIP binding tables).=0A> =0A> As repe= ated over and over again: When you deploy PIM-SM on a MAG without a =0A>de= dicated MRIB, you will just use the regular IP unicast routing in the acce= ss =0A>network for JOIN/LEAVE operations and multicast will simply ignore = the PMIP =0A>mobility management (as well as the M-tunnels).=0A> =0A> In t= he converse, you cannot define a persistent MRIB for PIM that reflects =0A= >PMIP mobility management, as PMIP unicast routes depend on the source add= ress =0A>of the MN (and in addition changes with handovers).=0A> =0A> That= 's all I'm trying to clarify since Sunday :-(=0A> =0A> Thomas=0A> =0A> On = 29.07.2011 03:51, pierrick.seite@orange-ftgroup.com wrote:=0A> =0A> > Let m= e react to the following:=0A> > =0A> >> =0A> >> I will ask to vendors and o= perators whether my assumption is correct=0A> >> or not for the general PM= IPv6 implementation. But imagine what happens=0A> >> if routing table is n= ot installed on MAG? How direct routing can be=0A> >> implemented without = a routing table? In PMIPv6 domain, there are many=0A> >> routers or nodes = other than LMA and MAG, and LMA and MAG would need to=0A> >> communicate t= hem not for mobile nodes in some cases. MAG should have a=0A> >> routing t= able.=0A> >> =0A> > =0A> > In our current PMIP implementation, MAG and LMA = are mobility functions=0A> > supported by routers, as such, they both have= routing table. Besides,=0A> > quoting RFC5213:=0A> > =0A> > =0A> > "The m= obile access gateway is a function that typically runs on an=0A> > access = router."=0A> > =0A> > Moreover, when implementing localized routing, MAG MU= ST acts as routers.=0A> > Quting draft-ietf-netext-pmip-lr):=0A> > =0A> > = "packets are routed between the MAGs locally, without traversing the=0A> >= LMA."=0A> > =0A> > Anyway, I think that assuming MAG corresponds to real= istic deployment=0A> > models. Actually, PMIPv6 is mainly foreseen for 3GP= P/non-3GPP mobility=0A> > management (i.e. S2a/S2b interfaces in 3GPP/EPC = architecture) where=0A> > non-3GPP MAGs are current access routers with ad= ditional mobility=0A> > capabilities. In other words, in real life, a MAG i= s not just a MAG,=0A> > it's also an access router in charge of managing = non-mobile host with=0A> > standard routing mechanism.=0A> > =0A> > My two = cents,=0A> > Pierrick=0A> =0A> -- =0A> Prof. Dr. Thomas C. Schmidt=0A> =B0= Hamburg University of Applied Sciences Berliner Tor 7 = =B0=0A> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg= , Germany =B0=0A> =B0 http://www.haw-hamburg.de/inet Fo= n: +49-40-42875-8452 =B0=0A> =B0 http://www.informatik.haw-hamburg.de/~sch= midt Fax: +49-40-42875-8409 =B0=0A> __________________________________= _____________=0A> multimob mailing list=0A> multimob@ietf.org=0A> https://= www.ietf.org/mailman/listinfo/multimob=0A> From schmidt@informatik.haw-hamburg.de Fri Jul 29 14:32:18 2011 Return-Path: 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 5CC06228010 for ; Fri, 29 Jul 2011 14:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nP-MtyC87zYO for ; Fri, 29 Jul 2011 14:32:11 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 830B322800F for ; Fri, 29 Jul 2011 14:32:11 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from modemcable227.81-176-173.mc.videotron.ca ([173.176.81.227] helo=[192.168.0.187]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QmufA-000Ptr-P0; Fri, 29 Jul 2011 23:32:10 +0200 Message-ID: <4E3326DC.5050406@informatik.haw-hamburg.de> Date: Fri, 29 Jul 2011 17:32:12 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <4E2DAE80.9040207@informatik.haw-hamburg.de><20110726.181219.168602339.asaeda@sfc.wide.ad.jp><4E2EDDE1.3040501@informatik.haw-hamburg.de> <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> <4E32FA60.1070105@informatik.haw-hamburg.de> <1311964846.87587.YahooMailRC@web111404.mail.gq1.yahoo.com> In-Reply-To: <1311964846.87587.YahooMailRC@web111404.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: Behcet Sarikaya , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:32:18 -0000 Hi Behcet, this is because PIM is running only in a single instance (hard to imagine how different PIM instances could coexist). While in 6224 the forwarding logic (Proxy instance) is selected according to the LMA-binding (collect all MNs that belong to one LMA), PIM just sees links/interfaces and a single routing table (MRIB). Routing rules that follow PMIP bindings would need to be expressed in this routing table ... and I cannot imagine how that should work. Maybe someone else can - but up until now nobody has revealed an approach. Best regards, Thomas On 29.07.2011 14:40, Behcet Sarikaya wrote: > Hi Thomas, > In RFC 6224 Section 4.2, you describe that a proxy instance is selected: > > The MAG decides on the mapping of downstream links to a proxy instance (and > hence an upstream link to an LMA) based on the regular Binding Update List as > maintained by PMIPv6 standard operations why do you think that something similar > can not be achieved with PIM-SM? > > Regards, > > Behcet > >> Hi Pierrick, Hitoshi, >> >> there are actually two different subjects mixed here. This confuses the >> points: >> >> 1) MAG is an Access*Router* - of course (I was arguing this here and in >> another thread). It has ordinary routing capabilities in the access network. >> Nobody objects this, so I fully agree with your statement, Pierrick. >> >> 2) PMIP mobility routing, however, works differently and is *not* the regular >> access routing function you describe. Quoting from RFC5213: >> "On receiving a packet from a mobile node connected to its access >> link, to a destination that is not directly connected, the packet >> MUST be forwarded to the local mobility anchor through the bi- >> directional tunnel established between itself and the mobile >> node's local mobility anchor. " >> >> This means: Depending on the identity of the MN (i.e. the source address / >> incoming interface), the default route at the MAG is chosen to be MN's LMA. >> This is *not* regular IP routing and cannot be expressed in a standard routing >> table (but in the PMIP binding tables). >> >> As repeated over and over again: When you deploy PIM-SM on a MAG without a >> dedicated MRIB, you will just use the regular IP unicast routing in the access >> network for JOIN/LEAVE operations and multicast will simply ignore the PMIP >> mobility management (as well as the M-tunnels). >> >> In the converse, you cannot define a persistent MRIB for PIM that reflects >> PMIP mobility management, as PMIP unicast routes depend on the source address >> of the MN (and in addition changes with handovers). >> >> That's all I'm trying to clarify since Sunday :-( >> >> Thomas >> >> On 29.07.2011 03:51, pierrick.seite@orange-ftgroup.com wrote: >> >>> Let me react to the following: >>> >>>> >>>> I will ask to vendors and operators whether my assumption is correct >>>> or not for the general PMIPv6 implementation. But imagine what happens >>>> if routing table is not installed on MAG? How direct routing can be >>>> implemented without a routing table? In PMIPv6 domain, there are many >>>> routers or nodes other than LMA and MAG, and LMA and MAG would need to >>>> communicate them not for mobile nodes in some cases. MAG should have a >>>> routing table. >>>> >>> >>> In our current PMIP implementation, MAG and LMA are mobility functions >>> supported by routers, as such, they both have routing table. Besides, >>> quoting RFC5213: >>> >>> >>> "The mobile access gateway is a function that typically runs on an >>> access router." >>> >>> Moreover, when implementing localized routing, MAG MUST acts as routers. >>> Quting draft-ietf-netext-pmip-lr): >>> >>> "packets are routed between the MAGs locally, without traversing the >>> LMA." >>> >>> Anyway, I think that assuming MAG corresponds to realistic deployment >>> models. Actually, PMIPv6 is mainly foreseen for 3GPP/non-3GPP mobility >>> management (i.e. S2a/S2b interfaces in 3GPP/EPC architecture) where >>> non-3GPP MAGs are current access routers with additional mobility >>> capabilities. In other words, in real life, a MAG is not just a MAG, >>> it's also an access router in charge of managing non-mobile host with >>> standard routing mechanism. >>> >>> My two cents, >>> Pierrick >> >> -- >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Fri Jul 29 20:10:15 2011 Return-Path: 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 5E02C21F871E for ; Fri, 29 Jul 2011 20:10: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 DwddnV3j0glA for ; Fri, 29 Jul 2011 20:10:15 -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 D33F421F8713 for ; Fri, 29 Jul 2011 20:10:13 -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 7BCBA2780A3; Sat, 30 Jul 2011 12:09:40 +0900 (JST) Date: Sat, 30 Jul 2011 12:09:39 +0900 (JST) Message-Id: <20110730.120939.110497289.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E32FA60.1070105@informatik.haw-hamburg.de> References: <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> <4E32FA60.1070105@informatik.haw-hamburg.de> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 03:10:15 -0000 Hi Thomas, > 1) MAG is an Access*Router* - of course (I was arguing this here and > in another thread). It has ordinary routing capabilities in the access > network. Nobody objects this, so I fully agree with your statement, > Pierrick. Right. This means MAG has a routing table. > 2) PMIP mobility routing, however, works differently and is *not* the > regular access routing function you describe. Quoting from RFC5213: > "On receiving a packet from a mobile node connected to its access > link, to a destination that is not directly connected, the packet > MUST be forwarded to the local mobility anchor through the bi- > directional tunnel established between itself and the mobile > node's local mobility anchor. " "Packets MUST be forwarded to the LMA through the bi-directional tunnel established between MAG and the mobile node's LMA" Yes, it's true for unicast! But this does not say anything about a situation where MAG does not have a routing table. Is this the reason that you insist MAG does not have a routing table? > This means: Depending on the identity of the MN (i.e. the source > address / incoming interface), the default route at the MAG is chosen > to be MN's LMA. This is *not* regular IP routing and cannot be > expressed in a standard routing table (but in the PMIP binding > tables). I think this interpretation is not correct. > As repeated over and over again: When you deploy PIM-SM on a MAG > without a dedicated MRIB, you will just use the regular IP unicast > routing in the access network for JOIN/LEAVE operations and multicast > will simply ignore the PMIP mobility management (as well as the > M-tunnels). I don't deny that PIM-SM needs MRIB (which would be populated from a unicast routing table) to work. I said your assumption that MAG does not have a routing table seems to be unreasonable (or maybe incorrect) for me. So I'm asking where is your source (i.e. description) of your assumption, because I cannot find such description anywhere. (IMO, above quote from rfc5213 does not say "MAG does not have a routing table in general".) > In the converse, you cannot define a persistent MRIB for PIM that > reflects PMIP mobility management, as PMIP unicast routes depend on > the source address of the MN (and in addition changes with handovers). > > That's all I'm trying to clarify since Sunday :-( Take care. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Sat Jul 30 05:02:35 2011 Return-Path: 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 9E90621F8A1A for ; Sat, 30 Jul 2011 05:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 BNF18eQNEVpy for ; Sat, 30 Jul 2011 05:02:34 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 751BC21F880C for ; Sat, 30 Jul 2011 05:02:30 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from smb-rcdg1-01.wifihubtelecom.net ([213.174.115.3] helo=[10.240.66.246]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qn8FR-000ONq-1f; Sat, 30 Jul 2011 14:02:29 +0200 Message-ID: <4E33F2D9.4040701@informatik.haw-hamburg.de> Date: Sat, 30 Jul 2011 08:02:33 -0400 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110729.115422.225666691.asaeda@sfc.wide.ad.jp> <843DA8228A1BA74CA31FB4E111A5C46201D4E610@ftrdmel0.rd.francetelecom.fr> <4E32FA60.1070105@informatik.haw-hamburg.de> <20110730.120939.110497289.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110730.120939.110497289.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 12:02:35 -0000 Hi Hitoshi, I don't think we're getting anywhere: 1.) I never claimed (nor insisted) that MAG does *not have* a routing table. (All I'm saying is: you misinterpret this routing table at the MAG) 2.) It is my impression that you are not sufficiently familiar with PMIP routing/forwarding. I suggest you discuss this with the PMIP experts (as you don't believe me anyway). Best regards, Thomas On 29.07.2011 23:09, Hitoshi Asaeda wrote: > Hi Thomas, > >> 1) MAG is an Access*Router* - of course (I was arguing this here and >> in another thread). It has ordinary routing capabilities in the access >> network. Nobody objects this, so I fully agree with your statement, >> Pierrick. > > Right. This means MAG has a routing table. > >> 2) PMIP mobility routing, however, works differently and is *not* the >> regular access routing function you describe. Quoting from RFC5213: >> "On receiving a packet from a mobile node connected to its access >> link, to a destination that is not directly connected, the packet >> MUST be forwarded to the local mobility anchor through the bi- >> directional tunnel established between itself and the mobile >> node's local mobility anchor. " > > "Packets MUST be forwarded to the LMA through the bi-directional > tunnel established between MAG and the mobile node's LMA" > > Yes, it's true for unicast! But this does not say anything about a > situation where MAG does not have a routing table. > Is this the reason that you insist MAG does not have a routing table? > >> This means: Depending on the identity of the MN (i.e. the source >> address / incoming interface), the default route at the MAG is chosen >> to be MN's LMA. This is *not* regular IP routing and cannot be >> expressed in a standard routing table (but in the PMIP binding >> tables). > > I think this interpretation is not correct. > >> As repeated over and over again: When you deploy PIM-SM on a MAG >> without a dedicated MRIB, you will just use the regular IP unicast >> routing in the access network for JOIN/LEAVE operations and multicast >> will simply ignore the PMIP mobility management (as well as the >> M-tunnels). > > I don't deny that PIM-SM needs MRIB (which would be populated from a > unicast routing table) to work. > I said your assumption that MAG does not have a routing table seems to > be unreasonable (or maybe incorrect) for me. > So I'm asking where is your source (i.e. description) of your > assumption, because I cannot find such description anywhere. > (IMO, above quote from rfc5213 does not say "MAG does not have a > routing table in general".) > >> In the converse, you cannot define a persistent MRIB for PIM that >> reflects PMIP mobility management, as PMIP unicast routes depend on >> the source address of the MN (and in addition changes with handovers). >> >> That's all I'm trying to clarify since Sunday :-( > > Take care. > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Sat Jul 30 10:02:56 2011 Return-Path: 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 CCE2121F86C4 for ; Sat, 30 Jul 2011 10:02:56 -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=[AWL=-0.000, 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 fLm9Omo02Gbf for ; Sat, 30 Jul 2011 10:02:50 -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 2DE5E21F850C for ; Sat, 30 Jul 2011 10:02:49 -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 AA23B278097; Sun, 31 Jul 2011 02:02:18 +0900 (JST) Date: Sun, 31 Jul 2011 02:02:18 +0900 (JST) Message-Id: <20110731.020218.133762683.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4E33F2D9.4040701@informatik.haw-hamburg.de> References: <4E32FA60.1070105@informatik.haw-hamburg.de> <20110730.120939.110497289.asaeda@sfc.wide.ad.jp> <4E33F2D9.4040701@informatik.haw-hamburg.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 17:02:56 -0000 Thomas, > I don't think we're getting anywhere: > = > 1.) I never claimed (nor insisted) that MAG does *not have* a routin= g > table. > (All I'm saying is: you misinterpret this routing table at the M= AG) Ok, I should not say, "not have a routing table", but should precisely say "not have a standard type RIB". Your thought is; "MAG does not have a standard type RIB". And my thought is opposite; "MAG has a standard type RIB (which could be used by PIM-SM)". > 2.) It is my impression that you are not sufficiently familiar with > PMIP routing/forwarding. I suggest you discuss this with the PMIP > experts (as you don't believe me anyway). Be calm... If you were the expert, you could explain precisely why PIM routing protocol cannot work on MAG. We can ask to netext ML, but at first I want to know why you insist MAG does not have a standard type RIB and what is your source about your thought. If someone explains Thomas's claim about no standard RIB on MAG, or if someone tells us what is the correct answer, I'd appreciate your help. Thank you for all. Regards, -- Hitoshi Asaeda > On 29.07.2011 23:09, Hitoshi Asaeda wrote: >> Hi Thomas, >> >>> 1) MAG is an Access*Router* - of course (I was arguing this here = and >>> in another thread). It has ordinary routing capabilities in the a= ccess >>> network. Nobody objects this, so I fully agree with your statemen= t, >>> Pierrick. >> >> Right. This means MAG has a routing table. >> >>> 2) PMIP mobility routing, however, works differently and is *not*= the >>> regular access routing function you describe. Quoting from RFC521= 3: >>> "On receiving a packet from a mobile node connected to its ac= cess >>> link, to a destination that is not directly connected, the p= acket >>> MUST be forwarded to the local mobility anchor through the b= i- >>> directional tunnel established between itself and the mobile= >>> node's local mobility anchor. " >> >> "Packets MUST be forwarded to the LMA through the bi-directional >> tunnel established between MAG and the mobile node's LMA" >> >> Yes, it's true for unicast! But this does not say anything about a >> situation where MAG does not have a routing table. >> Is this the reason that you insist MAG does not have a routing table= ? >> >>> This means: Depending on the identity of the MN (i.e. the source >>> address / incoming interface), the default route at the MAG is chos= en >>> to be MN's LMA. This is *not* regular IP routing and cannot be >>> expressed in a standard routing table (but in the PMIP binding >>> tables). >> >> I think this interpretation is not correct. >> >>> As repeated over and over again: When you deploy PIM-SM on a MAG >>> without a dedicated MRIB, you will just use the regular IP unicast >>> routing in the access network for JOIN/LEAVE operations and multica= st >>> will simply ignore the PMIP mobility management (as well as the >>> M-tunnels). >> >> I don't deny that PIM-SM needs MRIB (which would be populated from a= >> unicast routing table) to work. >> I said your assumption that MAG does not have a routing table seems = to >> be unreasonable (or maybe incorrect) for me. >> So I'm asking where is your source (i.e. description) of your >> assumption, because I cannot find such description anywhere. >> (IMO, above quote from rfc5213 does not say "MAG does not have a >> routing table in general".) >> >>> In the converse, you cannot define a persistent MRIB for PIM that >>> reflects PMIP mobility management, as PMIP unicast routes depend on= >>> the source address of the MN (and in addition changes with handover= s). >>> >>> That's all I'm trying to clarify since Sunday :-( >> >> Take care. >> Regards, >> -- >> Hitoshi Asaeda >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > = > -- = > = > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germ= any > =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8= 409 > =B0 From sgundave@cisco.com Sat Jul 30 18:10:34 2011 Return-Path: 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 B0A8821F85B2 for ; Sat, 30 Jul 2011 18:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599] 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 0IGGqalYYl38 for ; Sat, 30 Jul 2011 18:10:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1A21F85B8 for ; Sat, 30 Jul 2011 18:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=7353; q=dns/txt; s=iport; t=1312074635; x=1313284235; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=z3JWMtOOAFUJbCU/UH3Fre2eQQMmhXLmWnVxbcByXlw=; b=C1XAVto8+iFHlascBcwY2x1mc8J/1N1tV7S7XtrG1S70lTGW2lCyLc+b /5aSYSofvajKOjN0lMBIa/4CojCBu+KyTwF347KpqNuyLzPrF7rkC0+qi 5USyOo58pHNco2dK5ZAqJjgfXBjDKkHwkldQu6nFUkUhpijoqHVaY1msg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANKqNE6rRDoG/2dsb2JhbAA4CRanTneBQAEBAQECAQEBAQ8BKQEuAwsFDQEIGFUwAQEEAQ0FIodKBKFLAZ01gyWDHQSHKy+LIYUQhFyHGA X-IronPort-AV: E=Sophos;i="4.67,293,1309737600"; d="scan'208";a="8127584" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2011 01:10:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6V1AYM8011890; Sun, 31 Jul 2011 01:10:34 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 18:10:34 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Sun, 31 Jul 2011 01:10:33 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 30 Jul 2011 18:10:29 -0700 From: Sri Gundavelli To: Hitoshi Asaeda , Message-ID: Thread-Topic: [multimob] PMIPv6 extension for multicast Thread-Index: AcxPHqMM4wBoffwMl0aydaEM0ICMBg== In-Reply-To: <20110731.020218.133762683.asaeda@sfc.wide.ad.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 31 Jul 2011 01:10:34.0600 (UTC) FILETIME=[A662AE80:01CC4F1E] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 01:10:34 -0000 Guys: My input on this thread. Not to take any sides in this heated discussion, but what I believe we covered in the base specs. 1. LMA is a IP layer-3 router and so is the home agent as specified in RFC-3775. LMA is a feature extension to MIPv6 home agent. See Section 5.0 i= n RFC-5213. Also, the section 7.1 of RFC-3775, regarding Router Advertisement messages from the home agent, and also DHAAD related considerations. "The local mobility anchor MUST support the home agent function as defined in [RFC3775] and the extensions defined in this specification. A home agent with these modifications and enhanced capabilities for supporting the Proxy Mobile IPv6 protocol is referred to as a local mobility anchor." 2. MAG is a IP layer-3 router. Refer to 6.9.3 of RFC-5213. =20 "In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- router for the mobile node on the access link." 3. MAG is hosting MN's HNP on the access link. It injects a connected rout= e into the routing table. However, this route is not redistributed beyond the MAG. When the MAG receives a packet from the tunnel, after decap, the packe= t is forwarded on the MN-AR link. It needs to check the route table, however, implementations may do it other ways too without using routing tables, but intercepting every packet and checking the BUL table. But, for all practica= l purposes, MAG has a standard IP unicast RIB. 4. LMA is hosting the mobile node's home network prefixes. It is the anchor point for mobile node's sessions; it is the entry point for the mobile node's data traffic. LMA injects an aggregated routing prefix into IGP, so = a CN's IP packets to MN always reach the LMA. The injected aggregated routing prefix is redistributed into IGP. LMA has a standard IP unicast RIB and that's=20 5. LMA function is hosted on LTE PDN gateway. It is a layer-3 IP router, an= d all known commercial implementation including cisco's mobile gateways confirm to this. MAG is a hosted on a access edge gateway such as WLAN edge router, WiMAX ASN Gateway, 3GPP2 HSS Gateway, they all are standard IP routers, with standard IP RIB. 6. I will not talk on multicast RIB, I know, you guys will argue that the base specs did not cover this topic sufficiently and which is true. But, I will say, LMA/MAG are standard IP routers, and there is no reason to believ= e they cannot support "standard" multicast RIB/functions, if not PMIP related multicast extensions. All most all the specs implicitly assume this fact. Sri On 7/30/11 10:02 AM, "Hitoshi Asaeda" wrote: > Thomas, >=20 >> I don't think we're getting anywhere: >>=20 >> 1.) I never claimed (nor insisted) that MAG does *not have* a routing >> table. >> (All I'm saying is: you misinterpret this routing table at the MAG) >=20 > Ok, I should not say, "not have a routing table", but should precisely > say "not have a standard type RIB". >=20 > Your thought is; "MAG does not have a standard type RIB". > And my thought is opposite; "MAG has a standard type RIB (which could > be used by PIM-SM)". >=20 >> 2.) It is my impression that you are not sufficiently familiar with >> PMIP routing/forwarding. I suggest you discuss this with the PMIP >> experts (as you don't believe me anyway). >=20 > Be calm... >=20 > If you were the expert, you could explain precisely why PIM routing > protocol cannot work on MAG. >=20 > We can ask to netext ML, but at first I want to know why you insist > MAG does not have a standard type RIB and what is your source about > your thought. > If someone explains Thomas's claim about no standard RIB on MAG, or if > someone tells us what is the correct answer, I'd appreciate your help. >=20 > Thank you for all. > Regards, > -- > Hitoshi Asaeda >=20 >=20 >> On 29.07.2011 23:09, Hitoshi Asaeda wrote: >>> Hi Thomas, >>>=20 >>>> 1) MAG is an Access*Router* - of course (I was arguing this here and >>>> in another thread). It has ordinary routing capabilities in the acce= ss >>>> network. Nobody objects this, so I fully agree with your statement, >>>> Pierrick. >>>=20 >>> Right. This means MAG has a routing table. >>>=20 >>>> 2) PMIP mobility routing, however, works differently and is *not* th= e >>>> regular access routing function you describe. Quoting from RFC5213: >>>> "On receiving a packet from a mobile node connected to its acces= s >>>> link, to a destination that is not directly connected, the pack= et >>>> MUST be forwarded to the local mobility anchor through the bi- >>>> directional tunnel established between itself and the mobile >>>> node's local mobility anchor. " >>>=20 >>> "Packets MUST be forwarded to the LMA through the bi-directional >>> tunnel established between MAG and the mobile node's LMA" >>>=20 >>> Yes, it's true for unicast! But this does not say anything about a >>> situation where MAG does not have a routing table. >>> Is this the reason that you insist MAG does not have a routing table? >>>=20 >>>> This means: Depending on the identity of the MN (i.e. the source >>>> address / incoming interface), the default route at the MAG is chosen >>>> to be MN's LMA. This is *not* regular IP routing and cannot be >>>> expressed in a standard routing table (but in the PMIP binding >>>> tables). >>>=20 >>> I think this interpretation is not correct. >>>=20 >>>> As repeated over and over again: When you deploy PIM-SM on a MAG >>>> without a dedicated MRIB, you will just use the regular IP unicast >>>> routing in the access network for JOIN/LEAVE operations and multicast >>>> will simply ignore the PMIP mobility management (as well as the >>>> M-tunnels). >>>=20 >>> I don't deny that PIM-SM needs MRIB (which would be populated from a >>> unicast routing table) to work. >>> I said your assumption that MAG does not have a routing table seems to >>> be unreasonable (or maybe incorrect) for me. >>> So I'm asking where is your source (i.e. description) of your >>> assumption, because I cannot find such description anywhere. >>> (IMO, above quote from rfc5213 does not say "MAG does not have a >>> routing table in general".) >>>=20 >>>> In the converse, you cannot define a persistent MRIB for PIM that >>>> reflects PMIP mobility management, as PMIP unicast routes depend on >>>> the source address of the MN (and in addition changes with handovers). >>>>=20 >>>> That's all I'm trying to clarify since Sunday :-( >>>=20 >>> Take care. >>> Regards, >>> -- >>> Hitoshi Asaeda >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>=20 >> --=20 >>=20 >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany >> =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 >> =B0 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From sgundave@cisco.com Sat Jul 30 20:03:12 2011 Return-Path: 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 3A7F211E8078 for ; Sat, 30 Jul 2011 20:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599] 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 z7nWzPZou3B1 for ; Sat, 30 Jul 2011 20:03:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E0D5811E8074 for ; Sat, 30 Jul 2011 20:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=8738; q=dns/txt; s=iport; t=1312081393; x=1313290993; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+Agdboz95u6nAClMbZieUNq4ajkwg2coETJ1nTZF+YA=; b=BfglvllbZ5DqxgKP0+LOP5cNhG89LXc3sCExBQuLvXDW2w7Zf/825tH0 ggNUpNt4JetYSwW9k+4pqfpxg5v1XLqC5nOxuNa9pxVL2peGBO2KNa+eQ YKY9YBWCY1dZxwuCGsIaDCQz23YKasx/FpqP/c/08v6yCdQolpqAvgDwF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALnFNE6rRDoJ/2dsb2JhbAA3CRanTneBQAEBAQECAQEBAQ8BKQEuAwsFDQEIGFUwAQEEAQ0FIodKBKF8AZ0ugyWDHQSHKy+LIYUQhFyHGA X-IronPort-AV: E=Sophos;i="4.67,294,1309737600"; d="scan'208";a="8143352" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2011 03:02:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6V32xn1016525; Sun, 31 Jul 2011 03:02:59 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 20:02:58 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Sun, 31 Jul 2011 03:02:58 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Sat, 30 Jul 2011 20:02:54 -0700 From: Sri Gundavelli To: Hitoshi Asaeda , Message-ID: Thread-Topic: [multimob] PMIPv6 extension for multicast Thread-Index: AcxPHqMM4wBoffwMl0aydaEM0ICMBgAD7RVM In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 31 Jul 2011 03:02:58.0896 (UTC) FILETIME=[5A4C9500:01CC4F2E] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 03:03:12 -0000 I missed one other aspect on MAG handles the uplink packets. - Any IP packet from the mobile node using the source address (IPv4 HoA, or an address from any of the prefix IPv6 HNP), the MAG forwards the packets through the MAG-LMA tunnel. This is PBR (Policy Based Routing). A next hop determination based on a source L2/L3, dest L2/L3, DSCP or other parameters in the packet. Is this a standard RIB behavior ? May not be per the legacy assumption we have about RIB or on how routing works. But, at the same time= , this decision logic can be very well be present in a RIB. At the end of the day these can be elements in the Routing Information Base. I do not believe we have a IETF RFC definition on the exact RIB structure, but I believe thi= s is just a variant of advanced IP forwarding behavior. Sri On 7/30/11 6:10 PM, "Sri Gundavelli" wrote: > Guys: >=20 > My input on this thread. Not to take any sides in this heated discussion, > but what I believe we covered in the base specs. >=20 >=20 > 1. LMA is a IP layer-3 router and so is the home agent as specified in > RFC-3775. LMA is a feature extension to MIPv6 home agent. See Section 5.0= in > RFC-5213. Also, the section 7.1 of RFC-3775, regarding Router Advertiseme= nt > messages from the home agent, and also DHAAD related considerations. >=20 > "The local mobility anchor MUST support the home agent function as > defined in [RFC3775] and the extensions defined in this > specification. A home agent with these modifications and enhanced > capabilities for supporting the Proxy Mobile IPv6 protocol is > referred to as a local mobility anchor." >=20 >=20 > 2. MAG is a IP layer-3 router. Refer to 6.9.3 of RFC-5213. > =20 > "In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- > router for the mobile node on the access link." >=20 > 3. MAG is hosting MN's HNP on the access link. It injects a connected ro= ute > into the routing table. However, this route is not redistributed beyond t= he > MAG. When the MAG receives a packet from the tunnel, after decap, the pac= ket > is forwarded on the MN-AR link. It needs to check the route table, howeve= r, > implementations may do it other ways too without using routing tables, bu= t > intercepting every packet and checking the BUL table. But, for all practi= cal > purposes, MAG has a standard IP unicast RIB. >=20 > 4. LMA is hosting the mobile node's home network prefixes. It is the anch= or > point for mobile node's sessions; it is the entry point for the mobile > node's data traffic. LMA injects an aggregated routing prefix into IGP, s= o a > CN's IP packets to MN always reach the LMA. The injected aggregated routi= ng > prefix is redistributed into IGP. LMA has a standard IP unicast RIB and > that's=20 >=20 > 5. LMA function is hosted on LTE PDN gateway. It is a layer-3 IP router, = and > all known commercial implementation including cisco's mobile gateways > confirm to this. MAG is a hosted on a access edge gateway such as WLAN ed= ge > router, WiMAX ASN Gateway, 3GPP2 HSS Gateway, they all are standard IP > routers, with standard IP RIB. >=20 > 6. I will not talk on multicast RIB, I know, you guys will argue that the > base specs did not cover this topic sufficiently and which is true. But, = I > will say, LMA/MAG are standard IP routers, and there is no reason to beli= eve > they cannot support "standard" multicast RIB/functions, if not PMIP relat= ed > multicast extensions. All most all the specs implicitly assume this fact. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 7/30/11 10:02 AM, "Hitoshi Asaeda" wrote: >=20 >> Thomas, >>=20 >>> I don't think we're getting anywhere: >>>=20 >>> 1.) I never claimed (nor insisted) that MAG does *not have* a routing >>> table. >>> (All I'm saying is: you misinterpret this routing table at the MAG= ) >>=20 >> Ok, I should not say, "not have a routing table", but should precisely >> say "not have a standard type RIB". >>=20 >> Your thought is; "MAG does not have a standard type RIB". >> And my thought is opposite; "MAG has a standard type RIB (which could >> be used by PIM-SM)". >>=20 >>> 2.) It is my impression that you are not sufficiently familiar with >>> PMIP routing/forwarding. I suggest you discuss this with the PMIP >>> experts (as you don't believe me anyway). >>=20 >> Be calm... >>=20 >> If you were the expert, you could explain precisely why PIM routing >> protocol cannot work on MAG. >>=20 >> We can ask to netext ML, but at first I want to know why you insist >> MAG does not have a standard type RIB and what is your source about >> your thought. >> If someone explains Thomas's claim about no standard RIB on MAG, or if >> someone tells us what is the correct answer, I'd appreciate your help. >>=20 >> Thank you for all. >> Regards, >> -- >> Hitoshi Asaeda >>=20 >>=20 >>> On 29.07.2011 23:09, Hitoshi Asaeda wrote: >>>> Hi Thomas, >>>>=20 >>>>> 1) MAG is an Access*Router* - of course (I was arguing this here an= d >>>>> in another thread). It has ordinary routing capabilities in the acc= ess >>>>> network. Nobody objects this, so I fully agree with your statement, >>>>> Pierrick. >>>>=20 >>>> Right. This means MAG has a routing table. >>>>=20 >>>>> 2) PMIP mobility routing, however, works differently and is *not* t= he >>>>> regular access routing function you describe. Quoting from RFC5213: >>>>> "On receiving a packet from a mobile node connected to its acce= ss >>>>> link, to a destination that is not directly connected, the pac= ket >>>>> MUST be forwarded to the local mobility anchor through the bi- >>>>> directional tunnel established between itself and the mobile >>>>> node's local mobility anchor. " >>>>=20 >>>> "Packets MUST be forwarded to the LMA through the bi-directional >>>> tunnel established between MAG and the mobile node's LMA" >>>>=20 >>>> Yes, it's true for unicast! But this does not say anything about a >>>> situation where MAG does not have a routing table. >>>> Is this the reason that you insist MAG does not have a routing table? >>>>=20 >>>>> This means: Depending on the identity of the MN (i.e. the source >>>>> address / incoming interface), the default route at the MAG is chosen >>>>> to be MN's LMA. This is *not* regular IP routing and cannot be >>>>> expressed in a standard routing table (but in the PMIP binding >>>>> tables). >>>>=20 >>>> I think this interpretation is not correct. >>>>=20 >>>>> As repeated over and over again: When you deploy PIM-SM on a MAG >>>>> without a dedicated MRIB, you will just use the regular IP unicast >>>>> routing in the access network for JOIN/LEAVE operations and multicast >>>>> will simply ignore the PMIP mobility management (as well as the >>>>> M-tunnels). >>>>=20 >>>> I don't deny that PIM-SM needs MRIB (which would be populated from a >>>> unicast routing table) to work. >>>> I said your assumption that MAG does not have a routing table seems to >>>> be unreasonable (or maybe incorrect) for me. >>>> So I'm asking where is your source (i.e. description) of your >>>> assumption, because I cannot find such description anywhere. >>>> (IMO, above quote from rfc5213 does not say "MAG does not have a >>>> routing table in general".) >>>>=20 >>>>> In the converse, you cannot define a persistent MRIB for PIM that >>>>> reflects PMIP mobility management, as PMIP unicast routes depend on >>>>> the source address of the MN (and in addition changes with handovers)= . >>>>>=20 >>>>> That's all I'm trying to clarify since Sunday :-( >>>>=20 >>>> Take care. >>>> Regards, >>>> -- >>>> Hitoshi Asaeda >>>> _______________________________________________ >>>> multimob mailing list >>>> multimob@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multimob >>>=20 >>> --=20 >>>=20 >>> Prof. Dr. Thomas C. Schmidt >>> =B0 Hamburg University of Applied Sciences Berliner Tor 7 =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany >>> =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 >>> =B0 >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Sat Jul 30 21:07:28 2011 Return-Path: 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 879A621F8634 for ; Sat, 30 Jul 2011 21:07:28 -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=[AWL=-0.000, 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 dOebPSmsvisk for ; Sat, 30 Jul 2011 21:07:28 -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 0AA1421F8620 for ; Sat, 30 Jul 2011 21:07:27 -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 AEFB927809B; Sun, 31 Jul 2011 13:06:57 +0900 (JST) Date: Sun, 31 Jul 2011 13:06:56 +0900 (JST) Message-Id: <20110731.130656.22129512.asaeda@sfc.wide.ad.jp> To: sgundave@cisco.com From: Hitoshi Asaeda In-Reply-To: References: <20110731.020218.133762683.asaeda@sfc.wide.ad.jp> 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, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:07:28 -0000 Hi Sri, > will say, LMA/MAG are standard IP routers, and there is no reason to believe > they cannot support "standard" multicast RIB/functions, if not PMIP related > multicast extensions. All most all the specs implicitly assume this fact. Thank you very much for your precise explanation. I continue our draft work based on the current direction. I know there are some ambiguities in our current draft, so we will revise it soon to improve the quality. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sat Jul 30 21:17:20 2011 Return-Path: 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 7CC9B21F8669 for ; Sat, 30 Jul 2011 21:17:20 -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=[AWL=-0.000, 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 SCrgu83jOJ+A for ; Sat, 30 Jul 2011 21:17:20 -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 0A62511E8074 for ; Sat, 30 Jul 2011 21:17:19 -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 13E1B27809F; Sun, 31 Jul 2011 13:16:14 +0900 (JST) Date: Sun, 31 Jul 2011 13:16:12 +0900 (JST) Message-Id: <20110731.131612.95054215.asaeda@sfc.wide.ad.jp> To: sgundave@cisco.com From: Hitoshi Asaeda In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:17:20 -0000 Sri, > - Any IP packet from the mobile node using the source address (IPv4 HoA, or > an address from any of the prefix IPv6 HNP), the MAG forwards the packets > through the MAG-LMA tunnel. This is PBR (Policy Based Routing). A next hop > determination based on a source L2/L3, dest L2/L3, DSCP or other parameters > in the packet. Is this a standard RIB behavior ? May not be per the legacy > assumption we have about RIB or on how routing works. This PBR behavior does not affect anything for receiver mobility with PIM-SM. For sender mobility with PIM-SM, this PBR assumes that multicast packets sourced by MNs go through LMA. If this is the policy in PMIPv6, then PIM-SM just follows the decision. I would say, this is the case where PBR injects policy in the standard RIB (and PIM-SM could adopt the policy in its MRIB). > But, at the same time, > this decision logic can be very well be present in a RIB. At the end of the > day these can be elements in the Routing Information Base. I do not believe > we have a IETF RFC definition on the exact RIB structure, but I believe this > is just a variant of advanced IP forwarding behavior. I agree. Regards, -- Hitoshi Asaeda From contreras.uc3m@gmail.com Sun Jul 31 05:42:17 2011 Return-Path: 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 EA05421F8747 for ; Sun, 31 Jul 2011 05:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zPGVMmGzDySy for ; Sun, 31 Jul 2011 05:42:17 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 19F4121F8753 for ; Sun, 31 Jul 2011 05:42:17 -0700 (PDT) Received: by pzk6 with SMTP id 6so9013117pzk.26 for ; Sun, 31 Jul 2011 05:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rOKex8oULgRTlqRqK5OgQjOeVDgl0rrnUVzOvyhVnfM=; b=aSDFetZILU+XSFaU4HPNxYzUE6w2HAGmqfiPfw1936cqjGJzGCnMLkNlnncbi7avUP adNV4SxraYM8ZqfIgZvv/u9TwKbNixffGW1Lc7wGmUZvlWc+Z6QmY0mbjSoosRZrz+By DdHEQLnc3i9FbDSTHNStNRxskflSLKWgvq2eM= MIME-Version: 1.0 Received: by 10.68.54.35 with SMTP id g3mr5405301pbp.459.1312116138723; Sun, 31 Jul 2011 05:42:18 -0700 (PDT) Received: by 10.68.57.70 with HTTP; Sun, 31 Jul 2011 05:42:18 -0700 (PDT) In-Reply-To: <20110731.131612.95054215.asaeda@sfc.wide.ad.jp> References: <20110731.131612.95054215.asaeda@sfc.wide.ad.jp> Date: Sun, 31 Jul 2011 14:42:18 +0200 Message-ID: From: "Luis M. Contreras" To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=bcaec53051135a4a3204a95cd8b8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 12:42:18 -0000 --bcaec53051135a4a3204a95cd8b8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I think that the Thomas concerns yet apply. The MAG maintains of course a RIB. Any device will be reachable by whatever interface except through the multicast tunnel with LMA because there is no routing information propagation through the tunnel. If the MAG sends out a PIM join message through the tunnel interface to the LMA, once the LMA forwards the multicast flow to the MAG by using the tunnel, the MAG will implement RPF checking, and as consequence, the MAG will discard the multicast traffic because the source of that multicast traffic is not reachable through the multicast tunnel. I think this is the point Thomas highlights. A way to overcome this issue is advanced in section 4 of draft-zuniga-multimob-smspmip-06, where PIM is enabled only on the MAG's tunnel interface to the MTMA (i.e., the entity anchoring the multicast tree in the PMIPv6 domain). This has to be complemented with a multicast static route pointing to the tunnel to pass the RPF checking. An scenario where PIM routing is generally enabled in the MAG will need more complicated configuration, I guess, if we want some coexistence of muticast traffic coming from the LMA and from the other MAG interfaces. Without an in depth analysis, I think that in case the PIM routing is generally enabled in the MAG, all the PIM messaging will follow other interfaces different to the tunnel interface to the LMA, because either the RP in the ASM case, or the source in the SSM case, can be reached by the MAG through other interfaces distinct to the tunnels towards the LMAs. If we force the PIM messages to go to the LMA, then the multicast forwarding will fail due to the RPF check. Best regards, Luis 2011/7/31 Hitoshi Asaeda > Sri, > > > - Any IP packet from the mobile node using the source address (IPv4 HoA, > or > > an address from any of the prefix IPv6 HNP), the MAG forwards the packets > > through the MAG-LMA tunnel. This is PBR (Policy Based Routing). A next > hop > > determination based on a source L2/L3, dest L2/L3, DSCP or other > parameters > > in the packet. Is this a standard RIB behavior ? May not be per the > legacy > > assumption we have about RIB or on how routing works. > > This PBR behavior does not affect anything for receiver mobility with > PIM-SM. > For sender mobility with PIM-SM, this PBR assumes that multicast > packets sourced by MNs go through LMA. If this is the policy in > PMIPv6, then PIM-SM just follows the decision. I would say, this is > the case where PBR injects policy in the standard RIB (and PIM-SM > could adopt the policy in its MRIB). > > > But, at the same time, > > this decision logic can be very well be present in a RIB. At the end of > the > > day these can be elements in the Routing Information Base. I do not > believe > > we have a IETF RFC definition on the exact RIB structure, but I believe > this > > is just a variant of advanced IP forwarding behavior. > > I agree. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --bcaec53051135a4a3204a95cd8b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
I think that the Thomas concerns yet apply.
=A0
The MAG maintains of course a RIB. Any device will be reachable by wha= tever interface except through the multicast tunnel with LMA because there = is no routing information=A0propagation through the tunnel.
=A0
If the MAG sends out a PIM join message through the tunnel interface t= o the LMA, once the LMA forwards the multicast flow to the MAG by using the= tunnel, the MAG will implement RPF checking, and as consequence, the MAG w= ill discard the multicast traffic=A0because the=A0source of that multicast = traffic is not reachable through the multicast tunnel.
=A0
I think this is the point Thomas highlights.
=A0
A way to overcome this issue is advanced in section 4 of draft-zuniga-= multimob-smspmip-06, where PIM is enabled only on the MAG's tunnel inte= rface to the MTMA (i.e., the entity anchoring the multicast tree in the PMI= Pv6 domain). This has to be complemented with a multicast static route poin= ting to the tunnel to pass the RPF checking.
=A0
An scenario where PIM routing is generally enabled in the MAG will nee= d more complicated configuration, I guess, if we want some coexistence of m= uticast traffic coming from the LMA and from the other MAG interfaces. With= out an in depth analysis, I think that in case the PIM routing is generally= enabled in the MAG, all the PIM messaging will follow other interfaces dif= ferent=A0to the tunnel interface to the LMA, because either the RP in the A= SM case, or the source in the SSM case, can be reached by the MAG through o= ther interfaces distinct=A0to the tunnels towards the LMAs. If we force the= PIM messages to go to the LMA, then the multicast forwarding will fail due= to the RPF check.
=A0
Best regards,
=A0
Luis
2011/7/31 Hitoshi Asaeda <<= a href=3D"mailto:asaeda@sfc.wide.ad.jp">asaeda@sfc.wide.ad.jp>
Sri,

> - Any IP packet from the mobile node using the s= ource address (IPv4 HoA, or
> an address from any of the prefix IPv6 = HNP), the MAG forwards the packets
> through the MAG-LMA tunnel. =A0T= his is PBR (Policy Based Routing). A next hop
> determination based on a source L2/L3, dest L2/L3, DSCP or other param= eters
> in the packet. Is this a standard RIB behavior ? May not be p= er the legacy
> assumption we have about RIB or on how routing works.=

This PBR behavior does not affect anything for receiver mobility = with
PIM-SM.
For sender mobility with PIM-SM, this PBR assumes that m= ulticast
packets sourced by MNs go through LMA. If this is the policy in=
PMIPv6, then PIM-SM just follows the decision. I would say, this is
the = case where PBR injects policy in the standard RIB (and PIM-SM
could adop= t the policy in its MRIB).

> But, at the same time,
> this decision log= ic can be very well be present in a RIB. At the end of the
> day thes= e can be elements in the Routing Information Base. I do not believe
>= we have a IETF RFC definition on the exact RIB structure, but I believe th= is
> is just a variant of advanced IP forwarding behavior.

I a= gree.

Regards,
--
Hitoshi Asaeda
_________________= ______________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailma= n/listinfo/multimob

--bcaec53051135a4a3204a95cd8b8-- From asaeda@sfc.wide.ad.jp Sun Jul 31 08:29:54 2011 Return-Path: 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 ED65221F86BF for ; Sun, 31 Jul 2011 08:29:54 -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 NAINkosiQ5EZ for ; Sun, 31 Jul 2011 08:29:54 -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 E2EC121F86BD for ; Sun, 31 Jul 2011 08:29:53 -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 CFF52278062; Mon, 1 Aug 2011 00:29:24 +0900 (JST) Date: Mon, 01 Aug 2011 00:29:24 +0900 (JST) Message-Id: <20110801.002924.128862720.asaeda@sfc.wide.ad.jp> To: contreras.uc3m@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20110731.131612.95054215.asaeda@sfc.wide.ad.jp> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 15:29:55 -0000 Hi Luis, > The MAG maintains of course a RIB. Any device will be reachable by whatever > interface except through the multicast tunnel with LMA because there is no > routing information propagation through the tunnel. > > If the MAG sends out a PIM join message through the tunnel interface to the > LMA, once the LMA forwards the multicast flow to the MAG by using the > tunnel, the MAG will implement RPF checking, and as consequence, the MAG > will discard the multicast traffic because the source of that multicast > traffic is not reachable through the multicast tunnel. This is a different topic from the discussion about standard RIB. Your point is that M-Tunnel is not recognized in RIB. So if MRIB just copies from RIB, then M-Tunnel will be ignored. It is true, but it is Ok. M-Tunnel will be only used for special mroutes (which are independent from unicast routes) being injected into MRIB. When operators want to configure a special mroute, which is not the same unicast route for the destination, then they may use M-Tunnel to configure the independent mroute. And the configured mroute (using M-Tunnel) will be injected into MRIB. In other words, if operators do not need to distinguish RIB and MRIB for multicast forwarding at all, they don't need to configure M-Tunnel for mroutes. PIM-SM just uses the standard RIB as its MRIB in this case. Providing functionality to distinguish RIB and MRIB is the requirement for the use of PIM-SM, I think. And M-Tunnel could be used for configuring special mroute being injected into MRIB. However, if people confuse, I will remove this optional tunnel from the revised draft. > A way to overcome this issue is advanced in section 4 of > draft-zuniga-multimob-smspmip-06, where PIM is enabled only on the MAG's > tunnel interface to the MTMA (i.e., the entity anchoring the multicast tree > in the PMIPv6 domain). This has to be complemented with a multicast static > route pointing to the tunnel to pass the RPF checking. When operators use the regular IPv6-IPv6 tunnel as the link for LMA-MAG connection in PIM-SM, PIM-SM simply can adopt the regular tunnel as the upstream link. And, even if MAG connects to multiple LMAs via multiple IPv6-IPv6 tunnels, PIM-SM selects an upstream interface for the (*,G) or (S,G) with the RFP algorithm. > An scenario where PIM routing is generally enabled in the MAG will need more > complicated configuration, I guess, To me, PIM-SM is much simpler than MLD proxy configuration. MLD proxy definitively requires to configure the upstream interface. If MAG may associate multiple LMAs, MAG must install the same number of MLD proxy instances and configure each upstream interface. If MAG needs to communicate other multicast routers, let's say, for direct route, then it also installs the other MLD proxy instance and configure the upstream interface for it independently. Well, I feel your "multicast LMA" solution is simple and good. I don't deny it. But I'd say I like PIM-SM solution more, because it is more generally appricable. And it is in fact simpler. If operators install PIM-SM on MAG, then MAG can select upstream interfaces for any (S,G) and (*,G) thanks to the RPF. > if we want some coexistence of muticast > traffic coming from the LMA and from the other MAG interfaces. Without an in > depth analysis, I think that in case the PIM routing is generally enabled in > the MAG, all the PIM messaging will follow other interfaces different to the > tunnel interface to the LMA, because either the RP in the ASM case, or the > source in the SSM case, can be reached by the MAG through other interfaces > distinct to the tunnels towards the LMAs. If we force the PIM messages to go > to the LMA, then the multicast forwarding will fail due to the RPF check. Please read above. If operators don't need to distinguish RIB and MRIB, then no need to configure special tunnel. Regards, -- Hitoshi Asaeda