From multimob-bounces@ietf.org Wed Aug 6 07:41:55 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C45728C354; Wed, 6 Aug 2008 07:41:55 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9FD3A6AEB for ; Wed, 6 Aug 2008 07:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZHnqWcZJBIe for ; Wed, 6 Aug 2008 07:41:53 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id AD4813A6AA9 for ; Wed, 6 Aug 2008 07:41:53 -0700 (PDT) Received: (qmail 44084 invoked by uid 60001); 6 Aug 2008 14:42:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=dfLTqGnNx6rLGKOSeb2CHkv00ech6c2ZCuLDZSnzQEhiMoXr3JucuRKLGEngS9pLbvAK3p4yaF/8kaPAkRVAtMLWxp2ywUd+0/FnAbSw/kZYtnxlSNmLaGhuH4JI3KeAAUCNhgFjcwhNqI9q3cygvK2tW9lhD5aTRefMJ1zNc30=; Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Wed, 06 Aug 2008 07:42:25 PDT X-Mailer: YahooMailRC/1042.40 YahooMailWebService/0.7.218 Date: Wed, 6 Aug 2008 07:42:25 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <58095.43547.qm@web84301.mail.re1.yahoo.com> Subject: [multimob] Informal BoF Notes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0588379689==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0588379689== Content-Type: multipart/alternative; boundary="0-1994942054-1218033745=:43547" --0-1994942054-1218033745=:43547 Content-Type: text/plain; charset=us-ascii Dear all, We were counting on an audio recording to make detailed minutes but NOC had to interrupt the recording before our session was held. Here are my notes: - PIM co-chair Mike McBride asked mobility on which links (802.11, 802.16e, 3GPP/2) should be mentioned in the charter. Dave Thaler said it should be the link characteristic that should be mentioned. Link characteristics are shared link versus point-to-point links, predictive handover vs reactive handover possible, adhoc vs infrastructure links (are there others I left out?). - PMIPv6 Multicast Extension charter item was discussed extensively. My recollection of the identified requirements is: A. Minimize loss ... B. Minimize join latency C. Minimize transport cost D. Minimize duplication of packets towards one end (from MAG to LMA or from LMA to MAG) We agreed on a schedule to produce the requirements drafts and the volunteers were identified. Jari said it will be good to have a -00 solution draft by the draft submission deadline of IETF-73 (possibly mid-October). The schedule is as follows: mid-September initial version of PMIPv6 multicast protocol requirements draft end-September or early October both Group Management & PMIPv6 requirements drafts 00 solution draft mid October for PMIPv6 and 01 (or 02) solution draft for Group Management protocol solutions. Kind regards, Behcet --0-1994942054-1218033745=:43547 Content-Type: text/html; charset=us-ascii
Dear all,
  We were counting on an audio recording to make detailed minutes but NOC had to interrupt the recording before our session was held.
  Here are my notes:
- PIM co-chair Mike McBride asked mobility on which links (802.11, 802.16e, 3GPP/2) should be mentioned in the charter. Dave Thaler said it should be the link characteristic that should be mentioned. Link characteristics are shared link versus point-to-point links, predictive handover vs reactive handover possible, adhoc vs infrastructure links (are there others I left out?).
- PMIPv6 Multicast Extension charter item was discussed extensively. My recollection of the identified requirements is:
A. Minimize loss ...
B. Minimize join latency
C. Minimize transport cost
D. Minimize duplication of packets towards one end (from MAG to LMA or from LMA to MAG)

We agreed on a schedule to produce the requirements drafts and the volunteers were identified. Jari said it will be good to have a -00 solution draft by the draft submission deadline of IETF-73 (possibly mid-October).
The schedule is as follows:
mid-September initial version of PMIPv6 multicast protocol requirements draft
end-September or early October both Group Management & PMIPv6 requirements drafts
00 solution draft mid October for PMIPv6 and 01 (or 02) solution draft for Group Management protocol solutions.

Kind regards,

Behcet



--0-1994942054-1218033745=:43547-- --===============0588379689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0588379689==-- From multimob-bounces@ietf.org Wed Aug 6 08:10:19 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD0128C358; Wed, 6 Aug 2008 08:10:19 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDFF28C358 for ; Wed, 6 Aug 2008 08:10:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlBk5zUMCvDm for ; Wed, 6 Aug 2008 08:10:16 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 897253A67D8 for ; Wed, 6 Aug 2008 08:10:16 -0700 (PDT) Received: from [172.168.1.121] (adsl-76-204-79-54.dsl.pltn13.sbcglobal.net [76.204.79.54]) (authenticated bits=0) by nagasaki.bogus.com (8.14.2/8.14.2) with ESMTP id m76FAhNo082275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Aug 2008 15:10:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4899BEF0.5040007@bogus.com> Date: Wed, 06 Aug 2008 08:10:40 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Behcet Sarikaya References: <58095.43547.qm@web84301.mail.re1.yahoo.com> In-Reply-To: <58095.43547.qm@web84301.mail.re1.yahoo.com> X-Enigmail-Version: 0.95.6 X-Virus-Scanned: ClamAV 0.93.1/7959/Wed Aug 6 13:06:37 2008 on nagasaki.bogus.com X-Virus-Status: Clean Cc: multimob@ietf.org Subject: Re: [multimob] Informal BoF Notes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Behcet Sarikaya wrote: > Dear all, > We were counting on an audio recording to make detailed minutes but > NOC had to interrupt the recording before our session was held. yeah sorry about that... > Here are my notes: > - PIM co-chair Mike McBride asked mobility on which links (802.11, > 802.16e, 3GPP/2) should be mentioned in the charter. Dave Thaler said it > should be the link characteristic that should be mentioned. Link > characteristics are shared link versus point-to-point links, predictive > handover vs reactive handover possible, adhoc vs infrastructure links > (are there others I left out?). > - PMIPv6 Multicast Extension charter item was discussed extensively. My > recollection of the identified requirements is: > A. Minimize loss ... > B. Minimize join latency > C. Minimize transport cost > D. Minimize duplication of packets towards one end (from MAG to LMA or > from LMA to MAG) > > We agreed on a schedule to produce the requirements drafts and the > volunteers were identified. Jari said it will be good to have a -00 > solution draft by the draft submission deadline of IETF-73 (possibly > mid-October). > The schedule is as follows: > mid-September initial version of PMIPv6 multicast protocol requirements > draft > end-September or early October both Group Management & PMIPv6 > requirements drafts > 00 solution draft mid October for PMIPv6 and 01 (or 02) solution draft > for Group Management protocol solutions. > > Kind regards, > > Behcet > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 multimob-bounces@ietf.org Thu Aug 21 14:40:39 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441DE3A6ABC; Thu, 21 Aug 2008 14:40:39 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EBD3A6ABC for ; Thu, 21 Aug 2008 14:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.39 X-Spam-Level: X-Spam-Status: No, score=-100.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIBWdQn1Csjz for ; Thu, 21 Aug 2008 14:33:00 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id CBF853A685F for ; Thu, 21 Aug 2008 14:32:59 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178168087.adsl.alicedsl.de ([85.178.168.87] helo=mw-thinkpad) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KWHlM-000DV8-Sj for multimob@ietf.org; Thu, 21 Aug 2008 23:32:13 +0200 Date: Thu, 21 Aug 2008 23:32:12 +0200 From: Matthias Waehlisch To: multimob@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 X-FHTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-FHTW-MAINCATEGORY: clean X-FHTW-SPAMID: 151674::080821232504-29D4B940-CDDC2D53/0-0/0-1 Subject: Re: [multimob] Informal BoF Notes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi all, here are some additions: --snip-- Chairs introduce the multimob charter focusing on IGMPv3/MLDv2 and PMIPv6 extensions. Mike: What is exactly mean with mobility, WiFi ...? Brian: Mobile IP scenarios. ------ Thomas presents current status of problem statement draft. Last call will be invoked after this IETF meeting. Suresh: Problem statment covers also a lot of research issues. Source mobility is a too large problem ... Only parts of the problem statment should be under consideration for the WG. Marshall: We need a requirement draft, otherwise too big problem. We should narrow down the problem scope. Dave: Agrees with previous comments ... ------ Brian points out key issues of group management protocol extensions. Would like to see an IETF requirement draft describing interfaces and scenarios. Marshall: Do you see that it requires a new protocol for IGMP? Brian: No. Specifying either timing changes or additional messages that handle mobility constraints will be probably sufficient - we should not introduce fundamental changes to the group management, especially state machine. Toerless: API and protocol are two different issues. Hitoshi: Extensions should be considered as optional function. Brian: We need a requirement document about: Which scenario requires what. Toerless: Why do we not concentrate on problems first, which are not related to specific layer 2 technologies. Suresh: One can optimize layer 3 for layer 2 technologies. Brian: We should focus on general layer 2/layer 3 characteristics, not on specific layer 2 standards - Toerless agrees. Suresh: Maybe, we should introduce protocol profiles. Brian: First step, is to understand the basic mobile IP requirements Dave: Characteristics of link types seem more important than specific link technologies. ------ Hui presents requirements for PMIPv6. LMAs maintains n times tunnels (current situation). Dave: asks for clarification of the problem addressed. Discussion about first solutions. Thomas: Do you want MN to change its IP-stack, when using PMIPv6? Dave: The PMIPv6 scenario does not allow changes to the host! Discussion: Requirement vs. problem statement ... Items on the slide describe solutions and not requirements, e.g., LMA needs to buffer packets during handover. The corresponding requirement would be: minimize join latency. Suresh: Minimize duplication of packets between MAG and LMA. Hitoshi: MAG may become an IGMP/MLD proxy. --snap-- Cheers matthias -- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik :. link-lab :. Berliner Tor 7, 20099 Hamburg :. Hoenower Str. 35, 10318 Berlin :. Germany, mailto:waehlisch@ieee.org :. Germany, mailto:mw@link-lab.net :. http://home.fhtw-berlin.de/~mw :. http://www.link-lab.net :. :. FU Berlin, Inst. Informatik, Berlin, Germany http://www.mi.fu-berlin.de _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Aug 27 19:31:01 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A173A6AC2; Wed, 27 Aug 2008 19:31:01 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A633A66B4 for ; Wed, 27 Aug 2008 19:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.504 X-Spam-Level: *** X-Spam-Status: No, score=3.504 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xKy6sU7uHnF for ; Wed, 27 Aug 2008 19:31:00 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id CAAC43A6AC2 for ; Wed, 27 Aug 2008 19:30:59 -0700 (PDT) Received: from localhost (dhcp-143-230.sfc.wide.ad.jp [203.178.143.230]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id A3F2C13D03D6 for ; Thu, 28 Aug 2008 11:17:36 +0900 (JST) Date: Thu, 28 Aug 2008 11:30:58 +0900 (JST) Message-Id: <20080828.113058.205307583.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Aug_28_11_30_58_2008_135)--" Content-Transfer-Encoding: 7bit Subject: [multimob] Fw: PMIPv6 Requirements Draft X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org ----Next_Part(Thu_Aug_28_11_30_58_2008_135)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I try to send this again... ----Next_Part(Thu_Aug_28_11_30_58_2008_135)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Date: Thu, 28 Aug 2008 02:13:13 +0900 (JST) Message-Id: <20080828.021313.75768929.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org Subject: Re: PMIPv6 Requirements Draft From: Hitoshi Asaeda In-Reply-To: References: <48B45FA7.9000306@informatik.haw-hamburg.de> <007501c9082e$45abe1e0$7d02020a@denghui> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit (I moved this discussion to the ML. Sorry for some of you guys who don't catch the point.) Hi Pierrick, > MAG subscribing on behalf to the MN is just an example of solution > to illustrate the purpose. However this example is not supposed to > be in the requirement draft. Right. > But just to clarify my purpose; this > example is inspired from the way a DVB-(T or H) gateway is > performing IP multicast management: the gateway subscribes to > multicast groups and then broadcasts multicast flows on the radio > link. Well, this assumption will depend on the service model. So, I think the example, "MAG subscribs on behalf to the MN", is not the common case described in the requirement draft. > > I cannot remember there is a definitive assumption that oMAG and nMAG > > have link. It may be possible as an extension for CT, but it depends > > on the configuration of PMIP. Am I wrong? > > You're right, PMIP does not assume interface between MAGs; actually > I was thinking to "something" similar to inter-MAG data forwarding > as per PFMIP: > http://tools.ietf.org/html/draft-yokota-mipshop-pfmipv6-03 > > Anyway, R4.1 and R4.2 are clues for solution and should be out of > the scope of the requirement draft. So, the requirement to > retain here is only R#4 : Minimise cost on the forwarding link > (upstream link from the new MAG) Right. > > > R#6 scalability: solution must be scalable (basically solution > > > should not consider the LMA as a mulicast traffic bottleneck; the > > > LMA should not have to maintain a list of subscribed groups per all > > > MN in its PMIP domain) > > > > In my sense, as the requirement, this statement is too strong. > > Maybe it is necessary to detail the use case. > > I agree this is a strong requirement for the solution; clearly the > draft should detail the use-case. But rapidly, the idea is that this > requirement is linked to Scalability and reliability; as Dirk wrote, > the solution should avoid single point of failure. Can we agree on > this requirement? Sorry, my comment was ambiguous. Yes, I agree that the scalability issues should be descrived in the requirement draft. The statement that seems to be too strong is; "LMA should not have to maintain a list of subscribed groups per all MN". Because it seems that you imply or imagin some definitive (or concrete) service model. I mean, the condition whether LMA maintains subscribers groups or not depends on the solution, and hence it's better if the statement is changed in order to fit more general scenario. > > > R#7 access control: the network should be able to perfom admission > > > control > > > according to: > > > - resource availability on the access network, > > > - user profile (e.g. user subscription right) > > > - user preference (e.g. parental control) > > > > > Well, I'd like to know the detail for it.. > > Well, this is typically an operator requirement for IPTV > service. Now I don't know if it affects design of multicast support > for PMIP; but I guess it brings requirements on the MAG to perform > admission control, as expessed in Hui's proposal (section 4). Yes. As you said, it's an operator requirement especially for IPTV service. Admission control, accounting, and so on would be the one, too. They depend on the service model, not a requirement for protocol. One question. Does this requirement draft include the consideration of service models? Or the main aim of this requirement draft is to clarify the issues or roles of IP multicast protocols (IGMP/MLD and routing protocols) and behaviors for entities of PMIP? I thought the latter. (That's why I asked "Is it necessary for the requirement for PMIP?" in my previous mail.) Folks, what do you think? > > > R#8 security: some multicast flows could be ciphered (same > > > requirement as access control?) > > > > Is it necessary for the requirement for PMIP? > > To clarify the context: the use-case here is pay-per-view TV. As > preceding, I don't know if it affects design of multicast support > for PMIP. But it is clearly a service requirement. Right. This is the service requirement. > > > R#10 assuming a multi-interface terminal, the solution should > > > support inter-technology handover (the MN should be able to switch > > > multicast flow from one interface to another) > > > > Is it necessary for the requirement for PMIP? > > For operators (at least for FT ;-)), inter-technology handover is > probably the first use-case for PMIP. It is also true for mobile > multicast services. Now, does it bring a requirement for multicast > PMIP? I don't know but since this issue is discussing for PMIP I > guess we should address the point. IMO, this issue is not only for PMIP. Well, the discussion may be exciting :), but it may be better to be addressed or described in a separate draft. But again, it depends on the goal of this draft. If this draft will consider service models, then it'd be possible to be inside of this draft. Thanks, -- Hitoshi Asaeda ----Next_Part(Thu_Aug_28_11_30_58_2008_135)-- Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ----Next_Part(Thu_Aug_28_11_30_58_2008_135)---- From multimob-bounces@ietf.org Thu Aug 28 00:30:24 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13703A69D7; Thu, 28 Aug 2008 00:30:24 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0D93A68C1 for ; Thu, 28 Aug 2008 00:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odf1KATjhQpa for ; Thu, 28 Aug 2008 00:30:23 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 886F93A683E for ; Thu, 28 Aug 2008 00:30:22 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 09:30:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 09:30:19 +0200 Message-ID: In-Reply-To: <20080828.021313.75768929.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PMIPv6 Requirements Draft Thread-Index: AckI3+w6/RMcjoI8Q8e2l/I+pAcx+w== References: <48B45FA7.9000306@informatik.haw-hamburg.de><007501c9082e$45abe1e0$7d02020a@denghui> <20080828.021313.75768929.asaeda@sfc.wide.ad.jp> From: To: , X-OriginalArrivalTime: 28 Aug 2008 07:30:20.0689 (UTC) FILETIME=[ED30B010:01C908DF] Subject: Re: [multimob] PMIPv6 Requirements Draft X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Hitoshi, = Please see inline for comments. Regards, Pierrick > -----Message d'origine----- > De=A0: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > Envoy=E9=A0: mercredi 27 ao=FBt 2008 19:13 > =C0=A0: multimob@ietf.org > Objet=A0: Re: PMIPv6 Requirements Draft > = > (I moved this discussion to the ML. Sorry for some of you guys who > don't catch the point.) > = > Hi Pierrick, > = > > MAG subscribing on behalf to the MN is just an example of solution > > to illustrate the purpose. However this example is not supposed to > > be in the requirement draft. > = > Right. > = > > But just to clarify my purpose; this > > example is inspired from the way a DVB-(T or H) gateway is > > performing IP multicast management: the gateway subscribes to > > multicast groups and then broadcasts multicast flows on the radio > > link. > = > Well, this assumption will depend on the service model. So, I think > the example, "MAG subscribs on behalf to the MN", is not the common > case described in the requirement draft. > = > > > I cannot remember there is a definitive assumption that oMAG and nMAG > > > have link. It may be possible as an extension for CT, but it depends > > > on the configuration of PMIP. Am I wrong? > > > > You're right, PMIP does not assume interface between MAGs; actually > > I was thinking to "something" similar to inter-MAG data forwarding > > as per PFMIP: > > http://tools.ietf.org/html/draft-yokota-mipshop-pfmipv6-03 > > > > Anyway, R4.1 and R4.2 are clues for solution and should be out of > > the scope of the requirement draft. So, the requirement to > > retain here is only R#4 : Minimise cost on the forwarding link > > (upstream link from the new MAG) > = > Right. > = > > > > R#6 scalability: solution must be scalable (basically solution > > > > should not consider the LMA as a mulicast traffic bottleneck; the > > > > LMA should not have to maintain a list of subscribed groups per all > > > > MN in its PMIP domain) > > > > > > In my sense, as the requirement, this statement is too strong. > > > Maybe it is necessary to detail the use case. > > > > I agree this is a strong requirement for the solution; clearly the > > draft should detail the use-case. But rapidly, the idea is that this > > requirement is linked to Scalability and reliability; as Dirk wrote, > > the solution should avoid single point of failure. Can we agree on > > this requirement? > = > Sorry, my comment was ambiguous. > Yes, I agree that the scalability issues should be descrived in the > requirement draft. The statement that seems to be too strong is; > "LMA should not have to maintain a list of subscribed groups per all > MN". > Because it seems that you imply or imagin some definitive (or > concrete) service model. I mean, the condition whether LMA maintains > subscribers groups or not depends on the solution, and hence it's > better if the statement is changed in order to fit more general > scenario. I missed the point, sorry... Ok, I agree > = > > > > R#7 access control: the network should be able to perfom admission > > > > control > > > > according to: > > > > - resource availability on the access > network, > > > > - user profile (e.g. user subscription righ= t) > > > > - user preference (e.g. parental control) > > > > > > > Well, I'd like to know the detail for it.. > > > > Well, this is typically an operator requirement for IPTV > > service. Now I don't know if it affects design of multicast support > > for PMIP; but I guess it brings requirements on the MAG to perform > > admission control, as expessed in Hui's proposal (section 4). > = > Yes. As you said, it's an operator requirement especially for IPTV > service. Admission control, accounting, and so on would be the one, > too. They depend on the service model, not a requirement for > protocol. > = > One question. > Does this requirement draft include the consideration of service > models? Or the main aim of this requirement draft is to clarify the > issues or roles of IP multicast protocols (IGMP/MLD and routing > protocols) and behaviors for entities of PMIP? > I thought the latter. (That's why I asked "Is it necessary for the > requirement for PMIP?" in my previous mail.) > = > Folks, what do you think? I agree that requirement draft is not supposed to include consideration on = service. But I suspect that some service features may lead to requirement o= n PMIP entities; that's why we put some requirements on admission control. > = > > > > R#8 security: some multicast flows could be ciphered (same > > > > requirement as access control?) > > > > > > Is it necessary for the requirement for PMIP? > > > > To clarify the context: the use-case here is pay-per-view TV. As > > preceding, I don't know if it affects design of multicast support > > for PMIP. But it is clearly a service requirement. > = > Right. This is the service requirement. > = > > > > R#10 assuming a multi-interface terminal, the solution should > > > > support inter-technology handover (the MN should be able to switch > > > > multicast flow from one interface to another) > > > > > > Is it necessary for the requirement for PMIP? > > > > For operators (at least for FT ;-)), inter-technology handover is > > probably the first use-case for PMIP. It is also true for mobile > > multicast services. Now, does it bring a requirement for multicast > > PMIP? I don't know but since this issue is discussing for PMIP I > > guess we should address the point. > = > IMO, this issue is not only for PMIP. Well, the discussion may be > exciting :), but it may be better to be addressed or described in a > separate draft. I definitely agree solution could be addressed later (Of course, I do not e= xpect a solution for October) but we could add inter-tech handover in the r= equirement draft. I mean, we can try to make requirement draft as exhaustiv= e as possible; then solution draft expected for October could meet only a s= ubset of these requirements. = > But again, it depends on the goal of this draft. If this draft will > consider service models, then it'd be possible to be inside of this > draft. > = > Thanks, > -- > Hitoshi Asaeda Pierrick _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Aug 28 07:35:32 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497D23A6CB3; Thu, 28 Aug 2008 07:35:32 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB413A6C8D for ; Thu, 28 Aug 2008 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBsk2a+1XWnC for ; Thu, 28 Aug 2008 07:35:25 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id E64FA3A6CAF for ; Thu, 28 Aug 2008 07:35:24 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so233687tib.25 for ; Thu, 28 Aug 2008 07:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=dh6/Sg7eP/3PeFQ+TG4ZWxJAn70RNfm+a5a+LVClsKI=; b=D55ocyKsp/ignKO8blR1hJOZEwpqoZjFdhvxNAV+U8thS3t2ZWGWwOA0eIK8ODVXDg BESfNkYB6bzFohKQH4wEV1HxGGYvmBEfehcpRIimIn70u+uFKr1lOGy55xoTnhRhkmwa KN1e2xhJWchtldKL/puzgFBp8jU/juSA0Hn4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IdGBDuODMiiv0dEFKT2By/s6AwT/3LB2oK8guznDVjxTPAYMwVup1xbyeJQvUKXxVO kwJ9Ro/EuOTvZIYDX2aplWZkon+QHqSNBqzW4tF/2meSwcr3O2jkAod2Iy9UCGBcJvEC wNS3cCHIwk/QQ/RhyU8DpHG6tRDsaAvFfWPYA= Received: by 10.110.5.18 with SMTP id 18mr1525681tie.56.1219934124669; Thu, 28 Aug 2008 07:35:24 -0700 (PDT) Received: by 10.110.47.15 with HTTP; Thu, 28 Aug 2008 07:35:24 -0700 (PDT) Message-ID: <1d38a3350808280735oaa8e814x536b507d7f896ed7@mail.gmail.com> Date: Thu, 28 Aug 2008 22:35:24 +0800 From: "Hui Deng" To: "Hitoshi Asaeda" In-Reply-To: <20080828.113058.205307583.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 References: <20080828.113058.205307583.asaeda@sfc.wide.ad.jp> Cc: multimob@ietf.org Subject: Re: [multimob] Fw: PMIPv6 Requirements Draft X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1207377814==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1207377814== Content-Type: multipart/alternative; boundary="----=_Part_57709_12474713.1219934124650" ------=_Part_57709_12474713.1219934124650 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > One question. > Does this requirement draft include the consideration of service > models? Or the main aim of this requirement draft is to clarify the > issues or roles of IP multicast protocols (IGMP/MLD and routing > protocols) and behaviors for entities of PMIP? > I thought the latter. (That's why I asked "Is it necessary for the > requirement for PMIP?" in my previous mail.) > > Folks, what do you think? > Service model should be out of the scope of this document, but it may give some influence to current doc which we couldn't ignore, thanks -Hui ------=_Part_57709_12474713.1219934124650 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
One question.
Does this requirement draft include the consideration of service
models? Or the main aim of this requirement draft is to clarify the
issues or roles of IP multicast protocols (IGMP/MLD and routing
protocols) and behaviors for entities of PMIP?
I thought the latter. (That's why I asked "Is it necessary for the
requirement for PMIP?" in my previous mail.)

Folks, what do you think?
Service model should be out of the scope of this document,
but it may give some influence to current doc which we couldn't ignore,
 
thanks
 
-Hui
------=_Part_57709_12474713.1219934124650-- --===============1207377814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1207377814==--