-----Original Message-----
From: ext Koora Kalyan Com Bocholt [mailto:kalyan.koora@siemens.com]
Sent: Wednesday, July 27, 2005 10:23
To: Faccin Stefano (Nokia-NRC/Dallas); STDS-802-21@listserv.ieee.org
Subject: AW: [802.21] Higher layer requirements for IETF: meeting
minutes
Hi Stefano and all,
thank you for the minutes. After going through them again,
a clarification need arrised while understanding the 3
scenarios we were discussing.
With "IE" in the scenarios, I understand 'presently' it
is only IS-IE. But does it mean:
IS-IE = MIH Message Header + MIH Message Payload
(including MIH IS Message Data)
or
IS-IE = MIH Message Payload
(including MIH IS Message Data)
or
IS-IE = MIH IS Message Data ONLY?
This is also having an important impact on the L3 transport
discussion for 802.21 MIHF.
Regards,
Kalyan
-----Ursprüngliche Nachricht-----
Von: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org] Im
Auftrag von Stefano M. Faccin
Gesendet: Mittwoch, 27. Juli 2005 01:51
An: STDS-802-21@listserv.ieee.org
Betreff: [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.