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

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