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