RE: [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.
>
> 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.
> - 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.
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.
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.
>
> 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).
>
> 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. 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.
> - 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
>