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

Daniel Park <soohong.park@samsung.com> Wed, 11 July 2007 11:44 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8acF-0005u3-Q6; Wed, 11 Jul 2007 07:44:19 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1I8acD-0005td-QD for 16ng-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 07:44:17 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8acD-0005pu-9h; Wed, 11 Jul 2007 07:44:17 -0400
Received: from mailout1.samsung.com ([203.254.224.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8abx-0005rA-Fg; Wed, 11 Jul 2007 07:44:17 -0400
Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JL000474J8DQ2@mailout1.samsung.com>; Wed, 11 Jul 2007 20:43:25 +0900 (KST)
Received: from ep_spt03 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JL000FNMJ8FPG@ms7.samsung.com>; Wed, 11 Jul 2007 20:43:27 +0900 (KST)
Content-return: prohibited
Date: Wed, 11 Jul 2007 11:43:27 +0000 (GMT)
From: Daniel Park <soohong.park@samsung.com>
To: mipshop@ietf.org, 16ng@ietf.org
Message-id: <0JL000FNNJ8FPG@ms7.samsung.com>
MIME-version: 1.0
MIME-version: 1.0
X-Priority: 3
Msgkey: 20070711114327478@soohong.park
X-MTR: 20070711114327478@soohong.park
X-EPLocale: ko_KR.windows-1252
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale:
X-Generator: NamoMIME 6.0.0.3
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd
Cc:
Subject: [16NG] Fwd: Re: Call for Review on FMIP6 over IEEE802.16e
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: soohong.park@samsung.com
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1226367779=="
Errors-To: 16ng-bounces@ietf.org

Samsung Enterprise Portal mySingle

Thanks Jonne for your good review.

 

Hope this helps.

 

Daniel Park [at] SAMSUNG Electronics.



------- Original Message -------
Sender : Soininen Jonne (NSN FI/Espoo)<jonne.soininen@nsn.com> jonne.soininen@nsn.com
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.

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... ;)

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.

3) 2.  Terminology:   "We also referred to [5]." - I'm not quite sure what
this sentence means. Perhaps it needs rephrasing.

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 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.

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

"   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.


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.

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?

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.

8) 7.1.  Predictive Mode

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


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.
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng