[Mobopts] Re: Comments on draft-irtf-mobopts-mpa-framework-00.txt
Ashutosh Dutta <adutta@research.telcordia.com> Mon, 19 November 2007 20:35 UTC
Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDLQ-00082T-HG; Mon, 19 Nov 2007 15:35:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDLP-00082A-P6 for mobopts@irtf.org; Mon, 19 Nov 2007 15:35:47 -0500
Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDLM-0002Ws-Rx for mobopts@irtf.org; Mon, 19 Nov 2007 15:35:47 -0500
Received: from [128.96.58.178] (vpntnlA178.research.telcordia.com [128.96.58.178]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id lAJKZhB1022526; Mon, 19 Nov 2007 15:35:43 -0500 (EST)
Message-ID: <4741F3A0.20505@research.telcordia.com>
Date: Mon, 19 Nov 2007 15:35:44 -0500
From: Ashutosh Dutta <adutta@research.telcordia.com>
User-Agent: Thunderbird 1.5.0.13 (Windows/20070809)
MIME-Version: 1.0
To: Marco Liebsch <marco.liebsch@nw.neclab.eu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129
Cc: "mobopts@irtf.org" <mobopts@irtf.org>
Subject: [Mobopts] Re: Comments on draft-irtf-mobopts-mpa-framework-00.txt
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org
Hi Marco, Appreciate your review and useful feedback and comments on draft-irtf-mobopts-mpa-framework-00.txt. Please see inline for the answers to your questions and comments. We have taken care of many of the comments in the revised version (draft-irtf-mobopts-mpa-framework-01.txt) of the draft that we submitted recently. I am sending it to the MOBOPTS mailing list for further discussion. Regards Ashutosh Marco Liebsch wrote: > Hi Ashutosh, > > please find attached some quick and initial comments, which you > may consider as general comments and some editorial comments. > > Maybe some of my general comments are due to misunderstanding > or because I did not dig into this work beforehand. I could > not look at all thinks in detail so far, but maybe you find > some comments useful for the discussion. > > See you in Vancouver, > > marco ************************************************************************** Comments to Media-Independent Pre-Authentication Framework for Inter-Domain Handover Optimization, draft-irtf-mobopts-mpa-framework-00.txt General: ======== 2. Inter-domain Handover 3rd paragraph, last sentence: "...change its L3 identifier depending upon..." I don't think the *identifier* changes here, but the *locator*. At least for Mobile IP-like protocols. I guess the same is valid for SIP, where name@realm is the ID, whereas its registered IP address serves as locator. => Identifier changed to locator in the respective places Figure 1: Figure should look simpler. You use many specific functional components in the drawing without explaining them in the text. I propose to reduce them and keep most relevant ones for this general description. This could be the AAAH and the AAAF (or AAAV). AA is not important here to get the point (?). The few key components should be summarized in the text of section 2. Most of these components come back later in Figure 2 anyhow (AA, etc.) => Added the descriptions of AAAv, AAAH, AA, AR etc. briefly to this section to describe the components of Figure 1. 6.3 Basic Communication FLow Comment to Step 3: "...by executing the binding update operation..." In Mobile IP(v6) sending a binding update is usually triggered by reception of an on-link router advertisement or agent advertisement and subsequent configuration of a routable IP address at the interface. These will not be advertised on the established tunnel by default (and the tunnel is set up only 'after' the address has been configured, right?) => This is a good point. In MIPv6, binding update is dependent on receipt of on-link router advertisement. Thus, the mobile needs to detect the on-link router advertisement from the NAR tunneled through the transient tunnel before the proactive binding update could be sent out from the mobile. We have added a mechanism to send the RA tunneled through the transient tunnel, so that the mobile can send the proactive binding update based on the receipt of the router advertisement. Also the mobile must be modified to distinguish 'local' IP address configuration and 'remote' IP address configuration. This requires modification of hosts and protocols for MM, Address configuration. Is all this supported by an MPA-enabled MN? If modification of Mobile IP is required, it's not really agnostic/independent to the mobility management protocol, which I understand is one of the design goals. However, for a framework is should be ok as it is. => There is no need to change the mobility protocols, as such. Thus, modification of Mobile IP is not required either. But the host may need some modification, so that it can interact properly with the mobility protocols, such as Mobile IP or SIP while performing the required optimization functions. End host may need additional software to interact with mobility protocols and perform other related MPA related functions. 7.4 Address resolution I would not say DAD is part of address resolution but address configuration. I see this rather located in 7.3. But DAD for stateless address configuration is not considered, is it? As long as there is no tunnel to the target subnet in the CTN, it's difficult to perform DAD with the NDP. => DAD part has been moved to Section 7.3. Clarified few steps with respect to DAD operation for stateless auto-configuration. 7.7.2 Preventing packet loss for multiple interfaces Why is pre-authentication through the previous interface required here? The new interface can be powered and attached while the previous one maintains the session? That's one advantage of multi-mode terminals. Or did I misunderstand something here? => As mentioned elsewhere in the document, applicability of MPA is more compelling for single interface case. However, in case of multiple interface case, use of previous interface to perform certain MPA related operations is desirable for scenarios, such as 1) Saving battery power 2) In case of non-overlapping access or sudden disconnection 3. In case the carrier does not support simultaneous use of multiple interfaces. Authentication and attach to CDMA network via WLAN seems difficult, as techno/System specific IDs (e.g. IMEI, IMSI) are used and temporary IDs will be assigned (TMSI). But I must admit, that this of course depends on how efficient an AA and CA can be integrated with a CDMA-based target network and how powerful the protocol interface between MN and AA/CA is. => In case of multi access networks, for some types of target access networks, not all the steps of MPA could be possible. It could just perform pre-authentication vs. combination of pre-authentication and preconfiguration, or all the steps mentioned in Section 6. In a typical WiFi-CDMA handoff operation, some of the PPP context can be set up ahead of time by using WiFi interface. general comment: tunneling data between two ARs belonging to different domains can imply quite some delay in case such packets traverse always the top gateway router of the domain. I am wondering if the proactive tunnel brings always the expected performance gain compared to MM-tailored solutions. => MPA uses a transient tunnel between NAR and the mobile in PoA. It is true that, in case of inter-domain handoff, these entities could be far-off logically. Thus, the signaling and data during pre-authentication period will take a longer route, and thus, may be subjected to longer one-way-delay. Thus, it is a tradeoff between larger packet loss or larger one-way-packet delay for a transient period, when the mobile is preparing to handoff. summary: Very good work! Lot of things have been considered, such as different means for address acquisition, etc. Individual protocol components and needs have been evaluated thoroughly. To make an MPA framework for handover working in a particular system, I expect major modifications to existing components, such as address configuration, MM, local routing table management on MNs. => Since MPA framework is supposed to provide helper techniques to optimize the existing mobility management protocols, certain changes/modifications are needed on the mobile and router based on what part of MPA procedures are used inter-domain handoff. Editorial: ========== 1.1 Performance Requirements last paragraph repeats what's aid already above already (ITU delay bounds). Looks redundant and can be merged. =>Merged 2. Inter-domain Handover 4th paragraph: "...will be sujected..." -> "...will be subjected..." (?) => changed 3. Existing work on Fast Handover Minor comment on the first paragraph: MM protocols don't suffer from handover delay, rather applications and performance do. MM works even with large handover latency. => rephrased "...propose a scheme reduces the delay..." -> "...propose a scheme that/which reduces the delay..." => Fixed 4. Applicability of MPA first paragraph mentions the 'CTN'. You should introduce abbreviations first before using them. Just write Candidate Target Network (CTN). Later you explain it anyhow in section 5. => Description of CTN added 6.1 Overview "...CTN as well as a execute tunnel..." -> "...CTN as well as execute a tunnel..." "...before attaching to the the target..." -> "...before attaching to the target..." => typos fixed 6.2 Functional Elements "...in one more network devices..." -> "...in one or more network devices..." => Fixed 6.3 [page 20] last sentense CH -> CN => Fixed _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] Re: Comments on draft-irtf-mobopts-mpa-… Ashutosh Dutta