Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 03 October 2013 20:52 UTC
Return-Path: <sarikaya2012@gmail.com>
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 04EEC21F9642 for <multimob@ietfa.amsl.com>; Thu, 3 Oct 2013 13:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.667
X-Spam-Level: *
X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7K3bwwhTITw for <multimob@ietfa.amsl.com>; Thu, 3 Oct 2013 13:52:14 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86B1821F8E85 for <multimob@ietf.org>; Thu, 3 Oct 2013 13:37:22 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id c11so2487420lbj.41 for <multimob@ietf.org>; Thu, 03 Oct 2013 13:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eB3gXUnyyCGQ3lUPoUGaL8refzud9jgxkQLvAwsu4JA=; b=NAzxLWrYF0JdijxkU4KJUlX6WRjBxRqCJ+vF9EQUwJt2f4Kp3vUxKmM0idv/afFa0i FMm1izIXAzQKeOuIOp8nL3baD8Yttw8ag60z65EqNDqyhvr7DLqMUDoyfauyd5usWQnJ 9Kr+SuyCRx2XvyZu5UECxSUQ8hGAId4iPL0LXUEWkX2EJRAfeU62hgwDf4FMylVMnCAF E75udFw67FMFel7WKzLx6SDQRrZLgsyFq3tvbSI4sStFRmth//oro0KAIJztX7sd/CYh 2XWNCXXCXjvHZ/O9go9T1MBhC3QfQh/Lw1Aqk/+4ABsFDNdwdAEfNHnhfK0c9UH+B0YK KHKQ==
MIME-Version: 1.0
X-Received: by 10.112.168.170 with SMTP id zx10mr8377841lbb.0.1380832641199; Thu, 03 Oct 2013 13:37:21 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Thu, 3 Oct 2013 13:37:21 -0700 (PDT)
In-Reply-To: <524B3BE3.8010502@venaas.com>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com> <5249E105.8040405@informatik.haw-hamburg.de> <524B0301.8080301@venaas.com> <CAC8QAcebJkGeL-SPqpp3eQCKbp876yWgrc0e39sZNJ3oYVQTTA@mail.gmail.com> <524B3BE3.8010502@venaas.com>
Date: Thu, 03 Oct 2013 15:37:21 -0500
Message-ID: <CAC8QAcddQVTwiC00gnG+N5voUs+uL8ixM8s1kyoD6h_3PN_v5Q@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Stig Venaas <stig@venaas.com>
Content-Type: multipart/alternative; boundary="001a11c23c8812b66204e7dc277c"
Cc: "multimob@ietf.org" <multimob@ietf.org>, "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 20:52:25 -0000
On Tue, Oct 1, 2013 at 4:17 PM, Stig Venaas <stig@venaas.com> wrote: > On 10/1/2013 11:58 AM, Behcet Sarikaya wrote: > >> You mean a certain implementation has somehow foreseen these and acting >> like this? >> > > No, it's per 4601, > > Where in this 150 page document? A lot of people say PIM-BIDIR, RFC 5015, 43 pages, is better. Regards, Behcet > Stig > > Otherwise you need to provide references. >> >> Regards, >> >> Behcet >> >> >> On Tue, Oct 1, 2013 at 12:14 PM, Stig Venaas <stig@venaas.com >> <mailto:stig@venaas.com>> wrote: >> >> Hi >> >> >> On 9/30/2013 1:37 PM, Thomas C. Schmidt wrote: >> >> Hi Stig, >> >> you're the PIM expert ... however, your statements confuse me. >> >> Event though the discussion does not matter to the source draft, >> I would >> like to clarify. Please see inline. >> >> On 30.09.2013 21:19, Stig Venaas wrote: >> >> Hi >> >> On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote: >> >> Dear Cong Liu, >> >> thanks for your feedback - please see inline. >> >> On 30.09.2013 08:47, Cong Liu wrote: >> >> Regarding this draft, I have the following comments >> for consideration. >> >> P14: "This tree can be of lesser routing efficiency >> than the PIM source >> register tunnel established in phase one, but >> provides the advantage of >> immediate data delivery to receivers that share a >> MAG with S." >> - This sentence implicitly indicates that local >> receivers sharing a MAG >> with S cannot receive immediate multicast traffic >> from the S in phase >> one. In my opinion, even in phase one, the MAG >> acting as the DR has the >> related multicast state so that immediate data >> delivery is possible. If >> so, the sentence here is not appropriate. >> >> >> This sentence actually refers to the building of an >> (S,G)-Tree at the >> end of PIM phase II. This tree follows reverse unicast >> routes and thus >> traverses the LMA-MAG tunnel - this is why it may be of >> lower efficiency >> than the forward (register) tunnel in phase I. >> >> What you are referring to is the question of >> source-local traffic >> distribution in PIM phase I. According to the way I >> understand PIM-SM, >> it does not distribute source-specific traffic locally >> in Phase I. This >> is because a local source S generates an (S,G)-State at >> the sender's >> local router (DR), but a receiver in ASM requires an >> (*,G) service. >> >> >> Traffic is distributed locally independent of the >> registration process. >> I assume you're talking about a source on one interface, and >> receivers >> on other interfaces on the same router? In that case for ASM >> (receivers >> joining a group, not specific sources), there would already be >> (*,G)-join state, and packets from the source would both be >> forwarded >> on the joined interfaces and sent as PIM registers. >> >> >> Mhmm ... this would mean that you have two feeds into the >> distribution >> tree: One rooted at the source (valid for local receivers), and >> one >> rooted at the RP - at this stage, we are still in phase I. >> >> >> If you're receiving packets from the source you're already on the >> SPT and prune the source from the shared tree. >> >> >> If (S,G) traffic were distributed locally, then the >> required (*,G)-Join >> to the RP would cause duplicate (S,G) traffic arriving >> at the >> source-local receiver. >> >> >> No, that shouldn't happen. >> >> >> How do you exclude? In phase I, all traffic is tunneled to the >> RP and >> the "path" from source to RP is not visible to the multicast >> distribution system. The DR of the receiver, which happens to be >> the DR >> of one of the sources, would just initiate an (*,G) join towards >> the RP >> ... and all traffic tunneled to the RP would be distributed down >> to the >> receivers. >> >> >> It would send a (*,G)-join with an (S,G) RPT prune. >> >> >> Thus traffic from the (local) source would reach the (local) DR >> and the >> receiver twice ???? >> >> Looking at the spec in Section 3.1 of RFC4601: >> >> "At the end of phase one, multicast traffic is flowing >> encapsulated to >> the RP, and then natively over the RP tree to the >> multicast >> receivers." >> >> >> That is sort of the general picture, but any receivers >> connected to the >> first hop router (and also later any routers on the path >> from the FHR to >> the RP) would receive packets before this. >> >> >> I guess not: If multicast packets are tunneled in source register >> packets, how can an intermediate router distribute them locally? I >> suppose you are talking about PIM phase II, aren't you? >> >> >> There are no strict phases like that. >> >> FHR would create (S,G)-state when the first packet arrives. The (S,G) >> would have outgoing interfaces inherited from the (*,G) if there are >> local receivers that joined G. In addition it sends registers. >> >> Later when the RP joins the SPT to receive packets natively (not >> registers), you would create (S,G)-state and start receiving packets >> on routers between FHR and the RP. Also these would immediately >> send packets to local receivers (and pruning the source off the RPT), >> rather than waiting to receive packets on the RPT. >> >> Stig >> >> >> Cheers, >> >> Thomas >> >> >> Some nits: >> 1) The term "MLD proxy" and "MLD Proxy" should be >> unified as MLD proxy >> or MLD Proxy >> 2) P14: This tree can be of lesser routing efficiency >> - This tree can be of less routing efficiency >> >> >> Thanks, it's fixed. >> >> Best regards, >> >> Thomas >> >> Thanks! >> >> Best Regards, >> Cong Liu >> >> >> 2013/9/30 Thomas C. Schmidt >> <schmidt@informatik.haw-__**hamburg.de<schmidt@informatik.haw-__hamburg.de> >> <mailto:schmidt@informatik.**haw-hamburg.de<schmidt@informatik.haw-hamburg.de> >> > >> <mailto:schmidt@informatik.__h**aw-hamburg.de<http://haw-hamburg.de> >> >> <mailto:schmidt@informatik.**haw-hamburg.de<schmidt@informatik.haw-hamburg.de> >> >>> >> >> Hi Dirk, >> >> thanks again for your detailed comments. Please >> see replies inline. >> >> On 26.08.2013 18 <tel:26.08.2013%2018>:29, >> Dirk.von-Hugo@telekom.de >> <mailto:Dirk.von-Hugo@telekom.**de<Dirk.von-Hugo@telekom.de> >> > >> <mailto:Dirk.von-Hugo@telekom.**__de >> >> <mailto:Dirk.von-Hugo@telekom.**de<Dirk.von-Hugo@telekom.de>>> >> wrote: >> >> As promised at IETF-87 I did a review of >> the source multicast >> mobility draft and think the document is in >> quite good shape. >> >> Being not the distinct expert in details of >> multicast protocols >> I am not sure to have understood everything >> in detail, so >> please >> correct me and forgive misunderstandings ... >> >> The three scenarios described are >> 1) the base solution with MLD proxies at >> MAGs (and optionally >> also at LMAs) (sect.3) >> 2) direct routing with or without MLD >> proxies at MAGs and with >> native Multicast support at MAG level or >> above via different >> established Multicast protocols (sect.4) >> 3) Routing optimization for direct routing >> with MLD proxies at >> MAGs (sect. 5) >> Right? >> >> >> Yes, this is it. >> >> IMHO from the abstract this is not easily >> to see. >> >> >> We have adjusted the abstract. In any case, it >> explicitly addresses >> (enumerates) the three scenarios mentioned abobe. >> >> I have some comments and suggestions to >> increase >> readability, in >> addition to some nits found, given in the >> following: >> >> Fig. 1, fig.3 to be placed on single pages >> to simplify >> readability. >> >> >> This is a fine-tuning that shall be done with >> the RFC-editor. In >> the >> process of RFC-editing, the boilerplate will >> change and so will the >> positioning of floating text and figures. >> >> Consistently use re-attach and >> re-distribute _or_ reattach and >> redistribute, respectively, throughout >> document. >> Is there any implicit meaning of Proxy with >> respect to proxy? >> Also MLD Proxy and MLD proxy are both used >> throughout the >> document ... >> >> >> Thanks ... this should be corrected, now. >> >> >> p.1 >> optimizations for synchronizing PMIPv6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies defined. >> => optimizations for synchronizing PMIPv6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies are defined. >> >> >> Thanks, corrected. >> >> p.3 >> Such approaches (partially) follow the >> business model of providing multicast >> data services in >> parallel to >> PMIPv6 unicast routing. >> ==> shouldn't one or more references be >> added here such as to >> [I-D.ietf-multimob-pmipv6-____**ropt], >> >> draft-ietf-multimob-fmipv6-___**_pfmipv6-multicast, >> >> draft-ietf-multimob-handover-_**___optimization ...? >> >> >> >> Yes, good point: It's added now. >> >> needs of receptive use cases >> => needs of applications for mobile >> multicast reception of >> content from few and mainly fixed content >> sources >> >> p.5 >> >> A multicast unaware MAG would simply >> discard these packets in >> the absence of a multicast routing >> information base >> (MRIB). >> ==> shouldn't one add more information >> about MRIBs introduced >> here for non-multicast aware readers such >> as: Such tables >> similar to MFIBs mentioned in RFC 6224 >> ensure that the >> router is >> able to correctly route/forward packets >> with multicast >> addresses >> as destinations . >> >> >> O.K. - we've added a brief explanatory insert >> ... even though I >> believe that a mulitcast unaware reader will >> not succeed in taking >> profit from this document ;) >> >> >> In case of a handover, the MN (unaware of >> IP mobility) >> => In case of a handover, the MN (being >> unaware of IP mobility) >> >> >> O.K., fixed. >> >> as soon as network connectivity is >> reconfigured >> => as soon as network connectivity is >> re-established >> >> O.K., fixed. >> >> >> p.7 >> multicast data is => multicast data are >> >> >> Mhmm, my dictionary says "data is" ... "data" >> is a singular term >> that subsumes (uncountable) plural ... >> >> >> p.8 >> In addition, an LMA serving as PIM >> Designated Router is >> connected >> => In addition, an LMA serving as PIM >> Designated Router >> (DR) is >> connected >> >> >> O.K., fixed. >> >> incoming interface validation is only >> performed by RPF >> checks >> => incoming interface validation is only >> performed by RPF >> (Reverse Path Forwarding) >> checks >> >> >> O.K., fixed. >> >> Notably, running BIDIR PIM [RFC5015] on >> LMAs remains robust >> with >> respect to source location and does >> not require special >> configurations or state management for >> sources. >> ==> Wouldn't it make sense to add a reason >> for this, e.g. >> ... since BIDIR PIM automatically builds >> trees to allow >> multicast data to be natively forwarded >> from sources to >> receivers without requiring source-specific >> information ... >> On the other hand a reference to sect. 4.4 >> might be perhaps >> misleading here since this section is not >> on direct multicast >> routing?! >> >> >> This is about the nature of BIDIR-PIM. The >> reason for this property >> is the bidirectional use of a static (= >> source-independent) >> spanning >> tree ... but explaining the ideas behind >> BIDIR-PIM may really go >> too >> far here ... if readers haven't heard about >> BIDIR-PIM, the should >> look up the reference. >> >> >> an IGMP proxy >> function needs to be deployed at MAGs >> in exactly the same >> way as for >> IPv6. >> => an IGMP proxy >> function needs to be deployed at MAGs >> in exactly the same >> way as is done for an MLD proxy for >> IPv6. >> >> p.9 >> For a dual-stack IPv4/IPv6 access network, >> the MAG proxy >> instances >> => For a dual-stack IPv4/IPv6 access >> network, the MAG proxy >> instances (i.e. IPMP/MLD proxy functions) >> >> In the following, efficiency-related issues >> remain. >> => In the following, efficiency-related >> issues which remain >> unsolved within the above defined base >> PMIPv6 multicast source >> support are described. >> >> >> Here, we would prefer the shorter forms. >> >> p.11 >> upstream will lead traffic into the >> multicast infrastructure >> => upstream will transfer traffic into the >> multicast >> infrastructure >> >> >> o.k. >> >> p.12 >> configurations have completed => >> configurations have been >> completed >> >> >> o.k. >> >> traffic from the mobile source continues to >> be transmitted via >> the >> same next-hop router using the same >> source address >> => traffic from the mobile source >> continues to be transmitted >> via the >> same next-hop multicast router using >> the same source >> address >> >> >> o.k. >> >> by aggregating proxies on a lower layer. >> ==> please clarify: what layer exactly is >> proposed? PIM DR at >> MAGs? >> >> >> A lower layer is meant in the (OSI) layered >> model: Layer 2 or >> below. >> >> in the access network for providing >> multicast services in >> parallel to >> unicast routes. >> => in the access network for providing >> multicast services in >> parallel to >> unicast routes ( see Fig. 3(b)). >> >> >> O.K. >> >> p.13 >> The following information is needed for >> all phases of PIM. >> => The following information is needed for >> all three phases of >> PIM as outlined in [RFC4601]. >> >> >> O.K. >> >> P.14 >> configured to not initiated (S,G) shortest >> path tress for >> mobile >> => configured to not initiated (S,G) >> shortest path trees for >> mobile >> >> >> Thanks, o.k. >> >> mobile source. This tree can be of lesser >> routing efficiency >> than >> => mobile source. This tree can be of >> lower routing >> efficiency than >> >> >> o.k. >> >> In >> response, the PIM RP will recognize >> the known source at a >> new >> (tunnel) interface immediately >> responds with a register >> stop. >> => In >> response, the PIM RP will recognize >> the known source at a >> new >> (tunnel) interface and thus (?) >> immediately respond with a >> register stop. >> >> >> O.k., fixed. >> >> As the >> RP had joined the shortest path tree >> to receive from the >> source via >> the LMA, >> =>As the >> RP has joined the shortest path tree >> to receive data from >> the source via >> the LMA, >> >> >> Meanwhile replaced. >> >> the LMA, it will see an RPF change when >> data arrives at a new >> => the LMA, it will see an RPF change when >> data arrive at a new >> >> >> s.o. >> >> In response to an exceeded threshold of >> packet transmission, >> DRs of >> receivers eventually will initiated a >> source-specific >> Join for >> => In response to an exceeded threshold of >> packet transmission, >> DRs of >> receivers eventually will initiate a >> source-specific Join >> for >> >> >> Thanks, fixed. >> >> this (S,G) tree will range from >> the receiving DR via the (stable) LMA, >> the LMA-MAG tunnel >> to the >> mobile source >> => >> this (S,G) tree will range from >> the receiving DR via the (stable) LMA, >> the LMA-MAG tunnel, >> and the serving MAG to the >> mobile source (described from leave to >> root?) >> >> >> o.k. >> >> This tree is of higher routing efficiency >> than >> established in the previous phase two >> => >> This tree is of higher routing efficiency >> than >> that established in the previous phase two >> >> >> thanks, o.k. >> >> p.15 >> via the source register tunnel. Tree >> mainenance eventually >> triggered >> => via the source register tunnel. Tree >> maintenance eventually >> triggered >> >> >> Thanks, o.k. >> >> p.16 >> BIDIR-PIM MAY be deployed in the access >> network => >> BIDIR-PIM [RFC5015] MAY be deployed in >> the access network >> >> >> Ref has been provided before. >> >> remain uneffected by node mobility => >> remain unaffected by node >> mobility >> >> >> Thanks, fixed. >> >> spanning group tree => spanning tree for >> the multicast group >> /multicast spanning tree >> >> >> o.k., thanks. >> >> p.17 >> document. To overcome these deficits, an >> optimized approach to >> ==> AFAIU it does mainly cover deficits >> mentioned in sect. >> 4, if >> also those inefficiencies described in >> 3.2.5 are tackled this >> should be explained >> >> >> Actually, the main concerns that are addressed >> in this peering >> approach are from section 3.2.5, namely the >> parallel proxy >> instances, which route via an LMA. >> >> We've added text to make this clearer. >> >> >> Following different techniques, these >> requirements are met in >> the >> following solutions. >> ==> to me it seems to be one solution only >> (peering between MLD >> proxies) adapted to several multicast >> protocol implementations >> for ASM and SSM >> >> >> Yes, the original text covered also the >> multiple-upstream proxy, >> which moved to the appendix now. The text has >> been corrected now. >> >> but provide superior performance in the >> presence of source- >> specific signaling (IGMPv3/MLDv2). >> ==> Wouldn't a reference to RFC 4604 >> ("Using Internet Group >> Management Protocol Version 3 (IGMPv3) and >> Multicast Listener >> Discovery Protocol Version 2 (MLDv2) for >> Source-Specific >> Multicast") make sense or be helpful here? >> >> >> O.k., we've added this. >> >> >> p.18 >> This filter base Must be updated, if and => >> This filter base >> MUST be updated, if and >> >> >> thanks, fixed. >> >> In >> addition, local multicast packets are >> transferred >> => >> In >> addition, multicast packets from >> locally attached sources >> are transferred >> or: >> In addition, such locally arriving >> multicast packets are >> transferred >> >> >> O.k., reworded. >> >> p.19 >> 6. IANA Considerations >> TODO. >> ==> to me there seem to be no IANA >> activities arising from the >> proposed protocol modifications, right? >> >> >> Yes. >> >> p.20 >> the PMIPv6 domain will not actively >> terminate group membership >> prior >> to departure. >> => >> the PMIPv6 domain will in general not >> actively terminate group >> membership prior >> to departure. >> >> >> o.k. >> >> p.22 >> but alternate configuriations => but >> alternate configurations >> >> a state decomposition , if needed => a >> state decomposition, if >> needed... >> >> >> Thanks, fixed. >> >> Hope this helps. >> >> >> Yes, thanks a lot for this detailed review! >> >> Best wishes, >> >> Thomas >> >> >> -----Original Message----- >> From: multimob-bounces@ietf.org >> <mailto:multimob-bounces@ietf.**org<multimob-bounces@ietf.org> >> > >> <mailto:multimob-bounces@ietf.**__org >> <mailto:multimob-bounces@ietf.**org<multimob-bounces@ietf.org> >> >> >> [mailto:multimob-bounces@ietf. >> <mailto:multimob-bounces@ietf.**>____org >> <mailto:multimob-bounces@ietf.**__org >> <mailto:multimob-bounces@ietf.**org<multimob-bounces@ietf.org>>>] >> On Behalf Of >> internet-drafts@ietf.org >> <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org> >> > >> <mailto:internet-drafts@ietf._**_org >> >> <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org> >> >> >> Sent: Samstag, 13. Juli 2013 00:50 >> To: i-d-announce@ietf.org >> <mailto:i-d-announce@ietf.org> >> <mailto:i-d-announce@ietf.org >> <mailto:i-d-announce@ietf.org>**> >> Cc: multimob@ietf.org >> <mailto:multimob@ietf.org> <mailto:multimob@ietf.org >> >> <mailto:multimob@ietf.org>> >> Subject: [multimob] I-D Action: >> draft-ietf-multimob-pmipv6-___** >> _source-04.txt >> >> >> >> A New Internet-Draft is available from the >> on-line >> Internet-Drafts directories. >> This draft is a work item of the >> Multicast Mobility Working >> Group of the IETF. >> >> Title : Mobile Multicast >> Sender Support in >> Proxy Mobile IPv6 (PMIPv6) Domains >> Author(s) : Thomas C. Schmidt >> Shuai Gao >> Hong-Ke Zhang >> Matthias >> Waehlisch >> Filename : >> draft-ietf-multimob-pmipv6-___** >> _source-04.txt >> >> Pages : 24 >> Date : 2013-07-12 >> >> Abstract: >> Multicast communication can be enabled >> in Proxy Mobile >> IPv6 >> domains >> via the Local Mobility Anchors by >> deploying MLD Proxy >> functions at >> Mobile Access Gateways, via a direct >> traffic distribution >> within an >> ISP's access network, or by selective >> route optimization >> schemes. >> This document describes the support of >> mobile multicast >> senders in >> Proxy Mobile IPv6 domains for all >> three scenarios. >> Protocol >> optimizations for synchronizing PMIPv6 >> with PIM, as >> well as >> a peering >> function for MLD Proxies defined. >> Mobile sources always >> remain >> agnostic of multicast mobility >> operations. >> >> >> >> The IETF datatracker status page for this >> draft is: >> >> https://datatracker.ietf.org/_** >> ___doc/draft-ietf-multimob-___**_pmipv6-source<https://datatracker.ietf.org/____doc/draft-ietf-multimob-____pmipv6-source> >> <https://datatracker.ietf.org/** >> __doc/draft-ietf-multimob-__**pmipv6-source<https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source> >> > >> >> >> <https://datatracker.ietf.org/** >> __doc/draft-ietf-multimob-__**pmipv6-source<https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source> >> <https://datatracker.ietf.org/** >> doc/draft-ietf-multimob-**pmipv6-source<https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source> >> >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/___** >> _draft-ietf-multimob-pmipv6-__**__source-04<http://tools.ietf.org/html/____draft-ietf-multimob-pmipv6-____source-04> >> <http://tools.ietf.org/html/__** >> draft-ietf-multimob-pmipv6-__**source-04<http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04> >> > >> >> >> <http://tools.ietf.org/html/__** >> draft-ietf-multimob-pmipv6-__**source-04<http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04> >> <http://tools.ietf.org/html/** >> draft-ietf-multimob-pmipv6-**source-04<http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04> >> >> >> >> A diff from the previous version is >> available at: >> >> http://www.ietf.org/rfcdiff?__** >> __url2=draft-ietf-multimob-___**_pmipv6-source-04<http://www.ietf.org/rfcdiff?____url2=draft-ietf-multimob-____pmipv6-source-04> >> <http://www.ietf.org/rfcdiff?_** >> _url2=draft-ietf-multimob-__**pmipv6-source-04<http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04> >> > >> >> >> >> >> <http://www.ietf.org/rfcdiff?_** >> _url2=draft-ietf-multimob-__**pmipv6-source-04<http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04> >> <http://www.ietf.org/rfcdiff?** >> url2=draft-ietf-multimob-**pmipv6-source-04<http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04> >> >> >> >> >> Internet-Drafts are also available by >> anonymous FTP at: >> ftp://ftp.ietf.org/internet-__**__drafts/<ftp://ftp.ietf.org/internet-____drafts/> >> <ftp://ftp.ietf.org/internet-_**_drafts/<ftp://ftp.ietf.org/internet-__drafts/> >> > >> <ftp://ftp.ietf.org/internet-_**_drafts/<ftp://ftp.ietf.org/internet-__drafts/> >> <ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/> >> >> >> >> >> ______________________________**_____________________ >> >> multimob mailing list >> multimob@ietf.org <mailto:multimob@ietf.org> >> <mailto:multimob@ietf.org <mailto:multimob@ietf.org>> >> https://www.ietf.org/mailman/_**___listinfo/multimob<https://www.ietf.org/mailman/____listinfo/multimob> >> <https://www.ietf.org/mailman/**__listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob> >> > >> >> >> <https://www.ietf.org/mailman/**__listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob> >> <https://www.ietf.org/mailman/**listinfo/multimob<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 <tel:%2B49-40-42875-8452> ° >> ° >> http://www.informatik.haw-____**hamburg.de/~schmidt<http://www.informatik.haw-____hamburg.de/~schmidt> >> <http://www.informatik.haw-__**hamburg.de/~schmidt<http://www.informatik.haw-__hamburg.de/~schmidt> >> > >> >> >> <http://www.informatik.haw-__**hamburg.de/~schmidt<http://www.informatik.haw-__hamburg.de/~schmidt> >> <http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/~schmidt>>> >> Fax: >> +49-40-42875-8409 <tel:%2B49-40-42875-8409> ° >> ______________________________** >> _____________________ >> >> multimob mailing list >> multimob@ietf.org <mailto:multimob@ietf.org> >> <mailto:multimob@ietf.org <mailto:multimob@ietf.org>> >> https://www.ietf.org/mailman/_**___listinfo/multimob<https://www.ietf.org/mailman/____listinfo/multimob> >> <https://www.ietf.org/mailman/**__listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob> >> > >> >> <https://www.ietf.org/mailman/**__listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob> >> <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob> >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org <mailto:multimob@ietf.org> >> https://www.ietf.org/mailman/_**_listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob> >> <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob> >> > >> >> >> >
- [multimob] I-D Action: draft-ietf-multimob-pmipv6… internet-drafts
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Dirk.von-Hugo
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Rahman, Akbar
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Cong Liu
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Stig Venaas
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Thomas C. Schmidt
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Stig Venaas
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Behcet Sarikaya
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Stig Venaas
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Behcet Sarikaya
- Re: [multimob] I-D Action: draft-ietf-multimob-pm… Dirk.von-Hugo