RE: [802.21] Tomorrow's Telecon material
Hi Soohong,
This message has slipped out of my inbox somehow for which I apologize.
Your comments are addressed below. Most comments were already
incorporated into the draft.
Regards,
Srini
>-----Original Message-----
>From: ext Soohong Daniel Park [mailto:soohong.park@SAMSUNG.COM]
>Sent: Wednesday, February 22, 2006 11:12 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] Tomorrow's Telecon material
>
>Ok, let me give some of comments on that first, then we will
>talk about further details during teleconf.
>
>Comments are inline with [daniel]
>
>Daniel (Soohong Daniel Park)
>Mobile Convergence Laboratory, SAMSUNG Electronics.
>
>
>---------------------------------------------------------------
>-----------------
>
>[daniel] "if available, pls use an xml2rfc format to compile a
>document, it would be very readable for folks."
>
>
> Media independent Information Service (MIIS) and Its Higher
> Layer Transport Requirements
>
><snipped>
>
>Abstract
>
> Media Independent Information Service (MIS) Information
>Services provides a framework by which a MIH (Media
>Independent Handover) function both in the mobile node and in
>the network can discover and obtain network information (both
>homogeneous and heterogeneous) within a geographical region to
>facilitate handovers.
>MIS includes support for various Information Elements (IEs).
>These IEs provide information that is essential for a handover
>function to make intelligent handover decision.
>The MIH function in a mobile node or network can obtain such
>network information (e.g., IEs) via both lower as well as
>higher layers.
>
>[daniel] "s/MIS/MIIS"
Srini> For the benefit of others, this is a vi editor command for search
and replace. MIS term is used consistently in the internet-draft. But I
don't have problems to change to MIIS.
>
> This document is an effort to describe use cases and
>requirements for higher layers Information Service while the
>information is transported over IP and above layers.
>
>[daniel] "as you wrote above, we can use both signal as lower
>layer and higher layer, and obviously this document is just
>focusing on higher layer. However, I encourage you to explain
>why lower layer signal (MIH format) is not suitable for legacy
>internet architecture. I think it can be described in
>Introduction section in brief. Without this concern, it can
>cause some of misunderstanding for IETF folks why existing
>lower layer signal is not useful, and why a new higher layer
>signal should be designed in IETF..."
>
Srini> okay, I see your point. But do you really think IETF would be
interested to know why a MAC protocol would not be sufficient for
transport? It is simply because the MIH capable nodes could be beyond a
subnet. I could check in the problem-statement draft to make this
statement explicit in the introductory sections, since it is applicable
to all MIH services.
>1. Introduction
>
>[daniel] " Bofore jumping to illustrating MIHS stuff, I
>encourage you to add some of general text, why 802.21 is
>needed in terms of mobility / what's trend of mobility / and
>related something for easy understanding of non-802.21 guys."
Srini> Okay, we can add more information on IP mobility aspects.
> Media Independent Handover Services are a class of network services,
> which aim to improve the quality of handovers available to mobile
> devices. In order to support more intelligent handover services it
> is often necessary to be able to exchange information between mobile
> and fixed nodes within the network.
>
> IEEE 802.21 working group is currently defining three broad
>classes of
> such services to facilitate the handover. They require passing of
> information within hosts, as well as between them:
>
>1.1 Media Independent Event Services (MIES) provide
>indications from lower layers about changes in the
>connectivity state [802.21 draft].
>Events are of two kinds: local and remote. In case of local
>events, information typically propagate upwards from L2 to MIH
>function and MIH function to upper layers within a local
>stack. In case of remote events, however, information may
>propagate from MIH or upper layers in one stack to MIH or
>upper layers in another stack.
>
>1.2 Media Independent Command Services (MICS) provide
>mechanisms for Controlling handovers [802.21 draft]. It
>includes the commands from upper layer to MIH and from MIH to
>lower layer. These commands mainly carry the upper layer
>decisions to the lower layers.
>
>1.3 Media Independent Information Service (MIIS) Information
>Services provides a framework by which a MIHF (Media
>Independent Handover Function) both in the mobile node and in
>the network can discover and obtain homogeneous and
>heterogeneous network information within a geographical region
>to facilitate handovers [802.21 draft]. MIIS includes support
>for various Information Elements (IEs). These IEs provide
>information that is essential for a handover function to make
>intelligent handover decision. The information can be made
>available via both lower as well as higher layers.
>
>
><snipped>
>
>
> /--------\
> / \
> ------ -------- -------- /----/ -------- \----\
> | IS | | |-----| |---/ | | \
> |Client|<-------------------------------------->| IS | \
> | | | | | | \ |Server| /
> -------\ -------- -------- \ -------- /
> Host \ Access Router \----\ /----/
> \ Point / \ /
> \ -------- -------- / \--------/
> \ | |-----| | / Core
> \ | | | |-------/ Network
> \| | | |
> -------- --------
> Access Router
> Point
> Visited Network
>
> Figure 3: IS-Server In the Network
>
>[daniel] "s/Figure 3/Figure 4"
Srini> corrected.
>
>
>
>
>
> /--------\
> / \
> ----- -------- -------- /----/ \----\
> | IS | | |-----| |---/ | ---- | \
> |Client|<---------------------------------------> IS | \
> | | | | | | \ |Server| /
> ----- -------- -------- \ -------- /
> Host \ Access Router \----\ /----/
> \ Point \ /
> \ \--------/
> \ | Core
> \ | Network
> \ |
> \ |
> \ /--------\
> \ / \
> \-------- -------- /---/ \----\
> | |-----| |---/ |-------| \
> | | | | | IS | \
> | | | |---\ | Server| /
> -------- -------- \ | Server| /
> Access Router \---\ /----/
> Point \ /
> \-------/
>
> Visited Network Core
> Network
>
> Figure 4: IS-Server In the Network
>
>[daniel] "s/Figure 4/Figure 5"
>
Srini> corrected
><snipped>
>
>
>3.4 Congestion Control Issues
>
>Transport protocol like TCP has congestion control mechanism
>and therefore in such cases this is a non issue. Where
>existing transport protocols do not incorporate their own
>congestion control and rate limitation, basic mechanisms for
>network protection and congestion recovery may need to be
>added to the IS application protocols.
>
>[daniel] "Unclear, is there any congestion issue in terms of
>of MIIS ? It is entirely up to transport protocol such as
>TCP/DCCP/etc...not to be resolved by higher IS protoco.
>Are you supposed to replace existing congestion control
>mechanisms with IS protocol ?
>It seems too much complex and not reasonable apporoach to me. "
Srini> no, that is not the intention. The discussion to indicate that
the congestion control aspects have to considered for any protocol
development in Internet.
>
>The choice of transport mechanism should work with both IPv4
>and IPv6 networks.
>
>[daniel] "Note: this document does not consider IPv4/IPv6
>combined networks. In order words, There is no guarantee IPv4
>(or IPv6) mobile node to communicate with IS server located in
>IPv6 (or IPv4) networks."
Srini> We have not asked for this requirement. I think at some point we
discussed that there may be no compatibility in the IP mobility
mechanisms between IPv6 and IPv4 so the info services across IP types
may not be useful.
>
>MIIS defines the IE and MIH protocol formats that are
>processed by only MIHF peer entities.
>Any changes to these formats and fields MUST not require
>modifying the underlying security
>mechanisms in future.
>
>[daniel] "some requirements seem reasonable at least to me.
>
Srini> ok
> 5. Security Considerations
>
>[daniel] " this section can refer to the 3.5 Security Issues "
>
Srini> The issues section were a repetition and hence removed.
>
>6. Acknowledgement
>
>
>
>
>
>
>
>
>
>