Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi all, I made the changes discussed yesterday (I hope I captured everything). Comments are solicited and very welcome. Stefano > -----Original Message----- > From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]On > Behalf Of ext Stefano M. Faccin > Sent: Tuesday, July 26, 2005 18:51 > 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. >
802.21 Higher Layer requirements strawman_v0.2.zip