Re: [16NG] Fwd: Re: Call for Review on FMIP6 over IEEE802.16e

[Heejin Jang <[e-mail]>]

Hi, Jonne.

Thanks for your opinion and comments. :)

The authors will revise the document based on your feedback
and send it separately to you next week. 

Kindly see my inline answer.

-Best Regards, 
Heejin.

--------------------------------------------------------------------------------
From: Daniel Park [mailto:[e-mail]] 
Sent: Wednesday, July 11, 2007 8:43 PM
To: [e-mail]; [e-mail]
Subject: [Mipshop] Fwd: Re: Call for Review on FMIP6 over IEEE802.16e


Thanks Jonne for your good review.

Hope this helps.

Daniel Park [at] SAMSUNG Electronics.

------- Original Message -------
Sender : Soininen Jonne (NSN FI/Espoo)<[e-mail]> [e-mail]
Date : 2007-07-11 19:41
Title : Re: Call for Review on FMIP6 over IEEE802.16e

I have a bit of a negative meta-comment to start with. It seems that the doc 
is intended for Informational status, and it is written in an informational 
way. I would strongly propose to publish this as a conference paper in some 
conference, rather than in the IETF. There are no inter-working or 
compatibility implications of _not_ publishing this as an RFC. As the 
document just shows an example of how Fmip could be used in different 
802.16e networks, I'm not sure this is really necessary for the IETF to have 
it. I would at least like to know a bit more why this is needed to be 
published via the IETF. 
 
Heejin>> The goal of this document is to provide developers with 
implementation guideline so that they provide products which can 
realize seamless handover in the 802.16 networks.

For this, the proposed document did as follows.

1> Among primitives proposed by IEEE 802.21, we selected a set of 
   primitives which can be cooperated with 802.16 handover messages for
   efficient FMIPv6 operation, and provided the most appropriate trigger 
   timing of each of selected primitives during 802.16 handover procedure. 
   
2> Provide a way to make a mobile node to operate in predictive mode
   as long as possible by using L3-driven handover (with a Handover_Commit
   command)
   
3> Introduce the recommended handover scenarios through L2(802.16) 
   & L3(FMIPv6) interaction based on IEEE 802.21 primitives.

The authors think that this proposal provides practically helpful information
to vendors involved in 802.16 or WiMAX system implementation, and it was 
also proven by acceptance of IEEE Network Magazine. 

That said, I read the draft and I provide here some comments. They are 
mostly editorial as my understanding of 802.16e is not on the level where I 
could study in detail the technical concepts. 

Detailed comments: 

1) I'm not that good in English, but the following captured my eye: 
Abstract 

   This document describes how a Mobile IPv6 Fast Handover could be 
S/could/can - I think can is a bit firmer than could... ;)  

Heejin>> Ok. 

2) 1.  Introduction: The introduction describes or summarizes what the 
document will describe. However, I think some hint to towards what this 
document is good for, and why and how the reader should read this document - 
is this document intended for people implementing 802.16e network as an 
implementation guideline, or is this a general idea, or what this document 
is. I think that would help the reader a great deal. 
 
Heejin>> Ok. This is also relative comment with 1). 
We will clarify the aim and advantages of proposal in the introduction.

3) 2.  Terminology:   "We also referred to [5]." - I'm not quite sure what 
this sentence means. Perhaps it needs rephrasing. 
 
Heejin>> Ok. We will move the sentence to the introduction section and 
rephrase it with more explanation.
  
4) 3.  Deployment Architectures for Mobility on IEEE 802.16e 

" The FMIPv6 is a kind of IP mobility solution, so needs to be performed 
when a mobile node (MN) handovers across the subnet. 
Regarding its specific operation, the FBU (Fast Binding Update) 
   message is sent conditionally depending on whether the target BS is 
   under different subnet or not.  The information may be available to 
   the MN before handover through the link-layer technology or 
   implementation-specific method.  This document describes the case 
   when an MN handovers across the subnet." 

I don't know how this paragraph relates to rest of the section 3. It 
seems to be a general notion about FMIPv6, but the connection of the 
paragraph to the rest of the section should be improved. In addition, at 
least there may be room for rephrasing in the first sentence. 
 
Heejin>> This paragraph was removed in the latest version (fh80216e-02.txt)
based on 16ng discussion result and comments of other reviewers.

5) 4.  IEEE 802.16e Handovers Overview 
S/handovers/handover 

Heejin>> Ok.

"   Compared with the handover in the wireless LAN, the 802.16e handover 
   mechanism consists of more steps since 802.16e embraces the 
   functionality for elaborate parameter adjustment and procedural 
   flexibility." 
   
Sounds a bit like marketing.... ;) I wonder if the comparison is needed. It 
is clear that 802.16e is quite a bit different from 802.11 and has much more 
ellaborate mobility mechanisms. 

"  When the MN 
   sets the target BS finally and is about to move to the link, it sends 
   MOB_HO-IND to the serving BS as a final indication for handover and 
   for resource release, then conducting handover." 

Maybe this could be rephrased for clarity. 
 
Heejin>> Ok. We will mention that.

6) 5.  Network Topology Acquisition and Cell Selection 

I guess this section explains, how cell selection works in 802.16e and is 
intended for background. Perhaps the fact that this is 802.16e functionality 
and not new functionality defined in this draft should be explicitly 
mentioned. 
 
Heejin>> Ok. 

7) 6.3.  Handover Execution 
" On completion of the network entry procedure, 
   according to WiMAX model, the initial service flow (ISF) for IPv6 CS 
   needs to be established by the network.  ISF is the first flow of the 
   pre-provisioned service before carrying the data packets.  For more 
   detailed description, refer to [9].  After that, the MN's link layer 
   informs its IP layer of the fact with Link_Up (LUP) trigger, forcing 
   IP layer to send FNA (Fast Neighbor Advertisement) to the NAR (New 
   AR).  In case of reactive mode, the MN should include the FBU within 
   the FNA message." 

This got me a bit confused. After discussing (and being the document for) 
general usage of FMIPv6 for 802.16e, here the document starts to refer to 
Wimax specification. Wimax is an architecture specified for 802.16e radio 
with its specific procedures, and its specific architecture. If I remember 
correctly, there is no FMIPv6 in Wimax currently - thus, I'm not sure what 
the paper is trying to propose: The possible interactions of 802.16e and 
FMIPv6 or something new for Wimax? 

Heejin>> We referred to [9] in order to give a specific example about 
the proper trigger timing of a Link_UP in case of WiMAX which is practical 
standard defined by WiMAX vendors. The paragraph seems to be re-writed 
for clear context, and we'll mention the WiMAX-relative texts as an example 
specifically only for WiMAX networks.

In addition, I cannot remember if [9] is a public specification. If it isn't 
it might be a bit hard to point to it from an IETF document. 
 
Heejin>> The [9] is not a final standard of Wimax NWG yet, but will be. 
We think that its reference will be helpful for a specific example in WiMAX
network though it's an on-going document.


8) 7.1.  Predictive Mode 

Purely Editorial: I would put the signaling flow in front of the 
explanation. I find it a bit easier to read.  

Heejin>>  Ok. 
 
So, once again, the editorial things can be clarified easily. However, I 
would like to understand what is the point and target of this work, and what 
is the intended outcome. 

Cheers, 

Jonne.

Heejin>> Thanks for your through review again. :)

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng