| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello Kalyan, thanks for adding the material to clarify your question. Yes, it is in line with my understanding of your question last week. I apologize if my answer to you question during the meeting was not clear. From my point of view, the consumer of IETF MIH-IEs is the MIHF. With option 3c the protocol defined by 802.21 goes to IETF, and IETF can enhance it by adding new IEs and possibly new fields to the MIH header (e.g. for security). The result is a protocol that the MIHF will process entirely. Now, we need to distinguish between the logical split of functionality and the implementation. One way of implementing it is what you indicated in the slides you sent with the transport adapter. However, logically the idea is in slide 4 of the enclosed set. Please note that I made a mistake in the picture of option 3c, and slide 3 of the enclosed set has the actual representation I had in mind. Thanks, Stefano >-----Original Message----- >From: ext Kalyan Koora [mailto:kalyan.koora@benq.com] >Sent: Thursday, December 15, 2005 3:35 AM >To: Faccin Stefano (Nokia-NRC/Dallas); STDS-802-21@listserv.ieee.org >Subject: AW: [802.21] IS Higher Layer Transport Requirements: >update on conf call on December 8 > >Hi Stefano, > >to understand your concept I have added one more slide "clear >division of work". Please have a look at it. I feel, we all >are saying the same thing but somehow misunderstanding is >comming in the middle. > >As long as the MIH-Packet delivered by the Tx MIHF Peer is >received at the Rx MIHF Peer over higher layer, it doesn't >matter what is happening with the packet during >transportation. (Just think of beaming in Startrek, as long as >all the particals reach from one point to the other, things go >fine if ;-) > >One thing which is not clear to me is, who is the consumer of >IETF MIH-IEs. If it is other than MIHF, I see no problem. If >it is to be MIHF, then the packet syntax, IE's integrity etc. >should be as defined by IEEE MIH protocol and should be >understood by the MIHF. >(Just trying to understand in this way, if you order a Pizza >and get it delivered, you will be happy. But if you order a >Pizza and get it delivered along with a bottle of wine, then >you will be much more happy ;-) > >Please have a look at the appended slide. > >Regards, >Kalyan > > > > >-----Ursprüngliche Nachricht----- >Von: Stefano M. Faccin [mailto:stefano.faccin@NOKIA.COM] >Gesendet: Mittwoch, 14. Dezember 2005 18:26 >An: STDS-802-21@listserv.ieee.org >Betreff: Re: [802.21] IS Higher Layer Transport Requirements: >update on conf call on December 8 > > >Hi, >as per my action point, here is the set of slides with the new >option 3c and related comments. Kalyan, thanks for reminding >me! Stefano > > >>-----Original Message----- >>From: ext Stefano M. Faccin [mailto:stefano.faccin@nokia.com] >>Sent: Wednesday, December 07, 2005 7:21 PM >>To: STDS-802-21@listserv.ieee.org >>Subject: [802.21] IS Higher Layer Transport Requirements: >>update on conf call on December 8 >> >>Updated agenda: >>Agenda: >>1) review of requirements produced at ad-hoc meeting >> in November - 30 min >> doc. 21-05-0441-00-0000-IS_Ad Hoc.ppt >>2) review of discussion on IETF involvement - 30 min >> doc. 21-05-0408-00-0000-IETFInvolvment.ppt >> No conclusions were reached in Vancouver (based >> on 21-05-0451-00-0000-802_MIHS_minutes_2005_11_14.doc). >> Way forward? >>3) IEs and their representation (Vivek Gupta) - 30 min >> >>=============================================================== >>========= >>================== >> >>Conference details: >>US dial-in: +1 972 894 6500 >> >>Conference ID: 57113 >> >>PIN: 53187 >> >
21-05-0408-01-0000-IETFInvolvment_sfa.ppt