RE: [802.21] Discussion on transport protocol selection for MIH!
Ajoy,
thanks foy your opinion. I guess we need to agree on disagreeing on this issue.
Stefano
________________________________
From: owner-stds-802-21@ieee.org on behalf of ext Singh Ajoy-ASINGH1
Sent: Tue 7/19/2005 8:31 PM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Discussion on transport protocol selection for MIH!
Hi Stefano,
I hope this is the last email of this thread.
Regards,
Ajoy
Hi guys,
I have to admit I am a bit baffled by this discussion. Though I agree 802.21 should and shall have a say in the final selection of the protocol to be used for 802.21 transport at L3, I am not sure the right way to do it is by discussing on this list which protocol we should use. That's like saying that 802.21 chooses protocol X and then goes to IETF and tells them "we want protocol X".
Ajoy-> The intent of this discussion was to better understand if we really need anything beyond existing protocol from IETF for L3 transport. If we can conclude that existing protocol can meet the requirements then we do not have to re-start this discussion in IETF again. Please note that IETF standardizations process is lengthy. So, any new work in IETF is going to delay the completion date of IEEE 802.21 work.
I guess anyody with a minimum of IETF experience can tell this does not work with IETF (nor it would work with 802.21 if IETF just imposed something on 802.21).
From my point of view, the best way for 802.21 to influence the selection of a protocol (i.e. whether an existing one "as is", an existing one with enhancements, or a new one) is to define requirements for such protocol based on the scenarios for the usage of L3 transport that 802.21 has been talking about (though implicitly). Perhaps this means in 802.21 we need to capture such scenarios and define the corresponding requirements, then bring the requirements to IETF. Deciding whether this is the way to proceed is something that the chair can do together with the 802.21 group. What I would suggest we consider is that just pushing for a given protocol within the 802.21 discussion adds a lot of noise without really leading the group anywhere.
Stefano
________________________________
From: owner-stds-802-21@ieee.org on behalf of ext NJEDJOU Eric RD-RESA-REN
Sent: Tue 7/19/2005 4:21 PM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Discussion on transport protocol selection for MIH!
Ajoy,
The requirement document for CARD was very ambitious.
The specification (RFC 4066) did not go as far as that ambition, which is understandable as by that time the need for intersystem handover was still to be demonstrated.
Regards
Eric
-----Message d'origine-----
De : Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
Envoyé : mardi 19 juillet 2005 23:02
À : NJEDJOU Eric RD-RESA-REN
Cc : 'STDS-802-21@listserv.ieee.org'
Objet : RE: [802.21] Discussion on transport protocol selection for MIH!
Hi Eric,
I do not know how did you conclude that CARD protocol was designed for only IEEE 802.11 based network? Please refer to the attached CARD requirement document (section 3.2) that clearly states that one of the requirement of CARD protocol was to support inter-technology handoff.
http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-seamoby-card-requirements-02.txt
Please see additional inline comments.
Regards,
Ajoy
-----Original Message-----
From: NJEDJOU Eric RD-RESA-REN [mailto:eric.njedjou@francetelecom.com]
Sent: Tuesday, July 19, 2005 3:39 PM
To: Singh Ajoy-ASINGH1
Cc: STDS-802-21@listserv.ieee.org
Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
Hi Ajoy,
Your presentation says CARD fits for inter-technology handovers. This is questionable as the AR-AP address resolution embedded into CARD operation can only be applied over IEEE 802 links and especially 802.11.
Ajoy-> Please explain why do you think so.
As you are aware of, CARD was designed because of the seamless mobility needs expressed during the design of FMIP within the Mobile IP WG. And FMIP itself was thought to be applicable mostly for 802.11. That's why the only known FMIP implementation are for 802.11 intra-technology handover with subnet change.
Now i am not saying the framework of CARD can not be extended to cover media independant handover signalling.
Ajoy-> Please explain why it can not be extended to cover MIH function.
It simply is not yet adapted exactly for that, at least according to RFC 4066 that describes CARD.
Ajoy-> Which section of RFC 4066 describes that CARD cannot be used by inter-technology handoff?
Eric
-----Message d'origine-----
De : owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] De la part de Singh Ajoy-ASINGH1 Envoyé : mardi 19 juillet 2005 21:42 À : 'Gupta, Vivek G'; 'Koora Kalyan Com Bocholt'; 'STDS-802-21@listserv.ieee.org'
Cc : 'mihep@eng.monash.edu.au'
Objet : RE: [802.21] Discussion on transport protocol selection for MIH!
Seems like a protocol like CARD tends to add extra capabilities beyond those identified in 802.21 which may result in further enhancement of MIH protocol or creation of some other new protocol.
We may need to clarify this more. Would also help if we specify clearly extra functionality currently being proposed as part of L3 transport (CARD etc.) above and extra functionality beyond what's being currently provided by 802.21.
Ajoy-> I am not sure if CARD adds too many extra functionality beyond what is needed by MIH protocol. CARD defines a mechanism for L2->L3 mapping as well as capability discovery mechanism. CARD assumes that MIH function is located at AR and Mobile Node whereas the current 802.21 spec does NOT mandate the location of network MIH component. But I would go though the suggested section of latest MIH spec and then continue further discussion. In case I notice that CARD provides additional functions beyond what is needed by 802.21, I will flag those as well.
BR,
-Vivek
> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
> Sent: Tuesday, July 19, 2005 8:54 AM
> To: Gupta, Vivek G; 'Koora Kalyan Com Bocholt'; 'STDS-802-
> 21@listserv.ieee.org'
> Cc: 'mihep@eng.monash.edu.au'
> Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
>
> Hi Vivek,
>
> Please find my inline replies. I am also attaching herewith a
> presentation slides about CARD. I guess the overview of CARD will be
> useful for 802.21 folks to better understand the background of CARD
> protocol and how it is useful for MIH transport.
>
> Regards,
> Ajoy
>
> -----Original Message-----
> From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> Sent: Tuesday, July 19, 2005 4:10 AM
> To: Koora Kalyan Com Bocholt; Singh Ajoy-ASINGH1; STDS-802-
> 21@listserv.ieee.org
> Cc: mihep@eng.monash.edu.au
> Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
>
>
> Given the wide coverage of cellular and wimax networks the
> issue/problem often turns out to be, how to detect the presence of
> wifi and how to decide to switch over to wifi? In the below case
> seems like the Information Service may not be very helpful in
> detecting the presence of wifi anyway. Seems like you may have to
> detect presence of wifi by traditional (beacon scan/probe) means
> anyway, unless the cellular network can give you some hint about
> presence of a wifi hotspot. And again after detecting the presence of
> wifi you may have to resort to L2 to pull up information pertaining to appropriate network selection.
>
> In general during discussions in 802.21, some of the requirements that
> emerged are as follows:
> 1] Need to enable both L2 and L3 transports
> L3 may be primarily used for 3G networks (where it is more difficult
> to modify L2 in a timely manner). L2 enabling in case of 802 networks
> is relatively less difficult and needed in certain cases.
>
> Ajoy-> I am ok with defining extensions to L2 if it is doable in some
> cases as you pointed out.
>
> 2] 802.21 defines the payload in both cases (both for L2 and L3
> transports) for MIH services. This should work for different MIH users
> including different L3 and above mobility protocols as well.
>
> Ajoy-> Do you mean infoElements? I guess MIH should define various
> infoElements and higher layer should be able to use appropriate
> transport mechanism and encoding to transport the infoElements.
>
> 3] Other requirements for L3 transport:
> a] How do you discover the presence of MIH services (IS, CS, ES etc.)
> and capability at L3?
>
> Ajoy-> This can be done both at L2 as well as L3. There are several
> Ajoy-> ways
> to do this:
> a. Extend l2 beacon
> b. Allow un-solicited L3 message from MIH server to MN for MIH discovery.
>
> c. Let mobile node send query and if it does not get any reply then it
> can assume that MIH function is not supported by network.
>
> b] Any security considerations
>
> Ajoy-> We need to have security association between MN<-> MIH Server
> Ajoy-> and
> between Network MIH Servers.
>
> c] If an IP based transport is used we may need to select appropriate
> port numbers if we end up selecting different protocols for carrying
> (IS,CS,ES) payloads.
>
> Ajoy-> I do not think just selecting appropriate port number is
> Ajoy-> enough. I
> guess we need a protocol between MN<->MIH Server and MIH Server<-> MIH
> Server. I would suggest please go through CARD (RFC 4066) as well as
> attached presentation slides.
>
> Not sure if we need much else beyond this:
>
> BR,
> -Vivek
>
> > -----Original Message-----
> > From: Koora Kalyan Com Bocholt [mailto:kalyan.koora@siemens.com]
> > Sent: Tuesday, July 19, 2005 12:11 AM
> > To: Singh Ajoy-ASINGH1; Gupta, Vivek G; 'STDS-802-21@listserv.ieee.org'
> > Cc: mihep@eng.monash.edu.au
> > Subject: AW: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> > Hi Ajoy,
> >
> > let me put up an other scenario where it is also not possible to get
> > information over higher layer.
> > Let us assume you have an IP connection over a cellular interface
> > like 3GPP and your in a foreign country. You come up to a hotspot
> > where you don't have any knowledge of the ISPs over there. Further,
> > it is possible that some come up and some go down time to time. In
> > this case how does the cellular provider knows about the hotspot? Or
> > do you assume that all the ISPs at hotspots do have some agreements
> > with the cellular ISP? Some of them could be just 'local' ISPs using
> > firewall/NAT/masquerading techniques and are not interested in cellular providers.
> > In this case too, you may have the possiblity to handover to the
> > hotspot ISP if you find any suitable provider.
> >
> > Regards,
> > Kalyan
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
> > Gesendet: Montag, 18. Juli 2005 17:07
> > An: 'Gupta, Vivek G'; Koora Kalyan Com Bocholt;
> > 'STDS-802-21@listserv.ieee.org'
> > Betreff: RE: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> >
> > [Gupta, Vivek G]
> > Actually the difficulty is for the first time, when you are powering
> > up
> or
> > in an un-initialized state or don't have any of the links connected.
> > At that time which initial link to select may be an issue. But then
> > you could always have a default radio/link to use in such cases.
> >
> > Ajoy-> Yes, but that is initial call setup scenario. Do we really
> > Ajoy-> need any seamlessness during initial call setup?
> >
> > -----Original Message-----
> > From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> > Sent: Sunday, July 17, 2005 9:45 AM
> > To: Singh Ajoy-ASINGH1; Koora Kalyan Com Bocholt;
> > STDS-802-21@listserv.ieee.org
> > Subject: RE: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-stds-802-21@ieee.org
> > > [mailto:owner-stds-802-21@ieee.org]
> > On
> > > Behalf Of Singh Ajoy-ASINGH1
> > > Sent: Sunday, July 17, 2005 6:36 AM
> > > To: 'Koora Kalyan Com Bocholt'; 'STDS-802-21@listserv.ieee.org'
> > > Subject: RE: [802.21] Discussion on transport protocol selection
> > > for
> > MIH!
> > >
> > > Hi Kalyan,
> > >
> > > I would like to comment on one of your statement here.
> > >
> > > Regards,
> > > Ajoy
> > >
> > >
> > > If we select higher layer protocols (eg. layer 3), it is
> > > difficult for the IS to be delivered before a generic layer
> > > related connection is established (if we consider IP, then
> > >
> > > Ajoy-> If you have multi-link mobile, you can use IP transport of
> > > connected link to obtain information about neighboring link.
> > [Gupta, Vivek G]
> > Actually the difficulty is for the first time, when you are powering
> > up
> or
> > in an un-initialized state or don't have any of the links connected.
> > At that time which initial link to select may be an issue. But then
> > you could always have a default radio/link to use in such cases.
> >
> >
> >
> >
> > >