RE: [802.21] [MIHEP] Discussion on transport protocol selection f or MIH!
Kalyan,
you have some very good points. It's great discussing with you, you're helping me seeing certain aspects from a different point of view. Please find some comments for clarification.
Stefano
> -----Original Message-----
> From: owner-mihep@ecselists.eng.monash.edu.au
> [mailto:owner-mihep@ecselists.eng.monash.edu.au]On Behalf Of ext Koora
> Kalyan Com Bocholt
> Sent: Friday, July 15, 2005 09:29
> To: STDS-802-21@listserv.ieee.org
> Cc: mihep@eng.monash.edu.au
> Subject: AW: [802.21] [MIHEP] Discussion on transport
> protocol selection
> f or MIH!
>
>
> Dear Stefano,
>
> please find my comments inline.
>
> Regards,
> Kalyan
>
> -----Ursprüngliche Nachricht-----
> Von: owner-mihep@ecselists.eng.monash.edu.au
> [mailto:owner-mihep@ecselists.eng.monash.edu.au] Im Auftrag von
> stefano.faccin@nokia.com
> Gesendet: Donnerstag, 14. Juli 2005 18:55
> An: STDS-802-21@listserv.ieee.org
> Cc: mihep@eng.monash.edu.au
> Betreff: FW: [802.21] [MIHEP] Discussion on transport
> protocol selection for
> MIH!
>
>
> >Kalyan,
> >thanks for your detailed analysis. I'm also copying the
> MIHEP mailing list
> to include our IETF
> >colleagues that have shown interest in the topics. Please see below.
> Stefano
> >
> >> -----Original Message-----
> >> From: owner-mihep@ecselists.eng.monash.edu.au
> >> [mailto:owner-mihep@ecselists.eng.monash.edu.au]On Behalf
> Of ext Koora
> >> Kalyan Com Bocholt
> >> Sent: Thursday, July 14, 2005 05:38
> >> To: STDS-802-21@listserv.ieee.org
> >> Subject: [MIHEP] Discussion on transport protocol
> selection for MIH!
> >>
> >>
> >> Hello All,
> >>
> >> at first I am glad to see that some discussion has started on the
> >> reflectors regarding 802.21 related aspects after a long
> break. I hope
> >> it will give a good result this way.
> >>
> >> While defining transport protocols for 802.21 service
> elements (ES, CS
> >> & IS), we have to keep couple of points in mind
> >> [Ref: .21 draft]:
> >>
> >> - the information exchange should be done fast
> >> - the overhead in exchange of information should be as less as
> >> possible
> >> - the extraction of the information at the terminal should
> not include
> >> high computational complexity
> >Stefano: indeed, these are requirements that 802.21 has
> produced and that
> needs
> > to be communicated clearly to IETF, thanks for bringing them up.
> >
> >>
> >> Though this is defined within IS section, this is valid
> for all the
> >> service elements. Within the present .21 draft, a 'common' frame
> >> format for service element exchange is defined.
> Irrespective of the
> >> transport protocol, this (future standardized) frame
> format should be
> >> taken as a requirement which should be embedded into the transport
> >> protocol without any change. That is, encapsulating the
> .21 frame in
> >> the transport protocol.
> >Stefano: the frame format is a good starting point. However,
> I think if we
> want
> >IETF to adopt it either as is or as a starting point, we
> need to present it
> to
> >IETF and identify in detail why it is good. What you say
> here is true, my
> point
> >is mainly that spelling all these aspects out in the form of
> requirements
> to
> >IETF would help the work in IETF tremendously.
> -----------------------------------------------------------
> [Kalyan]
> I agree with this too. Anyhow, I have a feeling that we have
> to refine the present format a bit to suit all the needs, also
> from IETF point.
[Stefano] I agree.
> -----------------------------------------------------------
> >>
> >> From my point of view, it is ideal to define ONE standardized
> >> transport protocol to carry the service elements between
> different MIH
> >> peers. This protocol should be 'ideally' able to:
> >>
> >> - carry the service elements ES, CS and IS
> >> - exchange the information with little delay (without complicated
> >> acknowledge methods with CRCs, retransmissions)
> >> - enable the client/station to extract the information quickly
> >> and forward them to higher layers.
> >Stefano: I am not sure one single protocol over IP can satisfy the
> requirements
> >of the three services, I think we would have to study
> potential protocols
> >carefully. E.g. IS does not require the same level of
> reliability and does
> >not have the same delay constraints ad ES and CS.
> >
> >>
> >> These requirements do recommend to select transport
> protocols which
> >> are suited for layers as low as possible (e.g.. layer 2).
> >Stefano: 802.21 has since the beginning identified that both
> L2 and L3
> transports
> >are needed for 802.21 services. For L2 transport, the
> supporting arguments
> include
> >the points you mention here. For L3 transport there are
> several reasons
> >(please see comments below).
> >
> >>
> >> I see that constraints in selection of lower layer protocols are
> >> arising mainly due to the IS. This is because the IS involves in
> >> carrying different network discovery and service discovery
> >> information. Further, a part of IS is of dynamic type, i.e. some
> >> service may be available at a particular time only.
> >>
> >> Problem factor (from IS point of view)
> >> - If we select lower layer protocols, it is almost impossible
> >> to deliver complete IS in request/response method.
> >> - If we select higher layer protocols (e.g.. layer 3), it is
> >> difficult for the IS to be delivered before a generic layer
> >> related connection is established (if we consider IP, then
> >> prior to exchange of info an IP connection is to be established).
> >Stefano: for completeness we need to consider this can be read also
> >as the IS service being accessible only through the current access.
> >What I mean is that you can have L3 connectivity over access/domain
> >1 and use the MIH IS to obtain information on access/domain
> 2 through IS
> >transported over L3 over the current connection. This is one of the
> >scenarios that was considered since the beginning of the 802.21 work.
> -----------------------------------------------------------
> [Kalyan]
> here too, it is true what you say for one scenario. But we
> should also think of scenarios where we haven't established
> a connection yet and where we don't have any L3 connection.
[Stefano] absolutely, I agree, nothing of what has been proposed or is being discussed is meant to tule those scenarios out. Obviously, you cannot access the extended IS set over L3 trhough the target access until you have L3 connectivity. At the same time, if I am a terminal that has no connections whatsoever, by trying to get a connection I am not performing a handoff. One may then argue that MIH services are not relevant, since they are meant to facilitate handoff, not initiate connections from scratch. We are fortunate that the MIH IS can give us tools to simplify the discovery of certain information needed to decide to which PoA the terminal wants to connect to (and by all means I think we should squeeze any benefits possible out of that), but we should be careful not to mix that up with handoff.
> -----------------------------------------------------------
> >> - On the other side, if complete IS is not available at mobility
> >> protocol, it is not possible to select and connect to an
> >> appropriate network.
> >>
> >> Thus, both of the protocol selections do have their own
> advantages and
> >> disadvantages.
> >Stefano: Kalyan, I think there is are also other two very important
> >aspects to be considered in the analysis. L2 transport of the MIH
> >services requires standardization in each of the link-layer
> technologies
> >(e.g. in 802.11, in 802.16, in 3GPP, 3GPP2, etc.). This is
> understood and
> >is accepted and feasible for at least 802.11 and 802.16. For
> 3GPP and
> >3GPP2 we can debate for a long time whether this is feasible or not,
> >IMHO based on several discussions with subject matter
> experts for 3GPP/PP2
> >standardization, it may be very hard to get 3GPP/PP2 to
> modify their L2
> >to support MIH services. Anyway, even assuming all of this
> is feasible,
> >we need to consider how long it will take to get the L2 transport
> >standardized. Moreover, even assuming the standardization is
> fast, we need
> >to consider that existing equipment will have to be modified
> (or replaced)
> >to support the new standard.
> -----------------------------------------------------------
> [Kalyan]
> Stefano, here too I completely support your opinion. I can
> realise how difficult it is to get either L2 or L3 based things
> to be moved through 3GPP/PP2. If we would like to include
> these services
> too, then an other scenario what we have to think of in designing a
> specific protocol for .21 is: We are in a foreign country and
> have no connection yet, and would like to start a session. In this
> case MIH has to get basic IS to select one PoA. Does our L3 protocol
> (which is to be defined) fits over here?
[Stefano] No, and it is not meant to fit there. You may want to go back to the previous e-mails and some of our presentation in 802.21, where we show which scenarios fit the L3 transport. Let me underline once more that L3 transport will not be capable of supporting all scenarios, and is not meant to. Apparently I've done a poor job of highlighting this.
> To make the scenario much more hard, we can assume that there
> are only 3GPP/PP2 networks reachable.
> -----------------------------------------------------------
>
> >Therefore, I see two dimensions: on one hand,
> >implementing L3 transport for IS would allow deployment of 802.21 IS
> service
> >independently of the status of standardization of L2
> transport in the
> >various fora. E.g. one can provide the IS service over L3
> transport for a
> >3GPP/WLAN interworking scenario even if neither the 3GPP nor
> WLAN equipment
>
> >supports the MIH IS service.
> -----------------------------------------------------------
> [Kalyan]
> We should be careful about this. It is giving me an impression
> that we are dividing 802.21 scope into two parts. I see MIH
> as a combination of 3 services. If not, we have to justify
> what is the advantage over other SD protocols. Otherwise it
> is treated as 'yet an other service discovery protocol'.
[Stefano] godd point, I agree.
> -----------------------------------------------------------
>
> >On the other hand, there are scenarios for
> >deployment of 802.21 MIH IS where it is actually necessary to access
> >information about a new access/domain without having any type of
> >connectivity with that specific access/domain, therefore requiring
> >access to the IS from the current access/domain (and this in most
> >scenarios requires L3). In addition, if in a specific
> scenario access to
> >IS needs to be secured (even for the basic information set),
> access to IS
> >information on new access/domain through IS over L3 using
> the current
> >connection may be the only way to go (due to the known problems of
> >securing exchanges of information e.g. in 802.11 over query/response
> >mechanisms before the terminal has actually associated). In
> conclusion,
> >I don't disagree with you, I'm just highlighting the fact
> that there are
> >other dimensions and scenarios to consider.
> -----------------------------------------------------------
> [Kalyan]
> Regarding security, I just point to section 5.1.6:
> "Events, commands and information messages carried between a MT and a
> network PoA
> cannot be secured until the MT is securely associated with
> the network PoA."
> So, if we mention basic information set should be transmitted
> prior to point of attachment, then it is unsecure.
> -----------------------------------------------------------
[Stefano] I guess it all depends on how you interpret the term PoA. I would leave this discussion to the design of the various scenarios that we need to add to the 802.21 document.
>
> >>
> >> At least to overcome part of the difficulty, it has been
> decided to
> >> divide the IS into basic and extended set. The main
> intention of the
> >> basic set is
> >> - to be delivered as soon as possible without much delay
> >> - to keep the amount of information as small as possible
> >> - to extract the information without any great complexity
> >> - to embed less secure information
> >>
> >> This basic set enables the client/station to have a
> knowledge of the
> >> network and allow it to decide to ask for extended information if
> >> needed. Either the higher layer can do this it self, like
> enabling a
> >> connection and asking for extended set or the higher layer
> can ask MIH
> >> to get this information. The extended set can have secure
> information
> >> elements.
> >Stefano: All of this is good and correct. I would like to
> add that even
> >the basic IS set can be transported over L3, even if with
> the constraint
> >that such information is obtained through the current access
> (e.g. by
> >connecting to an 802.21 server in the new access/domain).
> -----------------------------------------------------------
> [Kalyan]
> Just to point out that some cocepts like 802.1x don't allow
> this untill your authenticated.
> -----------------------------------------------------------
[Stefano] sorry once again for the poor job in explaining my point. I am aware 802.1X does not allow you to exchange L3 traffic over an authenticated 802.11 connection. If you read carefully my comment, I am stating that the access to IS through L3 is not through the target access (i.e. the one you're trying to connect to), but the current access (i.e. the access you currently have a connection with and therefore you can exchange L3 traffic).
>
> >>
> >> Now keeping all these points in mind, and seeing the
> discussion on the
> >> mailing lists, I feel, that we have to divide the 802.21 service
> >> elements into 2 categories:
> >>
> >> category 1 for ES, CS and Basic IS (BIS)
> >> category 2 for Extended IS (EIS)
> >>
> >> and transport protocols have to be discussed for them
> independently as
> >> the requirements of both the categories are a bit different.
> >Stefano: Kalyan, this is indeed one of the possible ways to see the
> problem.
> >In the MIHEP BOF we did not suggest dividing the analysis
> between basic and
>
> >extended set, but I agree it would be useful. We can
> definitely adjust the
> >ideas proposed in the MIHEF BOF proposal to add more
> granularity to the
> >analysis and consider basic and extended sets separately.
> >
> >> Further, the 1st category is intended to be transmitted between
> >> client/station and the Point of Attachment (PoA) with "relatively"
> >> less data. Whereas, the 2nd category can be carried over gateways,
> >> routers, etc. where there is "relatively" much data.
> >Stefano: I'd like to add that the split between cat.1 and cat.2 does
> >not (and should not) forbid transport at L3 of e.g. both the
> basic and
> >extended IS sets.
> -----------------------------------------------------------
> [Kalyan]
> I agree to this. This is also a reason to keep the transport
> ptorocol out of .21 standards scope.
> -----------------------------------------------------------
[Stefano] That's why I believe for L3 transport the work belongs to IETF, and the MIHEP initiative is based on such belief. At the same time, I believe 802.21 has the opportunity to influence that work considerably, and we should exercise such influence.
>
> > For this reason, in the MIHEP BOF request we suggested
> >that the analysis of requirements should be separated by
> services, at
> >least by considering IS as one block and ES/CS as a second
> block. This
> >is needed firstly because IS requirements and usage scenarios for L3
> >transport are very different from requirements and usage
> scenarios for
> >ES and CS. Secondly, it may be that no relevant or useful
> scenarios for
> >L3 transport of ES and CS are identified, in which case
> there should not
> >be impact on the analysis of IS L3 transport requirement and the
> >selection/design of a solution for IS.
> >
> >>
> >> Couple of questions on experts:
> >>
> >> - If this is agreed, shall the BOF discussed for future
> should cover
> >> both?
> >Stefano: I would like to modify the structure of the
> discussion along
> >the lines you're suggesting, and in addition considering the
> points I've
> >added above. Just to avoid misunderstandings, though, we
> need to keep
> >in mind that the MIHEP BOF for the next IETF meeting has not
> been approved,
>
> >therefore we will have only a less formal bar BOF at the
> next IETF meeting.
>
> >However, discussion on the MIHEP mailing list with
> participation of both
> >802.21 and IETF experts would be useful to collect enough
> feedback and
> >points for discussion to have an educated bas BOF at the next IETF.
> >
> >> - In our draft, we mentioned about an option "MAC
> Management Frames"
> >> carrying MIH service elements. If the aim of the group is to
> >> develop some protocols just like EAPoL, then are these considered
> >> as Management or Data frames?
> >Stefano: Kalyan, to avoid misunderstanding, I guess you are
> referring
> >to the current IEEE 802.21 group draft that was accepted at the last
> >IEEE 802.21 meeting. Please correct me if I'm wrong. Then I
> guess this
> >and the next questions are more relevant for the 802.21 folks, less
> >for the IETF folks.
> -----------------------------------------------------------
> [Kalyan]
> Yes, that is what I am referring to.
> -----------------------------------------------------------
>
> >> - If the above answer is "data frames", then does .11 or
> .3 presently
> >> allows to access management frames from higher layers (layer 3
> >> and above)?
> >> - Where is the correct place for such discussions IEEE or
> IETF or ???
> >> To my understanding lower layer protocols like EAP, ARP are also
> >> topic of IETF.
> >Stefano: that's a good question. IMHO, the discussion needs
> to take place
> >on both sides and coordinated.
> >
> >>
> >> Waiting eagerly to get your comments,
> >>
> >> with best regards,
> >> Kalyan
>