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

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