Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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