Subject: RE: [MIPSHOP-MIH-DT] hi everyone

From: Sam Xia <[email-masked]>
Date: Thu, 17 May 2007 15:42:06 +0800

hi folks,
 
I am thinking of the two topics mentioned by Robert. And i have some
premature thoughts.
 
1:  whether we felt whatever discovery mechanism we select/adapt needs to be
able to find multiple serving nodes for whatever we are asked to discover.
 
i don't think it is necessary that whatever discovery mechanism we select
has the ability to find multiple serving nodes for what the uses want to
know. since at present there are a lot of kinds of networks, the situation
discovering mih serving network nodes is very complicated, as may be
different in different access networks. AFAIK, there are a lot of candidate
solution for discovering procedure (see design consideration for common
MIH). These solutions may be used in different access netowrks. For example,
maybe one method is used, or two methods in bundle are used at the same
time. My belief is that we should not make any assumption about how the
operators deploy their access network. And i argue that it is very
reasonable that there should exist several discovering mechanisms at the
same access network at the same time, each of which plays different role to
find the corrresponding serving node. Of course, one mechanism should
support to discovering all serving node.
 
And i am considering the necessarity to design a new discovering mechanism
at this moment, even .21 asks us to do so. AFAIK, while mobile node moves to
a new network, there should be a configuration procedure in advace.
Particularly in heterogenious networks, IP configureation prodedure is
necessary when mobile node is IP capable. i think that it is very possible
to integrate the discovering procedure to these configuration
procedure(link/ip/service configuration procedure).
 
2: about the transportation attributes
i agree that there should be different attributes for different attributes.
in .21, ACK mechanism is used for MIH service; so reliability may be assured
by the MIH services themself. Fragmentation issue is listed but not
specified in .21. I don't know whether MIH services will support
fragmentation function. In general, the transportation should includes the
following:
a: reliability/unreliability;
b: fragmentation/unfragmentation;
c: urgent/unurgent;
 
3: whether the transportation protocol is designed only for .21
i wish the protocol can be used for other purposes, such as ar-info
collection.

 Best Regards, Sam Xia 

  _____  

From: Robert Hancock [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 1:13 AM
To: 'Telemaco Melia'; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] hi everyone

hi tele, all,
 
thanks for the ping, now we are all (just about) recovered from the ietf. 
 
in terms of issues to attack, i think it would be good to handle the
discovery/"service" identifier topics, since I think we were getting pretty
close to a common understanding in prague. the main open point I think was
whether we felt whatever discovery mechanism we select/adapt needs to be
able to find multiple serving nodes for whatever we are asked to discover.
 
the other topic we could continue in parallel would be the transport
attributes question. anyone want to take the token on that?
 
cheers,
 
r.

  _____  

From: Telemaco Melia [mailto:[email-masked]] 
Sent: 25 April 2007 18:09
To: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] hi everyone

Hi guys,

I was thinking that would be good to start writing some text based on the
slides Robert presented last meeting.
If people agree I can give a first attempt with a new doc. 

telemaco
[email-masked] wrote: 

I am too late to comment on the slides but they are mighty good. Great work.

Regards,
Srini

  _____  

From: ext Robert Hancock [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 10:44 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] hi everyone

it seems that the presentation was good enough for the audience ;-)
 
thanks everyone for all the time and effort that's been put in this week. i
think we got to know each other a lot better and also made real progress on
the technical work. now we just need to keep going.

i think dinner this evening has collapsed, partly through exhaustion and
partly more exciting offers - how people can think that a trip to the Prague
opera is more exciting than a mipshop discussion I do not know, but ... ;-)

but we will have another opportunity for a DT meal, at least in Chicago. see
you there!

cheers,

robert h.

  _____  

_______________________________________________

MIPSHOP-MIH-DT mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

-- 

Dr. Telemaco Melia			[email-masked]

Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142

NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155

Network Laboratories			Web: http://www.netlab.nec.de

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014 

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Sam Xia <[email-masked]>
Date: Wed, 23 May 2007 16:26:41 +0800

hi, everyone,
 
it has been silent for several weeks in the mailing list. i am afraid
whether we can come up with a good solution for mih transportation on time
before the next meeting. 

 Best Regards, Sam Xia 

  _____  

hi tele, all,

 
 
cheers,
 
r.

  _____  

Hi guys,

telemaco

Regards,
Srini

  _____  

 

cheers,

robert h.

  _____  

[email-masked]

-- 

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 23 May 2007 19:26:45 +0200

Hi Sam,

Please see comments in line

Sam Xia wrote:
> 1:  whether we felt whatever discovery mechanism we select/adapt needs 
> to be able to find multiple serving nodes for whatever we are asked to 
> discover.
>  
> i don't think it is necessary that whatever discovery mechanism we 
> select has the ability to find multiple serving nodes for what the 
> uses want to know. since at present there are a lot of kinds of 
> networks, the situation discovering mih serving network nodes is very 
> complicated, as may be different in different access networks. AFAIK, 
> there are a lot of candidate solution for discovering procedure (see 
> design consideration for common MIH). These solutions may be used in 
> different access netowrks. For example, maybe one method is used, or 
> two methods in bundle are used at the same time. My belief is that we 
> should not make any assumption about how the operators deploy their 
> access network. And i argue that it is very reasonable that there 
> should exist several discovering mechanisms at the same access network 
> at the same time, each of which plays different role to find the 
> corrresponding serving node. Of course, one mechanism should support 
> to discovering all serving node.
>  
> And i am considering the necessarity to design a new discovering 
> mechanism at this moment, even .21 asks us to do so. AFAIK, while 
> mobile node moves to a new network, there should be a configuration 
> procedure in advace. Particularly in heterogenious networks, IP 
> configureation prodedure is necessary when mobile node is IP capable. 
> i think that it is very possible to integrate the discovering 
> procedure to these configuration procedure(link/ip/service 
> configuration procedure).
What do you mean here?
That through the IP configuration procedures you can bootstrap the 
discovery of MoS (MIHF)?
Or the IP configuration procedure can be used as a transport for 802.21 
discovery(i.e. IS)?
We could think to the first one as a potential trigger. But I would tend 
to disagree in using DHCP as a transport (recall the thread on the 
mailing list)
I could drawn a couple of scenarios and post them to trigger discussion. 
I ll do that tomorrow.
> i agree that there should be different attributes for different 
> attributes. in .21, ACK mechanism is used for MIH service; so 
> reliability may be assured by the MIH services themself. Fragmentation 
> issue is listed but not specified in .21. I don't know whether MIH 
> services will support fragmentation function. In general, the 
> transportation should includes the following:
I would add security requirements.
> i wish the protocol can be used for other purposes, such as ar-info 
I have been triggering the attention of the chairs already. It appears 
to be an issue not yet  solved...

telemaco
>
>  Best Regards, Sam Xia
>
> ------------------------------------------------------------------------
> *From:* Robert Hancock [mailto:[email-masked]]
> *Sent:* Thursday, April 26, 2007 1:13 AM
> *To:* 'Telemaco Melia'; [email-masked]
> *Subject:* RE: [MIPSHOP-MIH-DT] hi everyone
>
>     hi tele, all,
>      
>     in terms of issues to attack, i think it would be good to handle
>     the discovery/"service" identifier topics, since I think we were
>     getting pretty close to a common understanding in prague. the main
>     open point I think was whether we felt whatever discovery
>     mechanism we select/adapt needs to be able to find multiple
>     serving nodes for whatever we are asked to discover.
>      
>     the other topic we could continue in parallel would be the
>     transport attributes question. anyone want to take the token on that?
>      
>     cheers,
>      
>     r.
>
>         ------------------------------------------------------------------------
>         *From:* Telemaco Melia [mailto:[email-masked]]
>         *Sent:* 25 April 2007 18:09
>         *To:* [email-masked]
>         *Subject:* Re: [MIPSHOP-MIH-DT] hi everyone
>
>         Hi guys,
>
>         I was thinking that would be good to start writing some text
>         based on the slides Robert presented last meeting.
>>         ------------------------------------------------------------------------
>>         *From:* ext Robert Hancock [mailto:[email-masked]]
>>         *Sent:* Thursday, March 22, 2007 10:44 AM
>>         *To:* [email-masked]
>>         *Subject:* [MIPSHOP-MIH-DT] hi everyone
>>
>>         thanks everyone for all the time and effort that's been put
>>         in this week. i think we got to know each other a lot better
>>         and also made real progress on the technical work. now we
>>         just need to keep going.
>>         i think dinner this evening has collapsed, partly through
>>         exhaustion and partly more exciting offers - how people can
>>         think that a trip to the Prague opera is more exciting than a
>>         mipshop discussion I do not know, but ... ;-)
>>         but we will have another opportunity for a DT meal, at least
>>         in Chicago. see you there!
>>         cheers,
>>         robert h.
>>         ------------------------------------------------------------------------
>>