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