RE: [802.21] Tomorrow's Telecon material
Hi Ajoy,
There is no better CARD expert than you so it is only fair that you have
the opportunity. Please keep the text along introductory lines but not
along the solution lines and also limit the text as people are already
angry with me for having so much text. :-)
Regards,
Srini
>-----Original Message-----
>From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
>Sent: Thursday, March 09, 2006 5:56 PM
>To: Sreemanthula Srinivas (Nokia-NRC/Dallas);
>STDS-802-21@LISTSERV.IEEE.ORG
>Subject: RE: [802.21] Tomorrow's Telecon material
>
>Hi Srini,
>
>Ok, great! I will send proposed text to you.
>
>Regards,
>Ajoy
>
>-----Original Message-----
>From: Srinivas.Sreemanthula@nokia.com
>[mailto:Srinivas.Sreemanthula@nokia.com]
>Sent: Thursday, March 09, 2006 5:51 PM
>To: Singh Ajoy-ASINGH1; STDS-802-21@LISTSERV.IEEE.ORG
>Subject: 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>