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