RE: [802.21] Higher layer requirements for IETF: meeting minutes
Stefano and all,
Thanx for the minutes. Few comments.
1] The protocol aspects (of MIH Protocol) come more into play for ES and
CS than for IS (which is mostly query/response). ES and CS have many
more messages and require req/rsp/ind type of messages which are more
involved than just IS related message exchange. As such if IETF/MIPSHOP
is currently only/mostly considering IS, protocol implications may not
be all that much applicable.
On the flip side what's so bad if 802.21 defines the payload and we
don't standardize a L3 protocol for IS? People could still use
proprietary (or hard-coded fixed ) ways to discover MIH IS servers and
wrap 802.21 specified MIH payloads in IP packets under some GUI. Things
could still work...(By no means am I saying that this work is not
required....just trying to get a perspective...)
2] Should MIHF in one network communicate with MIHF in another network?
How can we support network initiated handovers between Cellular <> Wimax
and say between WiMax/Cellular -> WiFi? Some sort of message exchange
may need to take place to support the network initiated handover
case.......What happens for network initiated homogeneous handovers (say
WiMax)? Do base stations need to exchange messages?
3] Can we get any input from IETF as to what IEs are more useful from
handover (L3MP) perspective? That may help our cause as well.
Best Regards,
-Vivek
> -----Original Message-----
> From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
On
> Behalf Of stefano.faccin@nokia.com
> Sent: Tuesday, July 26, 2005 4:51 PM
> To: STDS-802-21@listserv.ieee.org
> Subject: [802.21] Higher layer requirements for IETF: meeting minutes
>
> Please find enclosed the minutes of the 802.21 teleconference on July
26.
> Please let me know if I missed any important points. Srini, thank for
> taking electronic notes that I could use to write up the minutes.
> BR,
> Stefano
> P.S. the next audio conference on the same topic is on July 28 at 9PM
EST,
> please check previous e-mails on reflector for details.
>
> Purpose
> =======
> 802.21 Higher layer requirements for IETF
>
> Date
> ====
> July 26, 9am-11am EST.
>
> Participants
> =========
> Alistair Buttar, Subir Das, Stefano Faccin, Peretz Feder, Andrea
Francini,
> Prasad Govindarajan, Eleanor Hepworth, Benjamin Koh, Kalyan Koora,
Hong-
> Yon Lach, Xiaoyu Liu, Andrew McDonald, Yoshiro Ohba, Ajay Rajkumar,
Reijo
> Salminen, Ajoy Singh, Srinivas Sreemanthula, Qiaobing Xie
> (I apologize in advance if I missed somebody, as I'm sure I did; also,
i
> apologize for any mispelling)
>
> Discussion
> ========
> * Ajay summarized discussion that took place last week at IEEE
meeting
> regarding 802.21 and IETF
> * the current result of the discuss with Gabriel Montenegro (chair
of
> MIPSHOP WG) is that the MIPSHOP is willing to take up IS-related work
> through re-chartering. Requirements would have to come from 802.21 WG.
The
> MIPSHOP WG chair made clear that ES and CS most probably do not fit
the
> MIPSHOP framework
> * Ajoy brought up CARD applicability. It was agreed that the L3
> requirements are being worked out and the protocol selection is out of
> scope at this time
> * Stefano presented the high-level kickoff slides (previously
> distributed)
> * With respect to next IETF: Stefano indicates he will give up the
> slot currently allocated to the Faccin/Daley ID to present the
> requirements coming from 802.21. Also, a MIHEP Bar BOF will take place
to
> complement the 20min slot in MIPSHOP at IETF meeting.
> * Ajoy commented that ES and CS need not be on L3. No real
discussion
> took place, since it was agreed that present focus (due urgency to
provide
> requirements for IS to IEEE.
> * The question of what is "L3 transport" came up. The term may be
> misunderstood by IETF (e.g. Gabriel had indeed misunderstood it), and
> there does not seem to be complete consensus in 802.21 yet. Comments
were
> raised that if by "L3 transport" for 802.21 we actually consider just
> transport aspects, in theory 802.21 could define the protocol by
itself
> and then specify TCP or UDP transport, and ask IANA for allocation of
port
> numbers.
> * During the discussion it was indicated that by "L3 transport" we
> mean also architectural aspects such as discovery of MIHF
> functions/capabilities and security (i.e. aspects that are more
protocol
> oriented)
> * Discussion led to identifying three scenarios: (1) 802.21
defines
> only IEs, IETF defines the transport aspects, and no protocol
definition
> takes place; (2) 802.21 defines both the IEs and the protocol, and
IETF
> defines the transport aspects; (3) 802.21 defines the IEs, IETF
defines
> the transport aspects, and 802.21 and IETF collaborate in defining the
> protocol. Security aspects are definitely defined in IETF (out of
scope
> for 802.21). discovery aspects are defined by 802.21 and specified in
IETF.
> Ajay also indicated that the target at present is (2) or (3)
> * Some parties commented that (3) is more in line with the way
IETF
> works
> * As for discovery aspects, some parties indicated that it can be
part
> of work already on-going in other WGs, as an extension of current
> discovery solutions or as part of host configuration solutions
> * Ajoy asked if we should first define the protocol 802.21, then
bring
> it to IETF. Stefano indicated that timing is very important and that
we
> should not miss the current opportunity we have with MIPSHOP willing
to
> re-charter to include 802.21 aspects. Stefano reminded that the re-
> chartering must close soon (Gabriel indicated he needs to provide the
new
> charter to the ADs just after the next IETF, but Gabriel mentioned he
can
> stay a bit vague to allow for adjustments)
> * Ajoy asked if #1 can be more suitable for the success of 802.21,
i.e.
> 802.21 would not need to have the work in IETF completed before saying
it
> has completed its duties. WG think #3 would be better for the success.
> Ajay reminded that the success of 802.21 does not depend on completion
of
> work in IETF
> * Discussion about basic and extended information service. Kalyan
> asked if the "L3 transport" is only for extended-set? No, it is
applied to
> all of IS, since in some scenarios it is relevant only for extended
IS, in
> some other also for basic IS
> * Ajoy raised a question if two MIH servers can talk to each
other. It
> is not clear if two MIH functions in network can talk to each other.
Yoshi
> mentioned there is no need for such communication. Kalyan asked how
e.g.
> is the neighbor graph exchanged? Yoshi mentioned that transferring
> neighbor graph is out of scope of 802.21. Peretz indicated that one
> scenario is where MIH is proxied, e.g. MIHF in UE talks to an MIHF in
the
> network it is attached to, and the MIHF in the network proxies MIH
> information to another MIHF e.g. in the home network. It was mentioned
> this could be decided later, but since it affects the L3 requirements,
> Stefano suggested to assume that there "may" be communication between
two
> MIH functions and discuss this later in the emails. Qiaobing also
reminded
> this discussion is closely related to the model discussion that took
place
> at the meeting last week. Benjamin reminded that the MIH model
discussed
> at the ad-hoc was not agreed yet by the whole WG.
> * Stefano presented 3 scenarios to trigger discussion for L3
> requirements.
> * Yoshi pointed #1 and #2 are similar. Another scenario was
proposed
> (and numbered as #4): no L3 protocol is used between the MIHF in the
> terminal and the MIHF in the PoA, L2 is used instead, but then from
MIHF
> in PoA and MIHF in the network a L3 solution is used.
UE----L2--->sPoa---
> L3--->MIS
> * Ajoy mentioned another scenario where
UE----L3--->sPoa----L3.----
> >cPoa or UE----L3--->sPoa----L3---->MIH, Stefano replied it is a
subset of
> the current third scenario (but it will be described explicitly)
> * Ajay indicated that we still need to clarify to IETF what we
mean
> exactly by PoA, since it impacts this discussion and may be confusing
to
> IETF. Stefano suggested that a way forward is to present to IETF
example
> of PoAs, without necessarily providing a comprehensive and exhaustive
> definition.
> * Stefano indicates we need to consider two kinds of MIS interface
> since requirements may be different and should be at first looked
> separately (we can merge requirements if they are the same)
> * i) MIHF in UE to MIHF in network
> * ii) MIHF in network to MIHF in network
> * Qiaobing mentioned discovery should not be part of transport
> requirements. It was emphasized that the discussion is not just for
plain
> transport (in IETF sense of the term) but "L3 and above" requirements
for
> MIIS. It was agreed this needs ot be made very clear in slideset.
> * Also, Qiaobing suggested that we separate the requirements that
> relate only to transport from those that relate to
architectural/protocol
> aspects
> * Hong-Yon asked why we are considering also protocol
requirements.
> Stefano indicated we should try to list all the requirements we can
come
> up with, then choose which one we think are relevant for the
discussion in
> IETF.
> * Stefano will send out new slideset for discussion on mailing
list.
> * It was agreed to send contributions to requirements at least 4
> (four) hours before the next tele-conference so that the input can be
> consolidated
> * WG is encouraged to discuss and send scenarios and L3
requirements
> by next conf meeting on Thursday 9 PM EST.