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 will reduce the text and use it for next version. Please review the
condesed in the next version.

Regards,
Srini

>-----Original Message-----
>From: ext Singh Ajoy-ASINGH1 [mailto:ASINGH1@MOTOROLA.COM] 
>Sent: Friday, March 10, 2006 6:05 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: Re: [802.21] Tomorrow's Telecon material
>
>Hi, Srini, 
>
>In my view comparing FMIPv6 information service with CARD is 
>not correct. FMIPv6 defines MN-AR protocol, whereas CARD 
>defines MN-AR, AR-AR, and AR-Server protocols. AR-server piece 
>of CARD protocol is defined in appendix of the CARD RFC. So, I 
>guess, it may be more appropriate if could add some text in 
>line of following text somewhere in section 4 of IS requirement draft: 
>
>"The basic functionality of the CARD protocol is to provide L2 
>or L3 related information on the current and neighboring L2 
>and L3 POAs (point of attachments) to an MN (mobile node). 
>This information in turn is used by the MN for making handover 
>decisions for carrying out a seamless IP-layer handover. The 
>RFC defines only the container protocol for the information 
>elements (or attributes) and not the actual attributes that 
>may be of interest to an MN.  It provides an IANA registry for 
>registering various information elements to be carried out by 
>the protocol. The base spec of the protocol defines messages 
>between MN-AR and AR-AR, but the appendix of the RFC also 
>defines messages between AR and server. " 
>
>I am fine if you would like to modify proposed text to adapt 
>to IS requirement draft. Also since the deadline for IETF 
>submission has passed, please consider this as my input for 
>next revision of the draft.
>
>
>Regards,
>Ajoy 
>
>
>Delete or modify the following text (section 4 of IS 
>requirement draft):
>
>
>
>While information services delivery in this scenario is partly
>   addressed by experimental information services in CARD and FMIPv6,
>   the authors consider a fresh look at these issues are warranted,
>   particularly to establish the applicability of security association
>   establishment mechanisms in these and other environments [21][22].
>
>                                                  /--------\
>    I                                            /          \
>   -----          --------     --------    /----/            \----\
>   |[ ]|          |      |--+--| ---- |---/                        \
>   |ooo|<----------------------->|IS| |  /                          \
>   |ooo|          |      |  |  | ---- |  \                          /
>   -----          --------  |  --------   \                        /
>   Host            Access   |   Router     \----\            /----/
>                   Point    |                    \          /
>                            |  --------         / \--------/
>                            +--| ---- |        / Distribution
>                               | |IS| |-------/    Network
>                               | ---- |
>                               --------
>                                Router
>
>
>   Figure 2: IS-Server on Subnet Router
>
>   Information service servers deployed outside the mobile 
>node's subnet
>   present both advantages and challenges.  As illustrated in Figure 3,
>   an IS-Server outside a subnet doesn't require explicit support from
>   devices the mobile's link.  Therefore the server is able to be
>   deployed in networks which are not able to be modified easily.
>   Additionally, the server is in a position to serve many access
>   subnets simultaneously, which reduces administrative overheads.
>
>
>
>
>-----Original Message-----
>From: Stefano M. Faccin [mailto:stefano.faccin@NOKIA.COM]
>Sent: Thursday, March 09, 2006 6:53 PM
>To: STDS-802-21@listserv.ieee.org
>Subject: 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   
>>>>>>
>>>>>>        
>>>>>>
>>
>