RE: [802.21] Tomorrow's Telecon material
Hi Ajoy,
I would need your help to provide a two line summary for background.
Also please indicate what text you want to replace.
Regards,
Srini
>-----Original Message-----
>From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@MOTOROLA.COM]
>Sent: Thursday, March 09, 2006 5:32 PM
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: Re: [802.21] Tomorrow's Telecon material
>
>Hi Srini,
>
>I think the section 4 of IS service draft does not correctly
>portray the capability of card IS service. I would suggest
>please go through the contribution that we submitted during
>Jan meeting and then make necessary update to the draft.
>
>Phttp://www.ieee802.org/21/jan06_meeting_docs/21-06-0470-00-000
>0-CARD_Pr
>otocol_for_IS.doc
>
>
>Regards,
>Ajoy
>
>
>-----Original Message-----
>From: Srinivas Sreemanthula [mailto:Srinivas.Sreemanthula@NOKIA.COM]
>Sent: Thursday, March 09, 2006 3:31 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>