RE: [802.21] Tomorrow's Telecon material
Just to make sure everybody is in line, the IETF submission deadline was
according to "March 6, Monday - Internet Draft final submission cut-off
by 09:00 ET (14:00 GMT)".
Stefano
>-----Original Message-----
>From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@MOTOROLA.COM]
>Sent: Thursday, March 09, 2006 6:22 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] Tomorrow's Telecon material
>
>Subir,
>
>Ok, I will send the text tomorrow. I think deadline is Monday.
>
>Regards,
>Ajoy
>
>-----Original Message-----
>From: Subir Das [mailto:subir@RESEARCH.TELCORDIA.COM]
>Sent: Thursday, March 09, 2006 6:18 PM
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: Re: [802.21] Tomorrow's Telecon material
>
>Ajoy,
>I cann't agree anymore with Srini. Pl. go ahead and send the text.
>
>Thanks,
>-Subir
>
>Srinivas Sreemanthula wrote:
>
>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>