RE: [802.21] Higher layer requirements for IETF: meeting minutes
Kalyan, good question. Let's see what the list thinks about it.
Stefano
> -----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.
>