From mobopts-bounces@irtf.org Tue Oct 03 12:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUn62-00078a-Ry; Tue, 03 Oct 2006 12:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUn61-00078V-Mp for mobopts@irtf.org; Tue, 03 Oct 2006 12:26:17 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUn5y-0002ar-8C for mobopts@irtf.org; Tue, 03 Oct 2006 12:26:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k93GQB7P029714 for ; Tue, 3 Oct 2006 19:26:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:26:13 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 11:26:10 -0500 Received: from 10.241.32.15 ([10.241.32.15]) by mvebe101.NOE.Nokia.com ([172.19.64.23]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Oct 2006 16:26:09 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 03 Oct 2006 09:26:13 -0700 From: Rajeev Koodli To: Message-ID: Thread-Topic: RG last call Thread-Index: AcbnCKRd4rcAa1L7EdubMwAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 16:26:10.0364 (UTC) FILETIME=[A2CB87C0:01C6E708] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mobopts] RG last call X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, This is the last call for comments on draft-irtf-mobopts-l2-abstractions-01.txt The last call expires on October 20, 06. Please provide your input by then. Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Oct 04 11:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8qr-0008KP-Ng; Wed, 04 Oct 2006 11:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8qq-0008GK-Ew for mobopts@irtf.org; Wed, 04 Oct 2006 11:40:04 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8qp-0000A8-3P for mobopts@irtf.org; Wed, 04 Oct 2006 11:40:04 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 459FE200C93F; Wed, 4 Oct 2006 17:40:29 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19521-02; Wed, 4 Oct 2006 17:40:29 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3343B20031EF; Wed, 4 Oct 2006 17:40:29 +0200 (CEST) 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: Wed, 4 Oct 2006 17:39:59 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD6962293BA@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt Thread-Index: AcaFvwCjLyPg7NxXR2yqaMhwRUPAXAEV7gyQF2zayrA= From: "Simon Schuetz" To: , , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Mobopts] FW: I-D ACTION:draft-schuetz-tcpm-tcp-rlci-00.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > Title: TCP Response to Lower-Layer Connectivity-Change Indications > Author(s) : S. Schuetz, et al. > Filename : draft-schuetz-tcpm-tcp-rlci-00.txt Hi, The above mentioned draft was presented to TCPM WG at the last IETF meeting. We haven't received feedback yet and would like to ask the working groups to review and comment on the current version. http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-00.txt Although posted to multiple working groups, we'd like to keep the main discussion on the tcpm mailing list. Thanks, Simon _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Oct 06 14:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVu3g-0007vX-Cq; Fri, 06 Oct 2006 14:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVu3f-0007vS-Qq for mobopts@irtf.org; Fri, 06 Oct 2006 14:04:27 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVu3e-00046L-CL for mobopts@irtf.org; Fri, 06 Oct 2006 14:04:27 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k96I4OdI030402 for ; Fri, 6 Oct 2006 21:04:25 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 21:04:24 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 13:04:21 -0500 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, 6 Oct 2006 11:04:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: presentations Thread-Index: AcbpcdoB8+9rVjn6Sx2NWFF3XNNIrA== From: To: X-OriginalArrivalTime: 06 Oct 2006 18:04:21.0199 (UTC) FILETIME=[D93EDDF0:01C6E971] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mobopts] presentations X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, please let me know if you would like to present your work at the San Diego meeting. Provide o title o time for your presentation, and o a URL to your work Please let me know as soon as possible. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sat Oct 07 08:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWAq2-0008WV-93; Sat, 07 Oct 2006 07:59:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWAq0-0008WN-FB for mobopts@irtf.org; Sat, 07 Oct 2006 07:59:28 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWApv-0001Ap-3B for mobopts@irtf.org; Sat, 07 Oct 2006 07:59:28 -0400 Received: from e178169206.adsl.alicedsl.de ([85.178.169.206] helo=[192.168.178.25]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1GWApu-000IOY-8z; Sat, 07 Oct 2006 13:59:22 +0200 Message-ID: <45279733.6060807@fhtw-berlin.de> Date: Sat, 07 Oct 2006 14:01:55 +0200 From: Thomas C Schmidt User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: rajeev.koodli@nokia.com Subject: Re: [Mobopts] presentations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, we would like to present o "Multicast Mobility in MIPv6: Problem Statement - update" o Time: 10-15 min o URLs: http://www.realmv6.org http://www.rz.fhtw-berlin.de/content/Projekte/mipv6/index.html http://users.informatik.haw-hamburg.de/~schmidt/bib/index.html http://home.fhtw-berlin.de/~mw/ Draft update is under way ;) Cheers thomas rajeev.koodli@nokia.com wrote: > Hello folks, > > please let me know if you would like to present your work > at the San Diego meeting. Provide > > o title > o time for your presentation, and > o a URL to your work > > Please let me know as soon as possible. > > Regards, > > -Rajeev > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 09 02:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoxY-0002C6-Pd; Mon, 09 Oct 2006 02:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoxX-0002C1-Hv for mobopts@irtf.org; Mon, 09 Oct 2006 02:49:55 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWoxT-0008AR-P0 for mobopts@irtf.org; Mon, 09 Oct 2006 02:49:55 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GWoxD-0005aM-HT; Mon, 09 Oct 2006 08:49:41 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GWoxC-0005Uv-DK; Mon, 09 Oct 2006 08:49:34 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B028D876B; Mon, 9 Oct 2006 08:49:33 +0200 (CEST) Message-ID: <4529F0FD.2090907@tm.uka.de> Date: Mon, 09 Oct 2006 08:49:33 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-0.1 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: tera@ics.keio.ac.jp, gogo@tera.ics.keio.ac.jp, mitsuya@sfc.wide.ad.jp, shibrie@tera.ics.keio.ac.jp, koki@tera.ics.keio.ac.jp Subject: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -11.9 (-----------) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -7.5 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi authors, cross-layer interaction between L2 and L3 is an important topic given the increasing use of mobility and multi-homing across heterogeneous networks. I think it is good that you are working on this. OTOH, I do concur with the observation recently raised on the ML that there is an obvious overlap between your work and the ongoing work of the IEEE 802.21 working group. (IEEE 802.21 is working on the topic in a broader context. E.g., it also considers over-the-network events, commands, and information retrieval.) I won't further comment an any potential conflicts between your work and the work of IEEE 802.21, but do state my personal opinion that the two proposals should be harmonized and possibly merged. Architectural differences compared to IEEE 802.21 - Your proposal does not strictly differentiate between events, commands, and information retrieval services, as the IEEE 802.21 work does. (I recognize that you are using different "types" of primitives, but nonetheless.) It may be of benefit if you stated at some place in the beginning of the draft that you don't make/need this differentiation. It's one of the main architectural differences between your work and the IEEE 802.21 work. - You may also want to mention in the very beginning that your approach does not use an intermediate shim layer through which primitives are exchanged. This is another architectural difference between your work and the IEEE 802.21 work, which defines an MIH function between L2 and L3. Section 2, Terminology. - You should do without the definition of "peer" IMO; use "point of attachment" or "attachment point" instead. "Peer" has a widely accepted end-to-end meaning, where a peer of node X is another node Y with which X communicates at application layer. Defining the peer to be an access point may be confusing. Section 3, Primitives for L2 Abstractions - The draft defines a Confirm primitive to be the reply for a Request primitive, and the Response primitive to be the reply for an Indication primitive. Intuitively, I would have matched Request with Response, and Indication with Confirm, in which case figure 1 would look like this: ------------------------------------------------------ Request Confirm || /\ /\ || Layer N || || || || ------------||------||----------||------||------------ || || || || \/ || || \/ Layer N-m Response Indication ------------------------------------------------------ - You define Protocol Layer ID and Protocol ID fields to be included in all primitives. Are these fields really necessary? After all, the primitives are delivered directly from a protocol instance at one layer to a protocol instance at another layer, so what is the purpose of having the destination field? The primitives are not relayed or distributed anywhere where the destination fields might have to be consulted, as they would by an intermediate shim like like the MIH function in IEEE 802.21. Section 4.7, L2-LinkGoingDown (Type 2) - The text in this section describes the registration process for the Link Going Down event: > In the registration processing, the > L2-LinkGoingDown.request primitive carries the "Network Interface ID" > parameter and the "Enable/Disable" parameter. According to section 3, /all/ type 2 primitives use registration, but the registration process is explained only here. I'd therefore recommend to move the above text to the beginning of the section, and generalize it so that it becomes applicable to all type 2 primitives. - It is not clear whether a protocol interested in a type 2 primitive must re-register for the primitive after it has received the primitive once. E.g., if a movement detection daemon on a mobile node registers for the Link Going Down primitive and eventually receives one such primitive, does it have to register again in order to receive a Link Going Down primitive for the next handoff? Section 6.2, Condition - You may want to state that the conditions provided should be limited to those which do not change rapidly for other reasons than the behavior of the node implementing L2 abstractions. E.g., another interesting link condition might be the access latency for the medium. But the access latency may be a function of the number of other nodes competing for bandwidth, and hence is a very dynamic condition even if the node implementing L2 abstractions does not move and does not change communications patterns. It may hence be difficult to implement another "access latency" link condition. Section 7, Architectural Considerations > [4] Upper layers should utilize a timely recovery step so as to > limit the potential damage from link indications determined to > be invalid after they have been acted on. > > The proposed L3-driven handover described in Appendix D uses > the L2-LinkGoingDown indication as the trigger for starting > handover. L2-LinkGoingDown is indicated when the link quality > goes down below the specific threshold. This indication is not > canceled even if the link quality goes up soon. As described > above, L2-LinkStatus can be used to detect the most suitable > AP. The IP layer can cancel a handover if it finds that the > current AP is the most suitable one by using L2-LinkStatus when > L2-LingGoingDown is notified. You could avoid possible issues with anticipatory indications if you replaced the Link Going Down indication (which is the only anticipatory indication in your draft) by periodic or on-demand link status reports which notify an interested upper-layer protocol of link status changes. The upper-layer protocol can then make its own projections about when the current link attachment will go down due to decreasing signal quality. (Note that an additional use case for the similar Link Going Down indication in IEEE 802.21 is for the network to warn a mobile node about a forthcoming shutdown of a base station. You don't define over-the-network indications in your draft, so you may not actually depend on the Link Going Down indication.) > [8] Proposals should avoid race conditions, which can occur where > link indications are utilized directly by multiple layers of > the stack. > > Since our proposal defines the link indications to only the IP > layer, race conditions between multiple layers never happen. But there may be race conditions between protocols on the same layer. Take, e.g., Mobile IPv6 and Stateless Address Autoconfiguration. If Mobile IPv6 tries to register a new care-of address once it receives a Link Up indication, Stateless Address Autoconfiguration may not yet have such a new care-of address configured. The configuration of a new care-of address further depends on router and prefix discovery, which may also be triggered by the same Link Up indication. So there are plenty of race conditions, and all of them are within the IP layer. So far, so good. Best regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Rajeev Koodli wrote: > Folks, > > This is the last call for comments on > > draft-irtf-mobopts-l2-abstractions-01.txt > > The last call expires on October 20, 06. > > Please provide your input by then. > > Thanks, > > -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 09 11:37:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxBr-0003Fb-KU; Mon, 09 Oct 2006 11:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxBq-0003FV-PO for mobopts@irtf.org; Mon, 09 Oct 2006 11:37:14 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxBq-0004CO-25 for mobopts@irtf.org; Mon, 09 Oct 2006 11:37:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k99Fb4bZ028394; Mon, 9 Oct 2006 18:37:06 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 18:37:05 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:37:01 -0500 Received: from 10.241.59.137 ([10.241.59.137]) by mvebe101.NOE.Nokia.com ([172.19.64.23]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Oct 2006 15:36:59 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 09 Oct 2006 08:36:59 -0700 Subject: Re: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) From: Rajeev Koodli To: ext Christian Vogt , , , , , Message-ID: Thread-Topic: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) Thread-Index: AcbruMIfAKqX+lesEdu7AAAWy5YJpw== In-Reply-To: <4529F0FD.2090907@tm.uka.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 15:37:01.0023 (UTC) FILETIME=[C3544EF0:01C6EBB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Thanks for your input. I am sure the authors will find them worthwhile. I wanted to mention that we as an RG here should focus on the technical content rather than worrying about the "overlap" with 802.21. As I have mentioned previously, we should view this as a comprehensive investigation of L2 and L3 interactions in handovers and not necessarily as a study of 802.21. As was pointed out earlier in the ML, the authors could look into the gap between the primitives here and what 802.21 has defined. So, let's keep the focus on what this ID talks about in perspective. And, thank you for your other detailed comments. -Rajeev On 10/8/06 11:49 PM, "ext Christian Vogt" wrote: > Hi authors, > > cross-layer interaction between L2 and L3 is an important topic given > the increasing use of mobility and multi-homing across heterogeneous > networks. I think it is good that you are working on this. > > OTOH, I do concur with the observation recently raised on the ML that > there is an obvious overlap between your work and the ongoing work of > the IEEE 802.21 working group. (IEEE 802.21 is working on the topic in > a broader context. E.g., it also considers over-the-network events, > commands, and information retrieval.) I won't further comment an any > potential conflicts between your work and the work of IEEE 802.21, but > do state my personal opinion that the two proposals should be harmonized > and possibly merged. > > Architectural differences compared to IEEE 802.21 > > - Your proposal does not strictly differentiate between events, > commands, and information retrieval services, as the IEEE 802.21 work > does. (I recognize that you are using different "types" of primitives, > but nonetheless.) It may be of benefit if you stated at some place in > the beginning of the draft that you don't make/need this > differentiation. It's one of the main architectural differences between > your work and the IEEE 802.21 work. > > - You may also want to mention in the very beginning that your approach > does not use an intermediate shim layer through which primitives are > exchanged. This is another architectural difference between your work > and the IEEE 802.21 work, which defines an MIH function between L2 and L3. > > Section 2, Terminology. > > - You should do without the definition of "peer" IMO; use "point of > attachment" or "attachment point" instead. "Peer" has a widely accepted > end-to-end meaning, where a peer of node X is another node Y with which > X communicates at application layer. Defining the peer to be an access > point may be confusing. > > Section 3, Primitives for L2 Abstractions > > - The draft defines a Confirm primitive to be the reply for a Request > primitive, and the Response primitive to be the reply for an Indication > primitive. Intuitively, I would have matched Request with Response, and > Indication with Confirm, in which case figure 1 would look like this: > > ------------------------------------------------------ > Request Confirm > || /\ /\ || > Layer N || || || || > ------------||------||----------||------||------------ > || || || || > \/ || || \/ > Layer N-m Response Indication > ------------------------------------------------------ > > - You define Protocol Layer ID and Protocol ID fields to be included in > all primitives. Are these fields really necessary? After all, the > primitives are delivered directly from a protocol instance at one layer > to a protocol instance at another layer, so what is the purpose of > having the destination field? The primitives are not relayed or > distributed anywhere where the destination fields might have to be > consulted, as they would by an intermediate shim like like the MIH > function in IEEE 802.21. > > Section 4.7, L2-LinkGoingDown (Type 2) > > - The text in this section describes the registration process for the > Link Going Down event: > >> In the registration processing, the >> L2-LinkGoingDown.request primitive carries the "Network Interface ID" >> parameter and the "Enable/Disable" parameter. > > According to section 3, /all/ type 2 primitives use registration, but > the registration process is explained only here. I'd therefore > recommend to move the above text to the beginning of the section, and > generalize it so that it becomes applicable to all type 2 primitives. > > - It is not clear whether a protocol interested in a type 2 primitive > must re-register for the primitive after it has received the primitive > once. E.g., if a movement detection daemon on a mobile node registers > for the Link Going Down primitive and eventually receives one such > primitive, does it have to register again in order to receive a Link > Going Down primitive for the next handoff? > > Section 6.2, Condition > > - You may want to state that the conditions provided should be limited > to those which do not change rapidly for other reasons than the behavior > of the node implementing L2 abstractions. E.g., another interesting > link condition might be the access latency for the medium. But the > access latency may be a function of the number of other nodes competing > for bandwidth, and hence is a very dynamic condition even if the node > implementing L2 abstractions does not move and does not change > communications patterns. It may hence be difficult to implement another > "access latency" link condition. > > Section 7, Architectural Considerations > >> [4] Upper layers should utilize a timely recovery step so as to >> limit the potential damage from link indications determined to >> be invalid after they have been acted on. >> >> The proposed L3-driven handover described in Appendix D uses >> the L2-LinkGoingDown indication as the trigger for starting >> handover. L2-LinkGoingDown is indicated when the link quality >> goes down below the specific threshold. This indication is not >> canceled even if the link quality goes up soon. As described >> above, L2-LinkStatus can be used to detect the most suitable >> AP. The IP layer can cancel a handover if it finds that the >> current AP is the most suitable one by using L2-LinkStatus when >> L2-LingGoingDown is notified. > > You could avoid possible issues with anticipatory indications if you > replaced the Link Going Down indication (which is the only anticipatory > indication in your draft) by periodic or on-demand link status reports > which notify an interested upper-layer protocol of link status changes. > The upper-layer protocol can then make its own projections about when > the current link attachment will go down due to decreasing signal quality. > > (Note that an additional use case for the similar Link Going Down > indication in IEEE 802.21 is for the network to warn a mobile node about > a forthcoming shutdown of a base station. You don't define > over-the-network indications in your draft, so you may not actually > depend on the Link Going Down indication.) > >> [8] Proposals should avoid race conditions, which can occur where >> link indications are utilized directly by multiple layers of >> the stack. >> >> Since our proposal defines the link indications to only the IP >> layer, race conditions between multiple layers never happen. > > But there may be race conditions between protocols on the same layer. > Take, e.g., Mobile IPv6 and Stateless Address Autoconfiguration. If > Mobile IPv6 tries to register a new care-of address once it receives > a Link Up indication, Stateless Address Autoconfiguration may not yet > have such a new care-of address configured. The configuration of a new > care-of address further depends on router and prefix discovery, which > may also be triggered by the same Link Up indication. So there are > plenty of race conditions, and all of them are within the IP layer. > > So far, so good. > > Best regards, > - Christian _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Oct 20 04:18:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapZf-0001c9-Ux; Fri, 20 Oct 2006 04:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapZe-0001bL-9f for mobopts@irtf.org; Fri, 20 Oct 2006 04:17:50 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GapZb-0006hP-QB for mobopts@irtf.org; Fri, 20 Oct 2006 04:17:50 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Oct 2006 11:17:46 +0300 id 000AFD3A.4538862A.00006B22 Date: Fri, 20 Oct 2006 11:17:38 +0300 (EEST) From: Jukka MJ Manner To: Rajeev Koodli Subject: Re: [Mobopts] RG last call In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi all, I promised Rajeev to give a review of the draft, so here goes. In overall, I liked the document. Yet, I would remove all the sections (Appendix B.3 and D) that discuss the experiments, since those are difficult to verify, and do not really provide any important information, just that the scheme seems to work in some use case. Some more detailed comments: - Section 3 does not really discuss the Response primitive. In general, what is the use of the Response? Why would L3 really need to acknowledge an asynchronous Indication from L2? - Section 4: * is the proposal only for so-called Managed Mode (AP mode) link layers? How would this be applicable to ad-hoc or mesh radios? E.g., would L2-PeerList provide info about only L2 APs, but also other terminals? Would L2-LinkUp/Down tell which links to other ad-hoc nodes are up/down? * How do channels come into play? Does the L2-PeerList allow getting peers on different channels? Can L3 somehow control the use of channels? * After reading the whole spec, you actually later talk about quality of the signal in relation to the L2-PeerFound, i.e., only certain peers are told about to L3. That is not mentioned in Section 4. * Related to the above, and other requests, would there be a need to define some filters about which notifications are of interest? E.g. the above, a peer is announced only if the quality of the link to the peer is of some relative quality. * L2-PeerLost: provide info about which peers disappeared, but since when? Does L2 e.g. send a notification every second, and tell which peers disappeared within the past second? Or everytime there is even a one peer change in the list? * Is there any need to add some kind of security awareness to the primitives, i.e., is the link secure or not (how secure?)? E.g., to the link status primitive, or to a filter associated to the PeerFound? - Section 6.2 Condition: should the SNR be also provided? What is this "available bandwidth? If we talk about 802.11, if the link layer says I have full 54 Mbps connectivity, everybody knows that is about half the actual bandwidth I get for my IP packets. - Section 7: * [2]: As above, why is the Response needed in the first place? * [5]: You don't need congestion control in the transport, but you surely need rate limitation for how often indications are sent from L2 to L3. - Appendix A, p.20, 2nd sentence: I think the L2 and L3 are mixed: "L2 handover begins after the L2 sends L2-LinkConnect.confirm to the L3." - C.4: "is got lost" - C.6: "...frame to the AP, or the" > "...frame to the AP, and the" ? - C.7: "...and becomes under" > "...and falls unders"? Hope these comments help. Regards, Jukka On Tue, 3 Oct 2006, Rajeev Koodli wrote: > > Folks, > > This is the last call for comments on > > draft-irtf-mobopts-l2-abstractions-01.txt > > The last call expires on October 20, 06. > > Please provide your input by then. > > Thanks, > > -Rajeev > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Oct 20 14:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaylo-0007JQ-9A; Fri, 20 Oct 2006 14:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaylm-0007JG-Fw for mobopts@irtf.org; Fri, 20 Oct 2006 14:06:58 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaylk-0007bF-Uk for mobopts@irtf.org; Fri, 20 Oct 2006 14:06:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9KI6pVq005948; Fri, 20 Oct 2006 21:06:55 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 21:06:55 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 13:06:52 -0500 Received: from 10.241.59.85 ([10.241.59.85]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Oct 2006 18:06:52 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 20 Oct 2006 11:07:10 -0700 Subject: Re: [Mobopts] RG last call From: Rajeev Koodli To: ext Jukka MJ Manner Message-ID: Thread-Topic: [Mobopts] RG last call Thread-Index: Acb0co+kzmhi5mBlEduiwgAWy5YJpw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Oct 2006 18:06:52.0726 (UTC) FILETIME=[85588D60:01C6F472] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Thanks Jukka. A brief comment about the experiments: being an RG, we need exposure to them. So, we should include them appropriately, such as in an Appendix. But, I also agree that the system description has to be adequately provided so that folks know what to expect. Regards, -Rajeev On 10/20/06 1:17 AM, "ext Jukka MJ Manner" wrote: > > Hi all, > > I promised Rajeev to give a review of the draft, so here goes. > > In overall, I liked the document. Yet, I would remove all the sections > (Appendix B.3 and D) that discuss the experiments, since those are > difficult to verify, and do not really provide any important information, > just that the scheme seems to work in some use case. > > Some more detailed comments: > > - Section 3 does not really discuss the Response primitive. In general, > what is the use of the Response? Why would L3 really need to acknowledge > an asynchronous Indication from L2? > > - Section 4: > > * is the proposal only for so-called Managed Mode (AP mode) > link layers? How would this be applicable to ad-hoc or mesh radios? > E.g., would L2-PeerList provide info about only L2 APs, but also other > terminals? Would L2-LinkUp/Down tell which links to other ad-hoc nodes > are up/down? > > * How do channels come into play? Does the L2-PeerList allow getting > peers on different channels? Can L3 somehow control the use of > channels? > > * After reading the whole spec, you actually later talk about quality of > the signal in relation to the L2-PeerFound, i.e., only certain peers > are told about to L3. That is not mentioned in Section 4. > > * Related to the above, and other requests, would there be a need to > define some filters about which notifications are of interest? E.g. > the above, a peer is announced only if the quality of the link to the > peer is of some relative quality. > > * L2-PeerLost: provide info about which peers disappeared, but since > when? Does L2 e.g. send a notification every second, and tell which > peers disappeared within the past second? Or everytime there is even a > one peer change in the list? > > * Is there any need to add some kind of security awareness to the > primitives, i.e., is the link secure or not (how secure?)? E.g., to > the link status primitive, or to a filter associated to the PeerFound? > > - Section 6.2 Condition: should the SNR be also provided? What is this > "available bandwidth? If we talk about 802.11, if the link layer says I > have full 54 Mbps connectivity, everybody knows that is about half the > actual bandwidth I get for my IP packets. > > - Section 7: > * [2]: As above, why is the Response needed in the first place? > * [5]: You don't need congestion control in the transport, but you > surely need rate limitation for how often indications are sent > from L2 to L3. > > - Appendix A, p.20, 2nd sentence: I think the L2 and L3 are mixed: "L2 > handover begins after the L2 sends L2-LinkConnect.confirm to the L3." > > > - C.4: "is got lost" > > - C.6: "...frame to the AP, or the" > "...frame to the AP, and the" ? > > - C.7: "...and becomes under" > "...and falls unders"? > > > Hope these comments help. > > Regards, > Jukka > > On Tue, 3 Oct 2006, Rajeev Koodli wrote: > >> >> Folks, >> >> This is the last call for comments on >> >> draft-irtf-mobopts-l2-abstractions-01.txt >> >> The last call expires on October 20, 06. >> >> Please provide your input by then. >> >> Thanks, >> >> -Rajeev >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 23 01:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbspp-0007e1-N4; Mon, 23 Oct 2006 01:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbspo-0007dw-QC for mobopts@irtf.org; Mon, 23 Oct 2006 01:58:52 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbspk-0005QC-PG for mobopts@irtf.org; Mon, 23 Oct 2006 01:58:52 -0400 Received: from [IPv6:2001:200::8410:214:51ff:fed8:4c74] (unknown [IPv6:2001:200:0:8410:214:51ff:fed8:4c74]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1BF0B4D8AE; Mon, 23 Oct 2006 14:58:30 +0900 (JST) In-Reply-To: <4529F0FD.2090907@tm.uka.de> References: <4529F0FD.2090907@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D28DFA2-66E9-4590-8C3C-C6B428DF94F2@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Subject: Re: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) Date: Mon, 23 Oct 2006 14:59:02 +0900 To: Christian Vogt X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: Fumio Teraoka , Rie SHIBUI , Koshiro MITSUYA , koki mitani , Kazutaka GOGO , Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Thank you very much for your detailed comments. I am sorry for my delayed reply. Please find my comments inline: On 2006/10/09, at 15:49, Christian Vogt wrote: > Hi authors, > > cross-layer interaction between L2 and L3 is an important topic given > the increasing use of mobility and multi-homing across heterogeneous > networks. I think it is good that you are working on this. > Thanks. > OTOH, I do concur with the observation recently raised on the ML that > there is an obvious overlap between your work and the ongoing work of > the IEEE 802.21 working group. (IEEE 802.21 is working on the > topic in > a broader context. E.g., it also considers over-the-network events, > commands, and information retrieval.) I won't further comment an any > potential conflicts between your work and the work of IEEE 802.21, but > do state my personal opinion that the two proposals should be > harmonized > and possibly merged. > I agree that two proposals should be harmonized. We are looking forward how we can process that. > Architectural differences compared to IEEE 802.21 > > - Your proposal does not strictly differentiate between events, > commands, and information retrieval services, as the IEEE 802.21 work > does. (I recognize that you are using different "types" of > primitives, > but nonetheless.) It may be of benefit if you stated at some place in > the beginning of the draft that you don't make/need this > differentiation. It's one of the main architectural differences > between > your work and the IEEE 802.21 work. > Right. Our approach works fine for simple handover scenarios (e.g. same domain, same network access), but we may need more information for a complex handover scenarios (e.g. inter domain, mixed network access). I am not sure now. So we need to discuss how much impact the difference has. > - You may also want to mention in the very beginning that your > approach > does not use an intermediate shim layer through which primitives are > exchanged. This is another architectural difference between your work > and the IEEE 802.21 work, which defines an MIH function between L2 > and L3. > Right. We would like to have something works with the current deployed wireless networks. We do not want to add new entities in the network. > Section 2, Terminology. > > - You should do without the definition of "peer" IMO; use "point of > attachment" or "attachment point" instead. "Peer" has a widely > accepted > end-to-end meaning, where a peer of node X is another node Y with > which > X communicates at application layer. Defining the peer to be an > access > point may be confusing. > OK, I agree to use another world. > Section 3, Primitives for L2 Abstractions > > - The draft defines a Confirm primitive to be the reply for a Request > primitive, and the Response primitive to be the reply for an > Indication > primitive. Intuitively, I would have matched Request with > Response, and > Indication with Confirm, in which case figure 1 would look like this: > > ------------------------------------------------------ > Request Confirm > || /\ /\ || > Layer N || || || || > ------------||------||----------||------||------------ > || || || || > \/ || || \/ > Layer N-m Response Indication > ------------------------------------------------------ Agree. less confusing. > - You define Protocol Layer ID and Protocol ID fields to be > included in > all primitives. Are these fields really necessary? After all, the > primitives are delivered directly from a protocol instance at one > layer > to a protocol instance at another layer, so what is the purpose of > having the destination field? The primitives are not relayed or > distributed anywhere where the destination fields might have to be > consulted, as they would by an intermediate shim like like the MIH > function in IEEE 802.21. > We are thinking that the messages are exchanged between layers by using e.g. routing socket. It is an information method in which lll entities can hear all message. The protocol layer ID is used to filter unnecessary message, for example. > Section 4.7, L2-LinkGoingDown (Type 2) > > - The text in this section describes the registration process for the > Link Going Down event: > >> In the registration processing, >> the >> L2-LinkGoingDown.request primitive carries the "Network >> Interface ID" >> parameter and the "Enable/Disable" parameter. > > According to section 3, /all/ type 2 primitives use registration, but > the registration process is explained only here. I'd therefore > recommend to move the above text to the beginning of the section, and > generalize it so that it becomes applicable to all type 2 primitives. > I agree. > - It is not clear whether a protocol interested in a type 2 primitive > must re-register for the primitive after it has received the primitive > once. E.g., if a movement detection daemon on a mobile node registers > for the Link Going Down primitive and eventually receives one such > primitive, does it have to register again in order to receive a Link > Going Down primitive for the next handoff? > Such re-registration is not necessary. I will make it clear in the draft. > Section 6.2, Condition > > - You may want to state that the conditions provided should be limited > to those which do not change rapidly for other reasons than the > behavior > of the node implementing L2 abstractions. E.g., another interesting > link condition might be the access latency for the medium. But the > access latency may be a function of the number of other nodes > competing > for bandwidth, and hence is a very dynamic condition even if the node > implementing L2 abstractions does not move and does not change > communications patterns. It may hence be difficult to implement > another > "access latency" link condition. > Right. Do you think the state is needed to be more clear? > Section 7, Architectural Considerations > >> [4] Upper layers should utilize a timely recovery step so as to >> limit the potential damage from link indications >> determined to >> be invalid after they have been acted on. >> >> The proposed L3-driven handover described in Appendix D uses >> the L2-LinkGoingDown indication as the trigger for starting >> handover. L2-LinkGoingDown is indicated when the link >> quality >> goes down below the specific threshold. This indication >> is not >> canceled even if the link quality goes up soon. As >> described >> above, L2-LinkStatus can be used to detect the most suitable >> AP. The IP layer can cancel a handover if it finds that the >> current AP is the most suitable one by using L2- >> LinkStatus when >> L2-LingGoingDown is notified. > > You could avoid possible issues with anticipatory indications if you > replaced the Link Going Down indication (which is the only > anticipatory > indication in your draft) by periodic or on-demand link status reports > which notify an interested upper-layer protocol of link status > changes. > The upper-layer protocol can then make its own projections about when > the current link attachment will go down due to decreasing signal > quality. > > (Note that an additional use case for the similar Link Going Down > indication in IEEE 802.21 is for the network to warn a mobile node > about > a forthcoming shutdown of a base station. You don't define > over-the-network indications in your draft, so you may not actually > depend on the Link Going Down indication.) > Sorry, I do not see your point. >> [8] Proposals should avoid race conditions, which can occur >> where >> link indications are utilized directly by multiple layers of >> the stack. >> >> Since our proposal defines the link indications to only >> the IP >> layer, race conditions between multiple layers never happen. > > But there may be race conditions between protocols on the same layer. > Take, e.g., Mobile IPv6 and Stateless Address Autoconfiguration. If > Mobile IPv6 tries to register a new care-of address once it receives > a Link Up indication, Stateless Address Autoconfiguration may not yet > have such a new care-of address configured. The configuration of a > new > care-of address further depends on router and prefix discovery, which > may also be triggered by the same Link Up indication. So there are > plenty of race conditions, and all of them are within the IP layer. > Hum.. You are right. I will change the text. Thank you very much again, Koshiro _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 23 07:17:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxoQ-0005w6-17; Mon, 23 Oct 2006 07:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxoO-0005uT-U0; Mon, 23 Oct 2006 07:17:44 -0400 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbxb7-0000Cg-TW; Mon, 23 Oct 2006 07:04:06 -0400 Received: from e178167002.adsl.alicedsl.de ([85.178.167.2] helo=[192.168.178.25]) by mail1.rz.fhtw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1Gbxau-000CCN-Gz; Mon, 23 Oct 2006 13:03:48 +0200 Message-ID: <453CA23F.5050800@fhtw-berlin.de> Date: Mon, 23 Oct 2006 13:06:39 +0200 From: Thomas C Schmidt User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: mobopts , mipshop@ietf.org, Mip6 , sam@irtf.org, ssm@ietf.org Subject: [Mobopts] New ID: Multicast Mobility in MIPv6: Problem Statement Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi all, we submitted an updated version of the problem statement draft on extending Multicast to Mobility. It should be in the ID directory soon and can immediatly be downloaded under: http://www.realmv6.org/papers/draft-schmidt-mobopts-mmcastv6-ps-01.txt Details: Multicast Mobility in MIPv6: Problem Statement Abstract In this document we discuss mobility extensions to current IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues are summarized. The principal approaches to the multicast mobility problems are outlined subsequently. The new document not only accounts for all comments / reviews given so far, but has been extended significantly to incorporate o Deployment issues; o Current research on the characteristics of multicast routing trees under mobility; o Fairly exhaustive exploration of the solution space; o A large collection of references on various aspects of the subject. As it seems desirable to advance on the subject, we'd like to emphasize solicitation of comments & reviews ... Looking forward to your discussions! See you in San Diego, thomas _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 23 19:11:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8xQ-0005jM-6m; Mon, 23 Oct 2006 19:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc8xP-0005jE-Gu for mobopts@irtf.org; Mon, 23 Oct 2006 19:11:47 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc8xO-0005ep-0E for mobopts@irtf.org; Mon, 23 Oct 2006 19:11:47 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gc8wz-0008Ph-Pj; Tue, 24 Oct 2006 01:11:27 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Gc8wy-0000Bz-K7; Tue, 24 Oct 2006 01:11:20 +0200 Received: from [192.168.2.100] (p54A37CD2.dip.t-dialin.net [84.163.124.210]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3D73CB564; Tue, 24 Oct 2006 01:11:19 +0200 (CEST) Message-ID: <453D4C17.1070005@tm.uka.de> Date: Tue, 24 Oct 2006 01:11:19 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Koshiro MITSUYA Subject: Re: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) References: <4529F0FD.2090907@tm.uka.de> <8D28DFA2-66E9-4590-8C3C-C6B428DF94F2@sfc.wide.ad.jp> In-Reply-To: <8D28DFA2-66E9-4590-8C3C-C6B428DF94F2@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Fumio Teraoka , Mobopts , Kazutaka GOGO , Rie SHIBUI , koki mitani X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Koshiro. Two follow-ups below. >> Section 6.2, Condition >> >> - You may want to state that the conditions provided should be limited >> to those which do not change rapidly for other reasons than the behavior >> of the node implementing L2 abstractions. E.g., another interesting >> link condition might be the access latency for the medium. But the >> access latency may be a function of the number of other nodes competing >> for bandwidth, and hence is a very dynamic condition even if the node >> implementing L2 abstractions does not move and does not change >> communications patterns. It may hence be difficult to implement another >> "access latency" link condition. > > Right. Do you think the state is needed to be more clear? Yes, you could state this more clearly. There is a similar statement in the IEEE 802.21 specification which is that the information provided by Media Independent Information Services is relatively stable and does not change often. See section 6.3.3, Information Service Elements, of version 1.09 of the IEEE 802.21 specification. >> Section 7, Architectural Considerations >> >>> [4] Upper layers should utilize a timely recovery step so as to >>> limit the potential damage from link indications determined to >>> be invalid after they have been acted on. >>> >>> The proposed L3-driven handover described in Appendix D uses >>> the L2-LinkGoingDown indication as the trigger for starting >>> handover. L2-LinkGoingDown is indicated when the link quality >>> goes down below the specific threshold. This indication is not >>> canceled even if the link quality goes up soon. As described >>> above, L2-LinkStatus can be used to detect the most suitable >>> AP. The IP layer can cancel a handover if it finds that the >>> current AP is the most suitable one by using L2-LinkStatus when >>> L2-LingGoingDown is notified. >> >> You could avoid possible issues with anticipatory indications if you >> replaced the Link Going Down indication (which is the only anticipatory >> indication in your draft) by periodic or on-demand link status reports >> which notify an interested upper-layer protocol of link status changes. >> The upper-layer protocol can then make its own projections about when >> the current link attachment will go down due to decreasing signal >> quality. >> >> (Note that an additional use case for the similar Link Going Down >> indication in IEEE 802.21 is for the network to warn a mobile node about >> a forthcoming shutdown of a base station. You don't define >> over-the-network indications in your draft, so you may not actually >> depend on the Link Going Down indication.) > > Sorry, I do not see your point. The Link Going Down indication in IEEE 802.21 is not only used in local cross-layer signaling within a mobile node, but also between the mobile node and the network. This is why IEEE 802.21 requires the Link Going Down indication. But in your case, you do not specify any signaling between a mobile node and the network. So you could replace the Link Going Down indication by periodic or on-demand link status reports which notify an interested upper-layer protocol of link status changes. The advantage of this would be that you eliminate the single anticipatory indication in your proposal. In contrast to Link Going Down indications, simple link status reports don't suggest anything to the mobile node about when to do the next handoff. So they are not anticipatory. It is then the responsibility of the upper-layer protocol do decide when to switch to a different link. Hope this helps. - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Oct 29 08:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeAlo-0006Mk-8F; Sun, 29 Oct 2006 08:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeAld-0006Lk-6S for mobopts@irtf.org; Sun, 29 Oct 2006 08:32:01 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeAlb-000410-TO for mobopts@irtf.org; Sun, 29 Oct 2006 08:32:01 -0500 Received: from [128.96.58.66] (vpntnlA66.research.telcordia.com [128.96.58.66]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id k9TDVvXK000184; Sun, 29 Oct 2006 08:31:57 -0500 (EST) Message-ID: <4544AD4D.9070302@research.telcordia.com> Date: Sun, 29 Oct 2006 08:31:57 -0500 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Mobopts] Revised MPA (Media independent Pre-Authentication) drafts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Colleagues, New version of MPA drafts are now available at the following links. Comments and suggestions are welcome. http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-03.txt http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-implementation-03.txt Regards Ashutosh _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Oct 30 08:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXGO-0006Po-QZ; Mon, 30 Oct 2006 08:33:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXGM-0006Pj-Rw for mobopts@irtf.org; Mon, 30 Oct 2006 08:33:14 -0500 Received: from mail1.rz.fhtw-berlin.de ([141.45.5.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeXGL-0006ch-9B for mobopts@irtf.org; Mon, 30 Oct 2006 08:33:14 -0500 Received: from e178167230.adsl.alicedsl.de ([85.178.167.230] helo=[192.168.178.25]) by mail1.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1GeXGK-000MDK-Am; Mon, 30 Oct 2006 14:33:12 +0100 Message-ID: <4545FFCA.3010303@fhtw-berlin.de> Date: Mon, 30 Oct 2006 14:36:10 +0100 From: Thomas C Schmidt User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Romdhani, Imed" References: <735F04A99D358E468A16EDB64FC04555031C5AAC@EVS1.napier-mail.napier.ac.uk> In-Reply-To: <735F04A99D358E468A16EDB64FC04555031C5AAC@EVS1.napier-mail.napier.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Matthias Waehlisch , mobopts Subject: [Mobopts] Re: Review of Multicast Mobility in MIPv6: Problem Statement X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: schmidt@fhtw-berlin.de List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Imed, many thanks for reviewing the draft. Please see comments inline: Romdhani, Imed wrote: > > I have finished reading your draft and I honestly enjoyed it. It is an > extraordinary work. > Thanks for the flowers :-) > > I identified many points that could be useful to enhance this draft. > > > > From a structural point of view, it will be interesting to re-structure > the whole draft based either on top-down multicast architecture approach > or on communication type basis. In the former point of view, the draft > could be organised into two main sections: > > · One-to-many multicast mobile > > · Many-to-many multicast mobile > Mhmm, not sure what you have in mind: this document is concerned with the problem of mobility extensions for IP-layer multicast. So the idea is to remain close to the established IP-layer multicast architecture and take the perspective from the well known. > > > The multipoint-to-multipoint issue (many-to-many) is not addressed. > However, these kinds of application are promising especially for > collaborative work or distributed applications. The main challenges in > this case will be mainly related to source identification and > authorisation to the multicast delivery tree. > Once again I'm a little unsure what you head at: many-to-many communication is inherent to ASM, in SSM it is mainly concerned with the distribution of the corresponding 'many' source addresses. The latter, though, has not been addressed in the draft as it supposedly resides on the application layer (e.g. Web sites, SIP distribution, ...). There is of course the issue of initially discovering CoA addresses in case of a mobile source. You are right, this should be mentinoned, even though there has been very little work here ... > > > If the draft will be structured based on top-down approach, it could > include the impacts of IP mobility on all multicast layers: from session > description, session announcement, address allocation, to routing and > membership management. While the higher layers issues are not already > well defined and poorly addressed in the literature, IP mobility can > have many restrictions and new extensions are required to handle mobile > devices. For example, the periodicity of announcements could be adapted > or stopped to cope with mobility frequencies, the session description > could include recommendations for nomadic users (to adapt multimedia > coding and framing for example, etc.). > I agree, there are many issues on the application layers related to mobility extensions of IP multicast. This may be added in another release, but would largely extend the document. E.g., if we look at adaptive audio/video coding and its relation to mobility aspects, this would open up a whole new affair: As you might be pointing at, the ITU video coding people are just about to release a Scalable Video Codec (SVC) as an extension to H.264, which is supposed to be capable of dynamically adjust frame resolution and rates to operative conditions (including network performance). Concerning the SDP, there is work to replace SDP ... Maybe we should just add a section pointing to this work - really including relevant details would require extra experts and likely make it unreadable for IP-centric people. > > > As the solutions are concerned, they could be also summarises into two > main sections: > > · Improvements of the Mobile IP protocol: this section can cover > the enhancement of MN and HA features and functions to handle IP > multicast. It will be also interesting to investigate the issues and > solutions for NEMO as a Mobile Router is a particular case of MN. > > · Improvement and adaptation of the multicast infrastructure: > improvement of router behaviour, router discovery, multicast control, > multicast membership, etc. > We partly tried to follow this in differentiating approaches, which solely modify MIPv6 entities or agents from those, modifying the routing protocols ... however, it appears tempting to us to stick in the solution section to the structure of the problem section ... hope is to make it easier to match problems and approaches. You are right with NEMO - we skipped this ... and feel unsure about its relevance to the draft. There are recent discussions regarding MIPv6 : NEMO in the unicast case, though. > > > Finally, I believe that this draft has omitted to mention some issue > that I would like to summarise in the following points (they could be > integrated in Section 4.2): > > · Membership issue for mobile parties: the periodicity of > IGMP/MLD problem has to be slowed down to prevent extra power and > process consumption. Queries are no more broadcasted to ALL-nodes, but > encapsulated to specific unicast address (Home subscription approach), > therefore the HA is aware that there is a unique member at tunnel > end-point. > Yes, this we omitted. Should be subject to an updated version. > · Routing issue: even with the Home Subscription approach, a > mobile receiver can still suffer from triangle routing issue especially > when the HA is not optimally located. It will be recommended to > “relocate” the HA to Edge (boundary) of the home network to forward IP > multicast packet before they cross the whole network (from ingress to > access levels, and then from access level to egress level) > Yes, Home Subscrition (or bi-directional tunneling, as we call it) usually leads to triangular routing. Also, we are aware of some work to 'multiply' Home Agents, mainly to achieve load balancing and fault tolerance. But you're right, we skipped your proposal to use the multiple HAs for agent assisted multicast tree geometry ... it appears somewhat similar to the (M)-HMIPv6 approach, probably with the distinction that MAPs are 'fixed' w.r.t. the local subnet and temporary with the MN, while the HA hierarchy is 'fixed' w.r.t. the MN, but only 'near' to the visited subnet. We should add this in the next version. > · Binding Updates issue: solutions that introduce a notification > mechanism using Binding Updates between SSM and mobile receivers broke a > basic rule of IP multicast: the source has not to know the exact > identity of receivers. In addition, the Return Routability has to be > clarified if it is used. > In SSM the issues arising from source filtering have to be somehow addressed. All the approaches we know about do this by either masking the CoA or by using some update scheme (Thaler, I believe, was the first proposal here). These updates, however, are usually not individually directed to multicast group members, i.e. no registration & bookkeeping at the source is required, but are done via established multicast trees (HA-based control tree by Thaler, SDR by Jelger & Noel, the previous delivery tree in the Tree Morphing). My personal believe is, that return routability cannot be used in the multicast case. Multicast secure updates need to be one-way, thus requiring cryptographic identifiers (s. work of Gab Montenegro). But you are right: None of the authors have detailed out such a security layer, as far as we know. > · Mobile IPv4 and Mobile IPv6 inherit the same issues except > that they are using different architectural entities. > ... and except that MIPv6 is capable of the address masking and thereby of route optimisation ... > > > I will enjoy discussing these points with you. Please feel free to > correct me if you believe that I am wrong. > Thanks Imed, same goes for us: the field is a little intricate ... so it is worth re-thinking and discussing issues. We still don't know wether there is a simple and elegant solution, simultaneous complying to all requirements and desires ;) Cheers, thomas > -- > > ° Prof. Dr. Thomas Schmidt > > ° HAW Hamburg, Dept. E & I > > ° University of Applied Sciences > > ° Berliner Tor 7, D 20099 Hamburg > > ° Germany > > ° Fon: +49-40-42875-8157 > > ° http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Oct 31 02:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Genc7-0001Qe-OM; Tue, 31 Oct 2006 02:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Genc4-0001QV-W6 for mobopts@irtf.org; Tue, 31 Oct 2006 02:00:45 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Genbw-0003dW-FE for mobopts@irtf.org; Tue, 31 Oct 2006 02:00:44 -0500 Received: from [192.168.1.11] (p1181-ipbf412funabasi.chiba.ocn.ne.jp [122.16.247.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A08D34D8CB; Tue, 31 Oct 2006 16:00:15 +0900 (JST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8411209E-2347-42E8-B839-A9BE14F1B1CC@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Subject: Re: [Mobopts] RG last call Date: Tue, 31 Oct 2006 16:01:15 +0900 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Koshiro MITSUYA , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Jukka, I am sorry for the delayed reply. Please find my comment inline: On 2006/10/20, at 17:17, Jukka MJ Manner wrote: > > Hi all, > > I promised Rajeev to give a review of the draft, so here goes. Thank you! > In overall, I liked the document. Yet, I would remove all the sections > (Appendix B.3 and D) that discuss the experiments, since those are > difficult to verify, and do not really provide any important > information, > just that the scheme seems to work in some use case. > We thought these appendixes will help reader to understand our proposal. However, I agree with you. I will remove. > Some more detailed comments: > > - Section 3 does not really discuss the Response primitive. In > general, > what is the use of the Response? Why would L3 really need to > acknowledge > an asynchronous Indication from L2? I do not see any strong reason now, but I would keep the Response for future usage. One of our architectural feature is that all message (command and indication) go through the same inter-layer communication method. It is possible to e.g. accept the handover command after receiving the response of ToBeDown indication. > - Section 4: > > * is the proposal only for so-called Managed Mode (AP mode) > link layers? How would this be applicable to ad-hoc or mesh > radios? > E.g., would L2-PeerList provide info about only L2 APs, but > also other > terminals? Would L2-LinkUp/Down tell which links to other ad- > hoc nodes > are up/down? Some primitives may work on ad-hoc mode. However, ad-hoc mode or mesh is out of scope so far. If WG requests, we can work on the study. > * How do channels come into play? Does the L2-PeerList allow getting > peers on different channels? Can L3 somehow control the use of > channels? > Yes, L2-PeerList allow to get peers on different channels. However, L3-* do not need to play with channels. L3 specify a Peer, and L2 understand which channel the Peer is using. > * After reading the whole spec, you actually later talk about > quality of > the signal in relation to the L2-PeerFound, i.e., only certain > peers > are told about to L3. That is not mentioned in Section 4. Sorry, I don't see your point. > * Related to the above, and other requests, would there be a need to > define some filters about which notifications are of interest? > E.g. > the above, a peer is announced only if the quality of the link > to the > peer is of some relative quality. Same here. Could you explain explain more? > * L2-PeerLost: provide info about which peers disappeared, but since > when? Does L2 e.g. send a notification every second, and tell > which > peers disappeared within the past second? Or everytime there is > even a > one peer change in the list? We assume that L2 creates and maintains a list of APs when it performs scanning. When It performs scanning again, the comparing is performed and a notification is sent if needed. The timing of scanning is implementation issues. > * Is there any need to add some kind of security awareness to the > primitives, i.e., is the link secure or not (how secure?)? > E.g., to > the link status primitive, or to a filter associated to the > PeerFound? I would hear the WG voice :) > - Section 6.2 Condition: should the SNR be also provided? What is this > "available bandwidth? If we talk about 802.11, if the link layer > says I > have full 54 Mbps connectivity, everybody knows that is about > half the > actual bandwidth I get for my IP packets. It is out of scope in our spec. Such information is very useful for transport or application, but not so useful for L3. > - Section 7: > * [2]: As above, why is the Response needed in the first place? see above. > * [5]: You don't need congestion control in the transport, but you > surely need rate limitation for how often indications are > sent > from L2 to L3. > Good point. I will add a text to mention this. > - Appendix A, p.20, 2nd sentence: I think the L2 and L3 are mixed: "L2 > handover begins after the L2 sends L2-LinkConnect.confirm to the > L3." > > > - C.4: "is got lost" > > - C.6: "...frame to the AP, or the" > "...frame to the AP, and the" ? > > - C.7: "...and becomes under" > "...and falls unders"? > Thank you. I will fix them! regards, Koshiro > > Hope these comments help. > > Regards, > Jukka > > On Tue, 3 Oct 2006, Rajeev Koodli wrote: > >> >> Folks, >> >> This is the last call for comments on >> >> draft-irtf-mobopts-l2-abstractions-01.txt >> >> The last call expires on October 20, 06. >> >> Please provide your input by then. >> >> Thanks, >> >> -Rajeev >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Oct 31 02:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Genpo-0008Kw-4D; Tue, 31 Oct 2006 02:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Genpm-0008Kr-Ge for mobopts@irtf.org; Tue, 31 Oct 2006 02:14:54 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Genpk-0006zf-Cn for mobopts@irtf.org; Tue, 31 Oct 2006 02:14:54 -0500 Received: from [192.168.1.11] (p1181-ipbf412funabasi.chiba.ocn.ne.jp [122.16.247.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 608A54D8B6; Tue, 31 Oct 2006 16:14:51 +0900 (JST) In-Reply-To: <453D4C17.1070005@tm.uka.de> References: <4529F0FD.2090907@tm.uka.de> <8D28DFA2-66E9-4590-8C3C-C6B428DF94F2@sfc.wide.ad.jp> <453D4C17.1070005@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Subject: Re: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call) Date: Tue, 31 Oct 2006 16:15:51 +0900 To: Christian Vogt X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Fumio Teraoka , Rie SHIBUI , Koshiro MITSUYA , koki mitani , Kazutaka GOGO , Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Thank you for you reply. Please find my comment inline: [snip] >> Right. Do you think the state is needed to be more clear? > > Yes, you could state this more clearly. There is a similar > statement in the IEEE 802.21 specification which is that the > information provided by Media Independent Information Services is > relatively stable and does not change often. See section 6.3.3, > Information Service Elements, of version 1.09 of the IEEE 802.21 > specification. OK. Thank you for the information. > The Link Going Down indication in IEEE 802.21 is not only used in > local cross-layer signaling within a mobile node, but also between > the mobile node and the network. This is why IEEE 802.21 requires > the Link Going Down indication. > > But in your case, you do not specify any signaling between a mobile > node and the network. So you could replace the Link Going Down > indication by periodic or on-demand link status reports which > notify an interested upper-layer protocol of link status changes. > The advantage of this would be that you eliminate the single > anticipatory indication in your proposal. > > In contrast to Link Going Down indications, simple link status > reports don't suggest anything to the mobile node about when to do > the next handoff. So they are not anticipatory. It is then the > responsibility of the upper-layer protocol do decide when to switch > to a different link. > OK, I see you point. We have such on-demand link status report by L2-LinkStatus. And the LinkGoingDown is also needed to let several entities behave in the same way. regards, Koshiro > > > Hope this helps. > > - Christian > > -- > Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) > www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Oct 31 18:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2tt-0002Kj-1L; Tue, 31 Oct 2006 18:20:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2tr-0002Js-1V for mobopts@irtf.org; Tue, 31 Oct 2006 18:20:07 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf2tp-0005ee-Ik for mobopts@irtf.org; Tue, 31 Oct 2006 18:20:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9VNK1d8027668 for ; Wed, 1 Nov 2006 01:20:04 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 01:18:52 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 17:18:50 -0600 Received: from 10.241.59.53 ([10.241.59.53]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Oct 2006 23:18:50 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 31 Oct 2006 15:18:58 -0800 From: Rajeev Koodli To: Message-ID: Thread-Topic: Agenda for San Diego meeting Thread-Index: Acb9QvEFL1kbEmk2Edu6ywAWy5YJpw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 23:18:50.0303 (UTC) FILETIME=[EC6F64F0:01C6FD42] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061101012004-68E6BBB0-59249A8E/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Mobopts] Agenda for San Diego meeting X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, Here it is.. -Rajeev Tuesday, November 7, 2006 1520-1720 Afternoon Session II Spinnaker IRTF mobopts IP Mobility Optimizations Research Group Intro, RG status, Rajeev 5 min Gap analysis between draft-irtf-l2-abstraction and 802.11 draft, and Summary of RG review, Koshiro Mitsuya Time: 20 min "Multicast Mobility in MIPv6: Problem Statement - update" Time: 20 min Document: draft-schmidt-mobopts-mmcastv6-ps-01.txt Policy and mobility, Jouni Korhonen Time: 15 minutes Document: not available yet Mobile IPv6 Location Privacy Solution Update, Qiu Ying Time: 10 min Document: draft-irtf-mobopts-location-privacy-solutions-04.txt Title: CN-Targeted Location Privacy and Optimized Routing for Mobile IPv6, Kilian Weniger Time: 20 min Document: draft-weniger-mobopts-mip6-cnlocpriv-00 (under way) Title: Media Independent Pre-authentication (MPA), Ashutosh Dutta Time: 20 mins Document: draft-ohba-mobopts-mpa-implementation-03.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts