Subject: [MIPSHOP-MIH-DT] about next step

From: Sam Xia <[email-masked]>
Date: Wed, 07 Mar 2007 09:32:39 +0800

HI, Robert,
  From the recent mailing discussion, I drew a conclusion that the DC is
coverd by the MIH protocol which includes the common functionaltion of
transportation. But apparently, it is not very clear how the MIH protocl
deal with some issues specified in the DC. How about the next step? Any
comments?

 Best Regards, Sam Xia

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

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 07 Mar 2007 11:42:15 +0100

Hi all,

While going through the emails I just collected few points summarizing 
the status of the discussion.
I think it would be good to decide whether each of the listed issues is 
still relevant and which issue has a greater priority for the upcoming 
meeting.
To make our life easier I would be in favor of opening a tread for each 
of the issue and try to get a consensus before the meeting. this should 
give some time to better shape the presentation.

Views?

Here is the list:
Issue #1: Protocol Split
It looks like there is not yet a consensus.
The PS document, as Juan already pointed out, generally defines the 
splitting.
I think we should keep in mind that the solution we are designing could 
be used
by any other Mobility Support Service. We should ensure flexibility by 
clearly
splitting the information and information exchange mechanisms. I think this
is directly connected to what Srini says about state management Quoting 
some text
form a previous email: "There could be state-information related to 
transport
establishment and maintenance which is independent of Mih state machine."
General comment: make more clear what it is the common part.

Issue #2: Routing along multiple nodes
It seems we got consensus. Next we should sketch scenarios.

Issue #3: Naming and discovery
All agree that the transport should support discovery.
Naming is probably not required though (Subir's comment)

Issue #4: Secure Discovery
This is not a requirement

Issue #5: Localization
It seems we got to an agreement

Issue #5: Signaling peer changes
It seems this requires more discussions concerning whether the transport 
should be informed or not.

Issue #6: Message transport
It looks like different services could require different transport options.
Still need to investigate the role of fragmentation and in-order packet 
delivery.
(see transaction IDs). clarify also the relation with duplication detection.

Issue #7: State Management
See issue #1 about transport maintenance states.
Not yet consensus. Define transport error handling.

Issue#8: MIH versioning
Looks like solved.

cheers
telemaco

-- 
Telemaco Melia          	[email-masked]
Research Staff Member		Tel: +49 (0) 6221 4342- 142
Network Laboratories    	Fax: +49 (0) 6221 4342- 155
NEC Europe Ltd.         	Web: http://www.netlab.nec.de
Network Laboratories           
Kurfuersten-Anlage 36       
69115 Heidelberg
GERMANY   

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

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 7 Mar 2007 09:43:02 -0500

Hi Telemaco,

Thanks for the summary. This will make our life much easier.

Please see comments below for Issue #1: Protocol Split

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

Hi all,

Views?

Here is the list:

Issue #1: Protocol Split
It looks like there is not yet a consensus.
The PS document, as Juan already pointed out, generally defines the 
splitting.
I think we should keep in mind that the solution we are designing could 
be used
by any other Mobility Support Service. We should ensure flexibility by 
clearly
splitting the information and information exchange mechanisms. I think
this
is directly connected to what Srini says about state management Quoting 
some text
form a previous email: "There could be state-information related to 
transport
establishment and maintenance which is independent of Mih state
machine."
General comment: make more clear what it is the common part.

JCZ> I still have problems with the phrase "We should ensure flexibility
by clearly splitting the information and information exchange mechanisms
"
I like flexibility, but there is an associated cost of complexity. If we
are going to design a transport and discovery mechanism for MIH 802.21
that can be reused by other mobility services, I'm all for it. However,
if we are going to design something that fits any mobility support
service, then I have some problems, since this latter most likely will
impose more constraints to our design than needed (e.g. by 802.21
alone).
There is already a liaison with 802.21 and we already have a draft
specification that we can use as baseline. I think that there is no need
to expand the scope, especially at the risk of further delaying the work
at MIPSHOP.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 7 Mar 2007 09:49:52 -0500

Hi,

Please see below for some comments on Issue #6: Message transport

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

Issue #6: Message transport
It looks like different services could require different transport
options.
Still need to investigate the role of fragmentation and in-order packet 
delivery.
(see transaction IDs). clarify also the relation with duplication
detection.

JCZ> I think that most comments were about specific services being
transparent to the transport. This to me means that all services should
use a common transport and no specifics should be defined for each
service, especially if the service and contents is hidden to the
transport.

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 09:10:34 -0600

Hi Juan, 

>I think that there is no need to expand the scope, especially at the
risk of further delaying the work at MIPSHOP.

I think there may be a confusion on the use of the "flexibility" phrase.
It should be read as the general separation between the MIH-protocol and
the transport that carries the MIH-protocol. It only means, to me, that
the Mih service protocol is opaque to the transport that will be
designed to carry it. This is essentially the basic requirement that
came from 802.21 WG. So the intention is not to be generic for all
mobility services but various various services within the 802.21
protocol (i.e. IS, ES and CS).

Regards,
Srini 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 8:43 AM
To: Telemaco Melia; Sam Xia
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #1: Protocol Split

Hi Telemaco,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

Hi all,

Views?

Here is the list:

Issue #1: Protocol Split
It looks like there is not yet a consensus.
The PS document, as Juan already pointed out, generally defines the
splitting.
I think we should keep in mind that the solution we are designing could
be used by any other Mobility Support Service. We should ensure
flexibility by clearly splitting the information and information
exchange mechanisms. I think this is directly connected to what Srini
says about state management Quoting some text form a previous email:
"There could be state-information related to transport establishment and
maintenance which is independent of Mih state machine."
General comment: make more clear what it is the common part.

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 09:16:43 -0600

Some comments below.

Regards,
Srini 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 8:50 AM
To: Telemaco Melia; Sam Xia
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #6: Message transport

Hi,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

SS> The transport will be transparent to the payload but how the
transport is used is left to the user of the transport. Even now, there
are transports that offer more than one way to use it. A simple example
is if the transport could be setup as connnection or datagram oriented.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 7 Mar 2007 10:16:38 -0500

Hi Srini,

Thanks for the clarification. If that is the case, then I think that we
are closer to having consensus on that one too :)

Cheers,

Jc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: March 7, 2007 10:11 AM
To: Zuniga, Juan Carlos; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #1: Protocol Split

Hi Juan, 

Regards,
Srini 

-----Original Message-----

Hi Telemaco,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

Hi all,

Views?

Here is the list:

Issue #1: Protocol Split

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 09:31:09 -0600

Hi Juan,

Glad we clarified that.
Regards,
Srini 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 9:17 AM
To: Sreemanthula Srinivas (Nokia-SIR/Dallas);
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #1: Protocol Split

Hi Srini,

Cheers,

Jc

-----Original Message-----

Hi Juan, 

Regards,
Srini 

-----Original Message-----

Hi Telemaco,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

Hi all,

Views?

Here is the list:

Issue #1: Protocol Split

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 7 Mar 2007 10:39:51 -0500

Some more comments.

Cheers,

Jc

-----Original Message-----
Sent: March 7, 2007 10:17 AM

Some comments below.

Regards,
Srini 

-----Original Message-----

Hi,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

JCZ> I agree, but to me those requirements still belong to the common
part and could be needed by any service (e.g. reliable/unreliable
transport).

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 09:48:30 -0600

Hi Juan,

-----Original Message-----
Sent: Wednesday, March 07, 2007 9:40 AM

Some more comments.

Cheers,

Jc

-----Original Message-----

Some comments below.

Regards,
Srini 

-----Original Message-----

Hi,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]]
Sent: March 7, 2007 5:42 AM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] about next step

SS2> true. We may be saying the same thing. There are no specifics
defined as to which service uses which. But the transport says these are
the options available in a some host specific means (or a standardized
api) that any one/service can use. The implementers can use these
options as they choose for different reasons. There is no specification
on how the options are used.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 7 Mar 2007 15:48:42 -0000

hi,

i was writing another reply but srini has said it well:

a) does the transport know what service is using it?
b) does the service know what transport functionality it is getting?

at a very high level, I would say that the answer to (a) is NO and the
answer to (b) is YES.

see further below:

> Sent: 07 March 2007 15:17
> To: [email-masked]; 
> Still need to investigate the role of fragmentation and 
> in-order packet delivery.
> transparent to the transport. This to me means that all 
> services should use a common transport and no specifics 
> should be defined for each service, especially if the service 
> and contents is hidden to the transport.
> 
> transport is used is left to the user of the transport. Even 
> now, there are transports that offer more than one way to use 
> it. A simple example is if the transport could be setup as 
> connnection or datagram oriented.

another (related) example, may be more directly tuned to signalling
behaviours:

a transport user may have a message for which the delivery requirement
is
"deliver this if you can, but if you cannot don't worry since i will be
sending another one soon which is more up to date", whereas it may have
another message for which the delivery requirement is "i want this
delivered, please make sure that it is or tell me if not".

it could send them both unreliably and handle retransmissions itself. on
the other hand, it is more efficient to handle retransmissions in the
transport (since the transport can typically adapt timers to be
aggressive about retransmissions while still being safe about
congestion, and also use windowing and other techniques to deliver
multiple messages in parallel).

so it's these sorts of things which I refer to as different transport
characteristics which may be required - the set of possibilities is not
very large (for GIST, the choice is basically reliable/unreliable, and
transmission priority).

robert h.

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 07 Mar 2007 17:21:23 +0100

Hi Robert,

Please see below.

cheers
telemaco

> multiple messages in parallel).
[tele] It  could be the case that a specific service (e.g. ES) prefers 
retransmission to be manged not in the transport.
For instance, if an event packet is lost the retransmitted packet could 
contain an updated value field assuring therefore freshness
of reported information to an MIH peer. If retransmission is managed 
only at the transport layer this would not be possible.
Unless you do not notify the service.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Mar 2007 16:57:33 -0000

hi,

just to chime in: i think Juan Carlos has expressed it pretty well:

"If we are going to design a transport and discovery mechanism for MIH
802.21 that can be reused by other mobility services, I'm all for it." 

I don't think we should be planning to produce a totally general purpose
mobile network signalling protocol. I'm not sure how we would scope the
requirements for such a thing anyway. I do think there may be other
users of our output than .21 ES/CS/IS, but actually ES/CS/IS already
present quite a range of requirements: a solution which supports them
will support other things nearly automatically (certainly I think it
covers a fair range of transport requirements). 

The real question is: exactly how open do we think .21 deployment models
will be. That relates strongly to discovery issues in particular.

Maybe it would be helpful (or at least reassuring) to list some
non-goals: not on my list would be
*) context transfer
*) data plane re-routing
*) state pre-installation post-handover (e.g. pro-active QoS setup)
If it turned out that we could do these with our solution basically 'for
free' then OK; but that seems unlikely, and in any case not something we
should be worrying about now.

*** the follow-up question ***
- does anyone feel like writing some text which somehow captures this
aspect of what we are trying to do? it could be an update/replacement to
section 2 of the DC draft (or at least some sections of it). 
(generically: do people want me to do the drafting, or do they want to
volunteer, or do they want to be asked, or ...)

robert h.

> Sent: 07 March 2007 15:31
> Thanks for the clarification. If that is the case, then I 
> think that we are closer to having consensus on that one too :)
> 
> Cheers,
> 
> Jc
> 
> It should be read as the general separation between the 
> MIH-protocol and the transport that carries the MIH-protocol. 
> It only means, to me, that the Mih service protocol is opaque 
> to the transport that will be designed to carry it. This is 
> essentially the basic requirement that came from 802.21 WG. 
> So the intention is not to be generic for all mobility 
> services but various various services within the 802.21 
> While going through the emails I just collected few points 
> summarizing the status of the discussion.
> I think it would be good to decide whether each of the listed 
> issues is still relevant and which issue has a greater 
> priority for the upcoming meeting.
> To make our life easier I would be in favor of opening a 
> tread for each of the issue and try to get a consensus before 
> the meeting. this should give some time to better shape the 
> presentation.
> 
> Views?
> 
> Here is the list:
> 
> Issue #1: Protocol Split
> The PS document, as Juan already pointed out, generally 
> defines the splitting.
> I think we should keep in mind that the solution we are 
> designing could be used by any other Mobility Support 
> Service. We should ensure flexibility by clearly splitting 
> the information and information exchange mechanisms. I think 
> this is directly connected to what Srini says about state 
> management Quoting some text form a previous email:
> "There could be state-information related to transport 
> by clearly splitting the information and information exchange 
> mechanisms "
> I like flexibility, but there is an associated cost of 
> complexity. If we are going to design a transport and 
> discovery mechanism for MIH 802.21 that can be reused by 
> other mobility services, I'm all for it. However, if we are 
> going to design something that fits any mobility support 
> service, then I have some problems, since this latter most 
> likely will impose more constraints to our design than needed 
> (e.g. by 802.21 alone).
> There is already a liaison with 802.21 and we already have a 
> draft specification that we can use as baseline. I think that 
> there is no need to expand the scope, especially at the risk 
> of further delaying the work at MIPSHOP.
>

---

From: Subir Das <[email-masked]>
Date: Mon, 12 Mar 2007 14:19:11 -0400

> on how the options are used.
  Subir>  I mostly agree things that are discussed on this thread but 
didn't understand the following part:

"But the transport says these are
the options available in a some host specific means (or a standardized
api) that any one/service can use." 

Are we trying to standardize the API? Also is it possible to elaborate more on 
host specific options?

---

From: Subir Das <[email-masked]>
Date: Mon, 12 Mar 2007 14:54:33 -0400

> at a very high level, I would say that the answer to (a) is NO and the
  Subir> Good points.  I agree with you on (a).  When you say  the 
answer to (b) is yes, do you
             mean at the implementation/integration level  or at the 
protocol  protocol level?

  In general, it seems to me that we are using MIH services and MIH 
protocol interchangeably.
  It would be helpful if we all are in the same page on this. Here is my 
understanding:

 MIH protocol will use the transport for transporting things remotely. 
Towards this, transport protocol/layer
 will receive a packet from MIH protocol and it knows where to transport 
it. What is included within
 MIH protocol frame is not known ( unless we understand the reason why 
it needs to know) by the transport.
 And, MIH service is included with the MIH protocol frame. Only MIH 
protocol knows about the service.

Views?

---

From: Subir Das <[email-masked]>
Date: Mon, 12 Mar 2007 15:46:00 -0400

> covers a fair range of transport requirements). 
  Subir> I agree. Do we need to call it a mobile network signaling 
protocol?  IMO, Network signaling
             protocol has more than just the transport component. I 
assume you meant only the transport
             part.
> should be worrying about now.
  Subir>  I agree.
> volunteer, or do they want to be asked, or ...)
 Subir> When are we planning to update the draft?  Either way should be 
fine,  IMO.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 12 Mar 2007 19:40:29 -0400

Some comments below:

-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: March 12, 2007 2:55 PM
To: Hancock, Robert
Cc: [email-masked]; Zuniga, Juan Carlos;
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message transport

understanding:

Views?

JCZ> I agree with Subir's view. 
I'm also not very comfortable with mixing these two. We should be
worried about the transport of an MIH Protocol, and the services inside
this protocol one are not relevant. The different services impose
different requirements, true, but they should all be taken as a single
set of MIH requirements by the transport, and not individually. We
should keep in mind that the transport has no view of what goes inside
the MIH Protocol.

---

From: <[email-masked]>
Date: Mon, 12 Mar 2007 23:53:32 -0500

Hi Subir,
Just to understand clearly what your are saying with -

Are you saying that mih protocol is different from mih service? Mih
service defines the mih protocol. Or do you mean the common message
header and format for es/cs/is as the mih protocol? We should not
differentiate the two for MIPSHOP purposes. 

Either way, we all seem to agree that mih service protocol is not known
to the transport and seen as a transport payload. E.g. like UDP not
knowing about RTP. The reverse, RTP knowing that it utilizes UDP may be
true. So is the case here, MIH service protocol knows the transport
functions it may be using. In other words, the transport exports a
single set of transport services to the MIH service protocol layer. But
different MIH service protocol may use only what is needed for its
functionality. But, generally, I agree with the sentiment that this
aspect is not necessary for transport design but captured only to ensure
that a rich set of transport functions (and the APIs) are defined and
exported to its users (MIH layer).

Regards,
Srini

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 1:55 PM
To: Hancock, Robert
Cc: Sreemanthula Srinivas (Nokia-SIR/Dallas);
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message transport

 MIH protocol will use the transport for transporting things remotely. 
Towards this, transport protocol/layer
 will receive a packet from MIH protocol and it knows where to transport
it. What is included within  MIH protocol frame is not known ( unless we
understand the reason why it needs to know) by the transport.
 And, MIH service is included with the MIH protocol frame. Only MIH
protocol knows about the service.

Views?

---

From: Sam Xia <[email-masked]>
Date: Tue, 13 Mar 2007 19:49:16 +0800

Hi, Srubuvas,
 Please see inline.
 Best Regards, Sam Xia 

> Sent: Tuesday, March 13, 2007 12:54 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; 

Sam> I think  that .21 defines MIH services and MIH protocol which is
focusing on common message header/format as well as some transportation
sequences. MIH protocol is different than MIH servies. But I don't disagree
that we shoud look at the two things as a one, particularly in MIPSHOP. 

> exported to its users (MIH layer).
Sam> Agree. One more comment:
 MIH protocol defines some certain fields, i.e. "Transaction ID" and
"Fragment Flag" etc. which are very related with and impose on the transport
designing. But how to utilize these fields and functions is not defined very
clearly in the .21 draft. Here, I just want to say that MIH protocol is
somewhat overlapped with transportation  functionality.

---

From: Subir Das <[email-masked]>
Date: Tue, 13 Mar 2007 09:34:38 -0400

> differentiate the two for MIPSHOP purposes. 
     What I was trying to say is that MIH service is using the MIH 
protocol and therefore, MIH
      protocol is what we need to know. Do we care about what service is 
carried over this protocol
      unless we change the header and format of MIH protocol in MIPSHOP 
or we find different
      distinct requirements for different services from .21?  MIH 
service is a functional  entity
      and MIH is a protocol and the moment we combine this, it seems to  
be that we are combining
      the application and the underlying protocol. IMO, we should 
differentiate this from protocol
      design aspect. However, I would like to hear from you why do you 
think that "we should not
     differentiate the two for MIPSHOP putposes"
> knowing about RTP.  
   MIH service protocol seems to me a better name....
> The reverse, RTP knowing that it utilizes UDP may be
> true. 
   Even if this is true, how does it affect  UDP design? My point is: 
should we consider this
   a requirement for UDP?
> So is the case here, MIH service protocol knows the transport
> single set of transport services to the MIH service protocol layer. 
   I agree.
> But
     Correct.

   regards,
   -Subir

---

From: <[email-masked]>
Date: Tue, 13 Mar 2007 09:23:44 -0500

>I would like to hear from you why do you think that "we should not
Subir,

Because the transport neither have to know the MIH header nor the
service-type identifier in the MIH header. It receives a payload of
arbitrary size and a destination transport address. We all agree this
transparency. Let's talk f2f.

Regards,
Srini

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 8:35 AM
To: Sreemanthula Srinivas (Nokia-SIR/Dallas)
Cc: [email-masked]; [email-masked];

> Either way, we all seem to agree that mih service protocol is not 
> known to the transport and seen as a transport payload. E.g. like UDP 
> not knowing about RTP.
> The reverse, RTP knowing that it utilizes UDP may be true.
   I agree.
> aspect is not necessary for transport design but captured only to 
> ensure that a rich set of transport functions (and the APIs) are 
> defined and exported to its users (MIH layer).
>   
     Correct.

   regards,
   -Subir

> Towards this, transport protocol/layer  will receive a packet from MIH

> protocol and it knows where to transport it. What is included within

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 13 Mar 2007 17:26:46 +0100

Robert,

Please see below.

> 802.21 that can be reused by other mobility services, I'm all for it." 
[tele] agreed
> should be worrying about now.
[tele] agreed
> volunteer, or do they want to be asked, or ...)
[tele] if next week we agree on sharing the work and assign tasks I am 
willing to take over part of the editorial work.

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 13 Mar 2007 17:51:06 +0100

And i think this is in line with the PS document (section 5.1).

tele

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 13 Mar 2007 18:07:10 +0100

Srini,

I think it would be great if we could have a list of options the MIH 
layer could configure into the transport layer.
Some time ago Robert already mentioned the example of GIST (connection 
oriented transport vs non connection oriented transport).
I would proceed along these lines.

Comments?

telemaco

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 13 Mar 2007 17:39:27 -0000

hi everyone,
 
i changed the subject line to cover a specific subject which a lot of
the mails in this thread seem to have been covering.
 
i think that we are basically all saying the same thing (or at least
compatible things) here but with different terminology. i take some
blame for that, since the DC draft uses rather obscure terminology for
the various components of the problem.
 
i think, as Tele says, the scope of our work is to solve the problem
posed in the PS draft: basically, using the terminology of that draft,
we have to come up with a solution for the MSTP; this includes defining
the upper interface that the MSTP provides to signalling protocols, but
not those signalling protocols themselves.
 
for accessibility of our work to the IETF, we should probably stick to
the final terminology of the PS draft. Probably we should avoid terms
like 'MIH protocol' altogether.
 
(i think there are some ways in which the PS terminology could be
improved, but i'll send those directly to the mipshop list.)
 
robert h.
 
PS good to see the level of participation - the CC list includes almost
the whole DT ...

________________________________

	From: Telemaco Melia [mailto:[email-masked]] 
	Sent: 13 March 2007 16:51
	To: [email-masked]
	Cc: [email-masked]; Hancock, Robert;
[email-masked]; [email-masked];
[email-masked]
	Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message transport

	tele

		Hi Subir,

			In general, it seems to me that we are using MIH
services and MIH 

		Are you saying that mih protocol is different from mih
service? Mih
		service defines the mih protocol. Or do you mean the
common message
		header and format for es/cs/is as the mih protocol? We
should not
		differentiate the two for MIPSHOP purposes. 
		
		Either way, we all seem to agree that mih service
protocol is not known
		to the transport and seen as a transport payload. E.g.
like UDP not
		knowing about RTP. The reverse, RTP knowing that it
utilizes UDP may be
		true. So is the case here, MIH service protocol knows
the transport
		functions it may be using. In other words, the transport
exports a
		single set of transport services to the MIH service
protocol layer. But
		different MIH service protocol may use only what is
needed for its
		functionality. But, generally, I agree with the
sentiment that this
		aspect is not necessary for transport design but
captured only to ensure
		that a rich set of transport functions (and the APIs)
are defined and
		exported to its users (MIH layer).
		
		Regards,
		Srini
		
		-----Original Message-----
		From: ext Subir Das
[mailto:[email-masked]] 
		Sent: Monday, March 12, 2007 1:55 PM
		To: Hancock, Robert
		Cc: Sreemanthula Srinivas (Nokia-SIR/Dallas);
		[email-masked];
[email-masked];
		[email-masked]; [email-masked]
		Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message
transport

		Hancock, Robert wrote:

			hi,
			
			i was writing another reply but srini has said
it well:
			
			a) does the transport know what service is using
it?
			b) does the service know what transport
functionality it is getting?
			
			at a very high level, I would say that the
answer to (a) is NO and the

			answer to (b) is YES.
			
			see further below:

		  Subir> Good points.  I agree with you on (a).  When
you say  the
		answer to (b) is yes, do you
		             mean at the implementation/integration
level  or at the
		protocol  protocol level?
		
		  In general, it seems to me that we are using MIH
services and MIH
		protocol interchangeably.
		  It would be helpful if we all are in the same page on
this. Here is my
		understanding:
		
		 MIH protocol will use the transport for transporting
things remotely. 
		Towards this, transport protocol/layer
		 will receive a packet from MIH protocol and it knows
where to transport
		it. What is included within  MIH protocol frame is not
known ( unless we
		understand the reason why it needs to know) by the
transport.
		 And, MIH service is included with the MIH protocol
frame. Only MIH
		protocol knows about the service.
		
		Views?

		

		

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 13 Mar 2007 19:08:21 -0000

hi,
 
partly as a direct response to Tele's request, but partly also wrapping
up some other discussions on the 'pure' transport engineering aspects:
 
- i think we have a view that the MSTP should support a set of transport
capabilities. MIH services/MSTP users are free to invoke those
capabilities as they see fit, and the MSTP doesn't care who is using it.
 
- the question is, when we say "capabilities", what do we actually mean?
 
we thought about this hard for GIST and the conclusions were as follows.
(this is not a statement that we should use GIST; it's just an analysis
about what is useful to expose at an API and what is not.)

*	
	There are various degrees of reliability that can be asked for.
The strongest request is 'deliver until it gets through or report an
error' (you always have to accept the possibility of an error). The
weakest is 'try but don't check'. Intermediate is 'try within a timeout
and tell me if you fail'. The difference between the first and third is
that errors for the first are usually pathological (e.g. destination has
exploded), whereas the timeouts in the third could be small. 
*	
	In the reliable case, you could say whether you want messages
delivered in order or not. Ordering can be important if you are using
compression, or if different messages have inter-dependencies.
*	
	The transport could provide prioritisation.
*	
	The transport could provide message boundaries (saying where
each message starts).
*	
	The transport could protect the receiving endpoint (by imposing
flow control back to the sender).
*	
	The transport could fragment and re-assemble large messages.
*	
	The transport could protect the network (by imposing congestion
control).

The GIST API explicitly does the first three (the third is just an
implementation issue, not part of the protocol). It also implicitly does
the next two. It doesn't 'do' the last two: if the message needs
fragmentation and reassembly this just happens invisibly, as does
congestion control.
 
Tele raised a question about: if there is a retransmission, what is
retransmitted? Logically, it's possible to update the data to be
transmitted (rather than retransmitting the old data), and this would
seem to give some gain in responsiveness. However, note that no current
transport protocols allow such behaviour, and it would be quite
difficult to specify and implement. My analysis is that it is not really
valuable, and runs as follows:

*	
	if you care about the up-to-date-ness of data, you are
presumably transmitting it periodically, let's say with period T
*	
	if the one-way delay is then D, you can show that the mean
out-of-date-ness of the data at the receiver is(D+T/2)
*	
	if you retransmit once without refresh, this becomes (3D+T/2)
for that period, so the proportional change is 4D/T (assuming D << T).
*	
	and you only lose this for that period, i.e. with probability P
(probability of message loss)
*	
	in other words, the inefficiency from not refreshing the data is
4PD/T. 
*	
	under reasonable assumptions, that is a very small gain. For
example, if delay is probably dominated by packetisation, D/T is equal
to the overhead on the link caused by the reporting messages, so one
would hope that D<<T. And a P of 10% is big (probably means the network
is hard to use for other things). So to get a 4PD/T of even 1% would be
unusual.

The other aspect that has been raised is that the .21 specification has
some things in it which might overlap with the above MSTP functions.
Note that the .21 standard has to include some functions for the case
where the messages are being transferred directly at layer 2, and those
functions have some superficial similarity to the L3 transfer case.
However, the implementation complexity of those functions could be quite
different between the two cases. Some examples:

*	
	fragmentation is easy for the L2 case, because you directly know
the limitations imposed by the attached link. For L3, you can need extra
protocol support to find the MTU along the path. At least, the MTU
restrictions are quite different. (We also shouldn't forget that
reassembly is a subtle problem, open to a number of DoS attacks, for
which re-use of standard IETF solutions is attractive.)
*	
	congestion control is easy for the L2 case, because you can
sense the load on the attached link. Again in the L3 case you have to
know the congestion over the path.
*	
	ordering is easy in the L2 case, since re-ordering can't take
place on a single link. It easily can on a more complex path.

So, I just want us to be cautious about assuming that just because .21
includes some functionality to address a message transfer problem, it
means that the problem is solved for the L3 transfer case. 
 
cheers,
 
r.

	Sent: 13 March 2007 17:07

	Srini,
	
	I think it would be great if we could have a list of options the
MIH layer could configure into the transport layer.
	Some time ago Robert already mentioned the example of GIST
(connection oriented transport vs non connection oriented transport).
	I would proceed along these lines.
	
	Comments?
	
	telemaco

			I would like to hear from you why do you think
that "we should not

		Because the transport neither have to know the MIH
header nor the
		service-type identifier in the MIH header. It receives a
payload of
		arbitrary size and a destination transport address. We
all agree this
		transparency. Let's talk f2f.
		
		Regards,
		Srini
		
		-----Original Message-----
		From: ext Subir Das
		Cc: [email-masked];

			Hi Subir,
			Just to understand clearly what your are saying
with -

				In general, it seems to me that we are
using MIH services and MIH

			Are you saying that mih protocol is different
from mih service? Mih 
			service defines the mih protocol. Or do you mean
the common message 
			header and format for es/cs/is as the mih
protocol? We should not 
			differentiate the two for MIPSHOP purposes.

		     What I was trying to say is that MIH service is
using the MIH
		protocol and therefore, MIH
		      protocol is what we need to know. Do we care about
what service is
		carried over this protocol
		      unless we change the header and format of MIH
protocol in MIPSHOP
		or we find different
		      distinct requirements for different services from
.21?  MIH
		service is a functional  entity
		      and MIH is a protocol and the moment we combine
this, it seems to
		be that we are combining
		      the application and the underlying protocol. IMO,
we should
		differentiate this from protocol
		      design aspect. However, I would like to hear from
you why do you
		think that "we should not
		     differentiate the two for MIPSHOP putposes"

			Either way, we all seem to agree that mih
service protocol is not 
			known to the transport and seen as a transport
payload. E.g. like UDP 
			not knowing about RTP.

			The reverse, RTP knowing that it utilizes UDP
may be true.

		   Even if this is true, how does it affect  UDP design?
My point is: 
		should we consider this
		   a requirement for UDP?

			So is the case here, MIH service protocol knows
the transport 
			functions it may be using. In other words, the
transport exports a 
			single set of transport services to the MIH
service protocol layer.

		   I agree.

			But
			different MIH service protocol may use only what
is needed for its 
			functionality. But, generally, I agree with the
sentiment that this 
			aspect is not necessary for transport design but
captured only to 
			ensure that a rich set of transport functions
(and the APIs) are 
			defined and exported to its users (MIH layer).

		     Correct.
		
		   regards,
		   -Subir

			Regards,
			Srini
			
			-----Original Message-----
			From: ext Subir Das

			Hancock, Robert wrote:

				hi,
				
				i was writing another reply but srini
has said it well:
				
				a) does the transport know what service
is using it?
				b) does the service know what transport
functionality it is getting?
				
				at a very high level, I would say that
the answer to (a) is NO and 
				the

				answer to (b) is YES.
				
				see further below:

			  Subir> Good points.  I agree with you on (a).
When you say  the 
			answer to (b) is yes, do you
			             mean at the
implementation/integration level  or at the 
			protocol  protocol level?
			
			  In general, it seems to me that we are using
MIH services and MIH 
			protocol interchangeably.
			  It would be helpful if we all are in the same
page on this. Here is 
			my
			understanding:
			
			 MIH protocol will use the transport for
transporting things remotely.

			Towards this, transport protocol/layer  will
receive a packet from MIH

			protocol and it knows where to transport it.
What is included within  
			MIH protocol frame is not known ( unless we
understand the reason why 
			it needs to know) by the transport.
			 And, MIH service is included with the MIH
protocol frame. Only MIH 
			protocol knows about the service.
			
			Views?

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 13 Mar 2007 14:31:52 -0400

Hi Robert,

I agree with you that we need to have a common terminology in all
documents. However, I believe that we should actually refer to MIH
Protocol (like it is currently done in 802.21) and instead avoid terms
like MIH Services, which to me are adding more confusion in this group.

Since we are now in last call for the PS, the timing is perfect to clean
the terminology there too. Then in the future (ie once the PS is
accepted) we can stick to it. 

Jc

From: Hancock, Robert [mailto:[email-masked]] 
Sent: March 13, 2007 1:39 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] protocol terminology (was: Issue #6:
Messagetransport)

hi everyone,

robert h.

	

	
	tele

	Hi Subir,

	 
	Are you saying that mih protocol is different from mih service?
Mih
	service defines the mih protocol. Or do you mean the common
message
	header and format for es/cs/is as the mih protocol? We should
not
	differentiate the two for MIPSHOP purposes. 
	 
	Either way, we all seem to agree that mih service protocol is
not known
	to the transport and seen as a transport payload. E.g. like UDP
not
	knowing about RTP. The reverse, RTP knowing that it utilizes UDP
may be
	true. So is the case here, MIH service protocol knows the
transport
	functions it may be using. In other words, the transport exports
a
	single set of transport services to the MIH service protocol
layer. But
	different MIH service protocol may use only what is needed for
its
	functionality. But, generally, I agree with the sentiment that
this
	aspect is not necessary for transport design but captured only
to ensure
	that a rich set of transport functions (and the APIs) are
defined and
	exported to its users (MIH layer).
	 
	Regards,
	Srini
	 
	-----Original Message-----
	From: ext Subir Das [mailto:[email-masked]] 
	Sent: Monday, March 12, 2007 1:55 PM
	To: Hancock, Robert
	Cc: Sreemanthula Srinivas (Nokia-SIR/Dallas);
	[email-masked];

	Hancock, Robert wrote:

		hi,

		a) does the transport know what service is using it?
		b) does the service know what transport functionality it
is getting?
		 
		at a very high level, I would say that the answer to (a)
is NO and the

		answer to (b) is YES.
		 
		see further below:

	  Subir> Good points.  I agree with you on (a).  When you say
the
	answer to (b) is yes, do you
	             mean at the implementation/integration level  or at
the
	protocol  protocol level?
	 
	  In general, it seems to me that we are using MIH services and
MIH
	protocol interchangeably.
	  It would be helpful if we all are in the same page on this.
Here is my
	understanding:
	 
	 MIH protocol will use the transport for transporting things
remotely. 
	Towards this, transport protocol/layer
	 will receive a packet from MIH protocol and it knows where to
transport
	it. What is included within  MIH protocol frame is not known (
unless we
	understand the reason why it needs to know) by the transport.
	 And, MIH service is included with the MIH protocol frame. Only
MIH
	protocol knows about the service.
	 
	Views?

---

From: Subir Das <[email-masked]>
Date: Tue, 13 Mar 2007 18:15:00 -0400

Hi Telemaco,
I would like to understand what you are referring to here.
Why MIH layer needs to configure the transport layer? 

regards,
-Subir

---

From: <[email-masked]>
Date: Tue, 13 Mar 2007 23:51:47 -0500

Hi Telemaco,
I think Robert captures the points better than we could in this group
based on the experience the NSIS WG had in this area. If I were to pick
and choose for MIH use, they would be.
 
1. underlying transport connection (tcp/udp)
2.in-order delivery
3. prioritization
4. fragmentation and reassembly
 
Robert, you said "if the message needs fragmentation and reassembly this
just happens invisibly, as does congestion control"
 
you mean as in, IP level fragmentation? Are these fragments firewall/nat
traversal safe?
 
Regards,
Srini

From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 12:07 PM
To: Sreemanthula Srinivas (Nokia-SIR/Dallas)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message transport

Srini,

Comments?

telemaco

		I would like to hear from you why do you think that "we
should not

	Because the transport neither have to know the MIH header nor
the
	service-type identifier in the MIH header. It receives a payload
of
	arbitrary size and a destination transport address. We all agree
this
	transparency. Let's talk f2f.
	
	Regards,
	Srini
	
	-----Original Message-----
	From: ext Subir Das [mailto:[email-masked]] 
	Sent: Tuesday, March 13, 2007 8:35 AM
	To: Sreemanthula Srinivas (Nokia-SIR/Dallas)
	Cc: [email-masked];

		Hi Subir,

		

	     What I was trying to say is that MIH service is using the
MIH
	protocol and therefore, MIH
	      protocol is what we need to know. Do we care about what
service is
	carried over this protocol
	      unless we change the header and format of MIH protocol in
MIPSHOP
	or we find different
	      distinct requirements for different services from .21?
MIH
	service is a functional  entity
	      and MIH is a protocol and the moment we combine this, it
seems to
	be that we are combining
	      the application and the underlying protocol. IMO, we
should
	differentiate this from protocol
	      design aspect. However, I would like to hear from you why
do you
	think that "we should not
	     differentiate the two for MIPSHOP putposes"

		Either way, we all seem to agree that mih service
protocol is not 
		known to the transport and seen as a transport payload.
E.g. like UDP 
		not knowing about RTP.

	   Even if this is true, how does it affect  UDP design? My
point is: 
	should we consider this
	   a requirement for UDP?

		So is the case here, MIH service protocol knows the
transport 
		functions it may be using. In other words, the transport
exports a 
		single set of transport services to the MIH service
protocol layer.

	   I agree.

		But
		ensure that a rich set of transport functions (and the
APIs) are 

	     Correct.
	
	   regards,
	   -Subir

		Regards,
		Srini
		
		-----Original Message-----
		From: ext Subir Das

		Hancock, Robert wrote:

			hi,

			
answer to (a) is NO and 
			the

			answer to (b) is YES.
			
			see further below:

		
this. Here is 
		my
		understanding:

	

		Towards this, transport protocol/layer  will receive a
packet from MIH

		protocol and it knows where to transport it. What is
included within  
		MIH protocol frame is not known ( unless we understand
the reason why 
		it needs to know) by the transport.
		 And, MIH service is included with the MIH protocol
frame. Only MIH 
		protocol knows about the service.
		
		Views?

		

		

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: Telemaco Melia <[email-masked]>
Date: Wed, 14 Mar 2007 09:57:33 +0100

Hi Srini,

I agree with your suggestions, though I have a couple of clarifications:
- in case the MSSL (Mobility Service Signaling Layer) disables the ACK 
mechanism would the MSTP be notified then?
- what about MSSL discovery mechanisms not in the same broadcast domain? 
(section 8.3.1.1 of the .21 draftv4)

Thanks
Tele

[email-masked] wrote:
> based on the experience the NSIS WG had in this area. If I were to 
> pick and choose for MIH use, they would be.
>  
> Robert, you said "if the message needs fragmentation and reassembly 
> this just happens invisibly, as does congestion control"
>  
> you mean as in, IP level fragmentation? Are these fragments 
> firewall/nat traversal safe?
>  
> Regards,
> Srini
>  
>  
>
> ------------------------------------------------------------------------
> *From:* ext Telemaco Melia [mailto:[email-masked]]
> *Sent:* Tuesday, March 13, 2007 12:07 PM
> *To:* Sreemanthula Srinivas (Nokia-SIR/Dallas)
> *Cc:* [email-masked]; [email-masked]; 
> *Subject:* Re: [MIPSHOP-MIH-DT] Issue #6: Message transport
>
> Srini,
>

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 14 Mar 2007 10:50:22 +0100

Hi Robert,

I was thinking more about a threshold based mechanism than a periodic 
reporting system (bursts of reports could probably happen)
I am fine if people believe the issue should not be considered.

cheers,
telemaco
> seem to give some gain in responsiveness. However, note that no 
> current transport protocols allow such behaviour, and it would be 
> quite difficult to specify and implement. My analysis is that it is 
> not really valuable, and runs as follows:
>
>    *
>       example, if delay is probably dominated by packetisation, D/T is
>       equal to the overhead on the link caused by the reporting
>       messages, so one would hope that D<<T. And a P of 10% is big
>       (probably means the network is hard to use for other things). So
>       to get a 4PD/T of even 1% would be unusual.
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Mar 2007 18:43:59 -0000

so, we need a terminology proposal to feed into the PS discussion.
 
i think the main thing we need is a name for the 'thing which is our
solution'. in the PS draft, that's called the 'Mobility Services
Transport Protocol (MSTP)'. I don't think that's ideal, but we can come
back to that.
 
then we need a name for the things that use the MSTP. in the PS draft,
these are called Mobility Support Services (MSS). Maybe Mobility Support
Protocol (MSP) would be better.
 
then I see the MIH protocol as defined by 802.21 as a possible example
of an MSP. but I wouldn't want to say that these terms are identical:
- it implies that the MSTP is only ever used for MIH (not necessarily
true)
- the MIH protocol as defined by 802.21 is actually not purely an MSP.
for example, it also includes certain other functions when it runs over
layer 2, there are phrases like 'L2 MIH protocol', and so on. that stuff
is really totally orthogonal to our work, but if we say that a protocol
which includes L2 broadcast messages runs over the MSTP that will cause
confusion.
 
so i would prefer to say something like "an example of an MSP is the MIH
protocol of 802.21 when operating over L3 connectivity". and we could
just put that in the PS and then it is fixed.
 
one thing which is still unclear to me is whether the MIH protocol is
one MSP or three (or more), for IS/ES/CS; i would like to discuss that
in Prague. so there will still be some open aspects on that at least.
 
my real problem is with the term MSTP since it is not necessarily just a
Transport protocol. although transport (in the OSI layering sense, or
IETF area definition sense) is part of our problem, it is not
necessarily all of it. In particular, we also need to think about
security aspects and discovery aspects. But we never managed to think of
a better name during the NSIS work, so maybe we just have to live with
it.
 
robert h.

	From: Zuniga, Juan Carlos
[mailto:[email-masked]] 
	Sent: 13 March 2007 18:32
	To: Hancock, Robert; [email-masked]
	Subject: RE: [MIPSHOP-MIH-DT] protocol terminology (was: Issue
#6: Messagetransport)

	Hi Robert,

	I agree with you that we need to have a common terminology in
all documents. However, I believe that we should actually refer to MIH
Protocol (like it is currently done in 802.21) and instead avoid terms
like MIH Services, which to me are adding more confusion in this group.

	Since we are now in last call for the PS, the timing is perfect
to clean the terminology there too. Then in the future (ie once the PS
is accepted) we can stick to it. 

	Jc

	hi everyone,

	i changed the subject line to cover a specific subject which a
lot of the mails in this thread seem to have been covering.

	i think that we are basically all saying the same thing (or at
least compatible things) here but with different terminology. i take
some blame for that, since the DC draft uses rather obscure terminology
for the various components of the problem.

	i think, as Tele says, the scope of our work is to solve the
problem posed in the PS draft: basically, using the terminology of that
draft, we have to come up with a solution for the MSTP; this includes
defining the upper interface that the MSTP provides to signalling
protocols, but not those signalling protocols themselves.

	for accessibility of our work to the IETF, we should probably
stick to the final terminology of the PS draft. Probably we should avoid
terms like 'MIH protocol' altogether.

	(i think there are some ways in which the PS terminology could
be improved, but i'll send those directly to the mipshop list.)

	robert h.

	PS good to see the level of participation - the CC list includes
almost the whole DT ...

		From: Telemaco Melia
[mailto:[email-masked]] 

		And i think this is in line with the PS document
(section 5.1).
		
		tele

		Hi Subir,

		 

		Regards,
		Srini
		 
		-----Original Message-----
		From: ext Subir Das

		Hancock, Robert wrote:

			hi,

			 

			answer to (b) is YES.
			 
			see further below:

		 
		 
		Views?

		 

		 

		

		-- 
		Telemaco Melia
[email-masked]
		Research Staff Member        Tel: +49 (0) 6221 4342- 142
		Network Laboratories         Fax: +49 (0) 6221 4342- 155
		NEC Europe Ltd.              Web:
http://www.netlab.nec.de
		Network Laboratories           
		Kurfuersten-Anlage 36       
		69115 Heidelberg
		GERMANY   

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

---

From: Subir Das <[email-masked]>
Date: Wed, 14 Mar 2007 17:40:05 -0400

Robert,
Thanks for starting this discussion. I will send comments on PS draft.
But since you have started this thread I  will express my view.

-Subir

Hancock, Robert wrote:
> Transport Protocol (MSTP)'. I don't think that's ideal, but we can 
> come back to that.
    I agree.
> these are called Mobility Support Services (MSS). Maybe Mobility 
> Support Protocol (MSP) would be better.
  I also think we need to change the name.  PS draft mentions about 
802.21 services and there are no other example services, then why the 
name has been changed from Media Independent Services to Mobility 
Support Services. I understand that we are in IETF but we need to have 
some reasons. I do not think that Mobility Support Protocol is a good 
name either. Are we going to design another mobility protocol to support 
the existing mobility protocols? 
> for example, it also includes certain other functions when it runs 
> over layer 2, there are phrases like 'L2 MIH protocol', and so on. 
> that stuff is really totally orthogonal to our work, but if we say 
> that a protocol which includes L2 broadcast messages runs over the 
> MSTP that will cause confusion.
    Do we have other example services in our mind? I am not saying that 
we need to restrict only to .21 but at this moment, if we
    do not find any other use case, how do we envision our problem?
>  
> so i would prefer to say something like "an example of an MSP is the 
> MIH protocol of 802.21 when operating over L3 connectivity". and we 
> could just put that in the PS and then it is fixed.
    It  would be nice if we know what are the use cases we are targeting 
on.
> in Prague. so there will still be some open aspects on that at least.
   That 's what I was trying to convey for last few days. .21 MIH  
services (ES/CS/IS) use MIH protocol to exchange the messages between 
two MIH entities. Therefore MIH protocol is the one we should consider 
for our design (from .21 perspective). On the other hand, PS draft is 
mentioning about these services and trying to propose that in order to 
exchange these services, MSP is needed. I do not think this is the 
correct way to describe the .21 services. .21 defines the MIH protocol 
and message format to carry their services. Unless, we find new services 
and understand whether the scope is broader than .21,  I do not see a 
need for naming a signaling protocol like MSP.

>  
> my real problem is with the term MSTP since it is not necessarily just 
> a Transport protocol. although transport (in the OSI layering sense, 
> or IETF area definition sense) is part of our problem, it is not 
> security aspects and discovery aspects. But we never managed to think 
> of a better name during the NSIS work, so maybe we just have to live 
> with it.
   My suggestion would be to separate transport and discovery.  We can 
possibly address the security part within the transport part.
>     *From:* Zuniga, Juan Carlos
>     *Sent:* 13 March 2007 18:32
>     *To:* Hancock, Robert; [email-masked]
>     *Subject:* RE: [MIPSHOP-MIH-DT] protocol terminology (was: Issue
>     #6: Messagetransport)
>
>     Hi Robert,
>
>      
>
>     Protocol (like it is currently done in 802.21) and instead avoid
>     terms like MIH Services, which to me are adding more confusion in
>     this group.
>
>      
>
>     Since we are now in last call for the PS, the timing is perfect to
>     clean the terminology there too. Then in the future (ie once the
>     PS is accepted) we can stick to it.
>
>      
>
>     Jc
>
>      
>
>     *From:* Hancock, Robert [mailto:[email-masked]]
>     *Sent:* March 13, 2007 1:39 PM
>     *To:* [email-masked]
>     *Subject:* [MIPSHOP-MIH-DT] protocol terminology (was: Issue #6:
>     Messagetransport)
>
>      
>
>     hi everyone,
>
>      
>
>     i changed the subject line to cover a specific subject which a lot
>     of the mails in this thread seem to have been covering.
>
>      
>
>     least compatible things) here but with different terminology. i
>     take some blame for that, since the DC draft uses rather obscure
>     terminology for the various components of the problem.
>
>      
>
>     problem posed in the PS draft: basically, using the terminology of
>     that draft, we have to come up with a **solution for the MSTP**;
>     this includes defining the **upper interface that the MSTP
>     provides** to signalling protocols, but **not** those signalling
>     protocols themselves.
>
>      
>
>     stick to the final terminology of the PS draft. Probably we should
>     avoid terms like 'MIH protocol' altogether.
>
>      
>
>         *From:* Telemaco Melia [mailto:[email-masked]]
>         *Sent:* 13 March 2007 16:51
>         *To:* [email-masked]
>         *Cc:* [email-masked]; Hancock, Robert;
>         [email-masked]
>         <mailto:[email-masked]> wrote:
>
>         Hi Subir,
>
>         [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>
>         [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>
>         Telemaco Melia               [email-masked] <mailto:[email-masked]>
>

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 22 Mar 2007 01:16:52 +0100

hi srini,
 
realised i hadn't answered this:
" 
Robert, you said "if the message needs fragmentation and reassembly this
just happens invisibly, as does congestion control"
 
traversal safe?"
 
-- that's really a different issue. All I was saying was that the MSTP user
does not say to the MSTP 'please fragment this message', the MSTP should
decide how to fragment (and re-assemble) the message.
 
How the MSTP actually achieves this fragmentation and reassembly is another
question. I am nearly 100% certain that IP fragmentation will not be the
right answer, for multiple reasons. But we can come back to that when we get
closer to the design stage.
 
cheers,
 
robert h.

  _____  

From: [email-masked]
[mailto:[email-masked]] 
Sent: 14 March 2007 05:52
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #6: Message transport

Hi Telemaco,
I think Robert captures the points better than we could in this group based
on the experience the NSIS WG had in this area. If I were to pick and choose
for MIH use, they would be.

 
 
Regards,
Srini

  _____  

Srini,

I think it would be great if we could have a list of options the MIH layer
could configure into the transport layer.
Some time ago Robert already mentioned the example of GIST (connection
oriented transport vs non connection oriented transport).
I would proceed along these lines.

Comments?

telemaco

Subir,

Regards,

Srini

-----Original Message-----

[email-masked]

Hi Subir,

  

      

    

or we find different

be that we are combining

not knowing about RTP.

should we consider this

   a requirement for UDP?

   I agree.

But

    

     Correct.

   regards,

   -Subir

Regards,

Srini

-----Original Message-----

To: Hancock, Robert

Hancock, Robert wrote:

hi,

at a very high level, I would say that the answer to (a) is NO and 

the

    

answer to (b) is YES.

see further below:

protocol  protocol level?

  It would be helpful if we all are in the same page on this. Here is 

my

understanding:

  

  

Views?

 

-- 

Network Laboratories           

Kurfuersten-Anlage 36       

69115 Heidelberg

GERMANY   

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

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 10:48:31 -0500

Great. I agree then.
 
Regards,
Srini

From: ext Robert Hancock [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 7:17 PM
To: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Issue #6: Message transport

hi srini,

 
-- that's really a different issue. All I was saying was that the MSTP
user does not say to the MSTP 'please fragment this message', the MSTP
should decide how to fragment (and re-assemble) the message.
 
How the MSTP actually achieves this fragmentation and reassembly is
another question. I am nearly 100% certain that IP fragmentation will
not be the right answer, for multiple reasons. But we can come back to
that when we get closer to the design stage.
 
cheers,
 
robert h.

	Hi Telemaco,
	I think Robert captures the points better than we could in this
group based on the experience the NSIS WG had in this area. If I were to
pick and choose for MIH use, they would be.

	Robert, you said "if the message needs fragmentation and
reassembly this just happens invisibly, as does congestion control"

	Regards,
	Srini

	Srini,

	Comments?
	
	telemaco

		
		
		Regards,
		Srini
		
		-----Original Message-----
		From: ext Subir Das

			Hi Subir,

			

		   I agree.

			But

		     Correct.
		
		   regards,
		   -Subir

			Regards,
			Srini
			
			-----Original Message-----
			From: ext Subir Das

			Hancock, Robert wrote:

				hi,

				

				answer to (b) is YES.
				
				see further below:

			

		

		

			Views?

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 17:22:26 -0500

Hi all,

I agree with Robert, I think we should try to avoid IP-level
fragmentation issues, those are really nasty and can cause a lot of
issues to the overall service.  
 
John

	From: ext Robert Hancock [mailto:[email-masked]] 
	Sent: 21 March, 2007 17:17
	To: [email-masked]  
	Subject: RE: [MIPSHOP-MIH-DT] Issue #6: Message transport

	hi srini,

	you mean as in, IP level fragmentation? Are these fragments
firewall/nat traversal safe?"
	 
	-- that's really a different issue. All I was saying was that
the MSTP user does not say to the MSTP 'please fragment this message',
the MSTP should decide how to fragment (and re-assemble) the message.
	 
	How the MSTP actually achieves this fragmentation and reassembly
is another question. I am nearly 100% certain that IP fragmentation will
not be the right answer, for multiple reasons. But we can come back to
that when we get closer to the design stage.
	 
	cheers,
	 
	robert h.

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: 14 March 2007 05:52
		To: [email-masked]
		Cc: [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
		Subject: RE: [MIPSHOP-MIH-DT] Issue #6: Message
transport

		Hi Telemaco,
		I think Robert captures the points better than we could
in this group based on the experience the NSIS WG had in this area. If I
were to pick and choose for MIH use, they would be.

		 
		you mean as in, IP level fragmentation? Are these
fragments firewall/nat traversal safe?
		 
		Regards,
		Srini

		From: ext Telemaco Melia
[mailto:[email-masked]] 
		Sent: Tuesday, March 13, 2007 12:07 PM
		To: Sreemanthula Srinivas (Nokia-SIR/Dallas)
		Cc: [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
		Subject: Re: [MIPSHOP-MIH-DT] Issue #6: Message
transport

		Srini,
		
		I think it would be great if we could have a list of
options the MIH layer could configure into the transport layer.
		Some time ago Robert already mentioned the example of
GIST (connection oriented transport vs non connection oriented
transport).
		I would proceed along these lines.
		
		Comments?
		
		telemaco

				I would like to hear from you why do you
think that "we should not

			Because the transport neither have to know the
MIH header nor the
			service-type identifier in the MIH header. It
receives a payload of
			arbitrary size and a destination transport
address. We all agree this
			transparency. Let's talk f2f.
			
			Regards,
			Srini
			
			-----Original Message-----
			From: ext Subir Das
[email-masked];

				Hi Subir,
				Just to understand clearly what your are
saying with -

				
				Are you saying that mih protocol is
different from mih service? Mih 
				service defines the mih protocol. Or do
you mean the common message 
				header and format for es/cs/is as the
mih protocol? We should not 
				differentiate the two for MIPSHOP
purposes.

			     What I was trying to say is that MIH
service is using the MIH
			protocol and therefore, MIH
			      protocol is what we need to know. Do we
care about what service is
			carried over this protocol
			      unless we change the header and format of
MIH protocol in MIPSHOP
			or we find different
			      distinct requirements for different
services from .21?  MIH
			service is a functional  entity
			      and MIH is a protocol and the moment we
combine this, it seems to
			be that we are combining
			      the application and the underlying
protocol. IMO, we should
			differentiate this from protocol
			      design aspect. However, I would like to
hear from you why do you
			think that "we should not
			     differentiate the two for MIPSHOP putposes"

				Either way, we all seem to agree that
mih service protocol is not 
				known to the transport and seen as a
transport payload. E.g. like UDP 
				not knowing about RTP.

			   MIH service protocol seems to me a better
name....

				The reverse, RTP knowing that it
utilizes UDP may be true.

			   Even if this is true, how does it affect  UDP
design? My point is: 
			should we consider this
			   a requirement for UDP?

				So is the case here, MIH service
protocol knows the transport 
				functions it may be using. In other
words, the transport exports a 
				single set of transport services to the
MIH service protocol layer.

			   I agree.

				But
				different MIH service protocol may use
only what is needed for its 
				functionality. But, generally, I agree
with the sentiment that this 
				aspect is not necessary for transport
design but captured only to 
				ensure that a rich set of transport
functions (and the APIs) are 
				defined and exported to its users (MIH
layer).

			     Correct.
			
			   regards,
			   -Subir

				Regards,
				Srini
				
				-----Original Message-----
				From: ext Subir Das
[mailto:[email-masked]]
				Sent: Monday, March 12, 2007 1:55 PM
				To: Hancock, Robert
				Cc: Sreemanthula Srinivas
(Nokia-SIR/Dallas); 
				[email-masked];
[email-masked]; 
				[email-masked];
[email-masked]
				Subject: Re: [MIPSHOP-MIH-DT] Issue #6:
Message transport

				Hancock, Robert wrote:

				hi,

				

				answer to (b) is YES.
				
				see further below:

				  Subir> Good points.  I agree with you
on (a).  When you say  the 
				answer to (b) is yes, do you
				             mean at the
implementation/integration level  or at the 
				protocol  protocol level?
				
				  In general, it seems to me that we are
using MIH services and MIH 
				protocol interchangeably.
				  It would be helpful if we all are in
the same page on this. Here is 
				my
				understanding:

			

				Towards this, transport protocol/layer
will receive a packet from MIH

				protocol and it knows where to transport
it. What is included within  
				MIH protocol frame is not known ( unless
we understand the reason why 
				it needs to know) by the transport.
				 And, MIH service is included with the
MIH protocol frame. Only MIH 
				protocol knows about the service.
				
				Views?

				

				

		-- 
		Telemaco Melia
[email-masked]
		Research Staff Member		Tel: +49 (0) 6221 4342-
142
		Network Laboratories    	Fax: +49 (0) 6221 4342-
155
		NEC Europe Ltd.         	Web:
http://www.netlab.nec.de
		Network Laboratories           
		Kurfuersten-Anlage 36       
		69115 Heidelberg
		GERMANY