Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 1 Mar 2007 13:35:25 -0000

hi subir,

thanks for the input. 

i've tried to pull out the comments and address them in this
mail (for ease of access). i think some of them are about clarity
issues rather than scope, but see what you think ...

Several of your comments indicate that something is under 
discussion in .21 already. This is actually a general point:
.21 is a moving target, and will continue to move for some
time yet, and we need to decide how to deal with that type of
uncertainty. I think the right technical approach is to scope
the functionality of the mipshop work to achieve a clean
design with basic but well thought out extensibility mechanisms,
in order that wherever .21 ends up the mipshop work will still
be applicable. In some cases that may lead to feedback to .21
(saying "it's really important that you do/don't make this 
assumption"); in other cases, we may make our own assumptions
about the functionality that is useful.

I would be interested to hear everyone's views on the above point.
Now for more details:

section 2: protocol split issues
Maybe the text here is unclear. The purpose of the section is to
introduce the fact that there is some protocol definition work
in the MIH services (== what .21 is doing for example), and some
in the transport (== what mipshop is doing); and that because of
this, there needs to be some formalisation of how the different
bits of the solution interact. Therefore:
- if you don't think this split should exist (!), please suggest how
to organise the work between ieee/ietf
- if you think the text is unclear, please suggest modifications
- else I must have misunderstood your comments

section 2: routing along multiple nodes
My assumption is that the transport (common part) needs at most
to consider how to go between adjacent hops. Whether the MIH service
layer puts them together into a longer route is then invisible.

section 3.1 (naming/discovery):
   The process of discovering a suitable peer and establishing a route
   towards it has a number of aspects that need to be considered.  The
   first of these is how MIH services are identified.  For an MN
   interested in a particular MIH service, the identity of the service
   must be usable in some discovery and name resolution procedure that
   ultimately returns an IP address to the interested MN.  Therefore,
   the name space within which MIH services are identified has an
   interaction with the set of possible discovery mechanisms.  For
   example, use of a particular discovery procedure may require
   extensions to support a new namespace or new registrations within an
   existing one.   

   Subir> This is something that need further discussion. Do we need
this as a requirement? 

[reh] I'm not sure what you are referring to as a requirement; I
think the paragraph is just a statement of fact. (Unless you believe
that the MIH service layer knows explicitly about IP addresses of
signalling peers and provides them to the transport.)

(security and discovery)
                   The selection of a suitable peer and its subsequent
   use may be based on a number of aspects including the capabilties of
   the MIH peer and the ability to setup a secure communications channel
   to that device.  Therefore, the discovery process has interactions
   with other transport layer functionality, which may need to be
   considered as part of the discovery procedure itself.

   Subir> Secure discovery is a strict requirement. We need to revisit
and 
   IMO, we do not need this one. If at all it is required in some cases,
it 
   Should be SHOULD NOT MUST. 

[reh] when you say 'secure discovery is a strict requirement', by
'strict' do you mean 'essential' or 'difficult'? 
My expectation would be that any solution we design MUST include
this capability; however, it would typically be in the 'mandatory
to implement, optional to use' category. Does that answer your
question?

(precision of the discovery process)
[reh] we should come back to this in a separate thread

(localisation)
   o  localisation of information.  The information associated with
      supporting a particular MIH service should be located in as few
      places as possible to aid failure recovery, and reduce
      requirements on MNs to hold large amounts of state information. 
 
  Subir> I do not understand the purpose of the above requirement. 

[reh] this is just a design goal: if deploying MIH services requires
configuration in large numbers of nodes, especially nodes outside
the access or not administratively controlled by the access, this 
becomes much harder. (Discovery solutions based on DNS could have this
problem, for example.)

3.2.  Signalling Peer Changes

   As well as the initial discovery of the peers for signalling, it must
   also be considered how to handle the case where the correct
   signalling peer changes while the MN is attached to the network. 

  Subir> I assume this should be transparent to the end users. I can
think 
  of two scenarios: 
i) peer changes while providing the services: this should be taken care
by existing mechanisms such as server pooling or backup servers.
ii) Peer changes while they are not in service: this should be
discovered easily if the discovery mechanism uses a logical namespace

[reh] i think case (ii) is easy and should be a side-effect of the
design. (i) is more difficult (but the main issue here is as much
mobility as fault handling; maybe there should be some cross references
to 3.9 here).

   Whatever approach is used here, it should be noted that there needs
   to be an interaction between the service layer and common protocol to
   convey not just the possibility that rediscovery is needed, but also
   to indicate that a peer change has taken place. 

 Subir> This should not be a requirement, IMO. 

[reh] Here I disagree. I think you are saying that the solution should
force fault management to take place transparently to the end nodes,
i.e. on highly available server pools or suchlike. While that is a
possible implementation approach, I think if the protocol design makes
that assumption it will be seen as broken.

3.3 Message transport

                                                             Different
   services might request different levels of transport support from a
   single instance; indeed, a service might request different transport
   characteristics for different transaction types.  

   Subir> My understanding is that MIH services are agnostic to
underlying transport. Therefore, I do not understand what do we mean by
`Different services might request different levels of transport support
from a single instance`. 

[reh] messages may have different priorities, may need to be delivered
in order or not, and so on. In other words, not all messages are the
same.

(congestion avoidance)
[reh] we should come back to this in a separate thread.

   Duplicate Message Detection:  multiple copies of a message may arrive
      at a node.  Does the transport layer provide duplicate message
      detection, or is this left up to the MIH service? 

 Subir> We need to discuss this. Currently there is no mechanism in the
MIH 
 Protocol but left as implementation. 

[reh] I think this comes into 'what is in general sensible to provide'
category (which depends partly on what else is provided).

3.4 State Management

   Subir> State management for MIH services is within MIH protocol
transaction. 
   There is no need to consider that within the transport, IMO. 

[reh] At a high level, I think we are all agreed on that. It is just the
implications that the transaction model have on the transport that we
need to consider (as you mention below).

   The current MIH services that have been identified require MN and NN
   initiated exchanges as a minimum.

   Subir> There is no way .21 can restrict this kind of behavior. Also
one 
   Scenario is missing here: 

   XX: Network Initiated only: where exchanges can only be initiated by
the
       Network, and the MN only responds to explicit requests for
       Information/service.

[reh] I think I agree. Maybe we should split it differently (as MN
initiated and NN initiated, and say these can be mixed). There is
another refinement needed: we have to consider two sorts of initiation
- who makes initial contact with the peer
- who starts an individual transaction
The implications come when we start to think about NAT traversal issues.

(state classification)
   Subir> Above points need further discussion. 

[reh] yes, the list is exhaustive, and certainly some parts would not be
visible to the common part. The key question is: what parts. (as the
following paragraph discusses.)

3.5 Multiplexing

   In addition, the extensibility of the MIH services needs to be
   considered.  For example, if multiple versions of an MIH service are
   available, this may impact the common protocol functionality in terms
   of discovery of compatible MIH service implementations  (see
   Section 3.1).

Subir> The above section is not very clear. In particular, the example 
Of `multiple versions of an MIH service`. What is the version here? Is
it 
802.21 specification version? If so, do we expect to have two versions 
Implemented within a device?

[reh] suppose there are two versions of .21 defined, say v1 and v2. If
nodes only ever support one version, then v1 and v2 nodes will not be
able to communicate. If one node supports v1 and v2, how does it choose
which one to use to communicate with another node (given that if is
tries only v1 it may never use v2, if it only tries v2 it may fail and
have to fall back to v1, and if it tries both you cause message
explosions.) Versioning is hard, but IMHO related to the node discovery
issue.

3.7 Security

clearly we need more clarity here ;-)

3.8/3.9:

Subir> It seems that Load management and failure handling are too
generic and it should be handled by error handling.

[reh] I think error handling is more related to 3.9 and this aspect
could be extended. error handling is one of the harder parts of the
protocol design. If you have any suggested concepts here that would be
helpful.

robert h.

> -----Original Message-----
> From: Subir Das [mailto:[email-masked]] 
> Sent: 27 February 2007 16:16
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [MIPSHOP-MIH-DT] A modest proposal
> 
> All,
> I put some of my quick comments in the draft version.
> Pl. search by name. 
> 
> Thanks,
> -Subir

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

---

From: Sam Xia <[email-masked]>
Date: Fri, 02 Mar 2007 18:32:00 +0800

Hi Rober and Subir,
 Please see the inline.

 Best Regards, Sam Xia 

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 9:35 PM
> To: Subir Das
> Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments
> 
> hi subir,
> 
> thanks for the input. 
> 
> mail (for ease of access). i think some of them are about 
> clarity issues rather than scope, but see what you think ...
> 
> design with basic but well thought out extensibility 
> mechanisms, in order that wherever .21 ends up the mipshop 
> work will still be applicable. In some cases that may lead to 
> feedback to .21 (saying "it's really important that you 
> do/don't make this assumption"); in other cases, we may make 
> our own assumptions about the functionality that is useful.
> 

I think that it is very important to scope the functionality of the mipshop
work to achieve the clear designing goal. Since the .21 is moving forward,
so the extensibility mechniasm should be considered carefully. And I think
that we have to get the feedback when scoping the functionality of the
mipshop work. Here, I have a basic question as following:
The functionality of mipshop work is limited to the internal implementation
of MIHF merely, isn't it? Could we add some MIH service primitive(s) to the
users of MIH services or to link layer?

> Maybe the text here is unclear. The purpose of the section is 
> to introduce the fact that there is some protocol definition 
> work in the MIH services (== what .21 is doing for example), 
> and some in the transport (== what mipshop is doing); and 
> that because of this, there needs to be some formalisation of 
> how the different bits of the solution interact. Therefore:
> - if you don't think this split should exist (!), please 
> suggest how to organise the work between ieee/ietf

Splitting between MIH service and the common functinality of transportation
protocol can be seen as a mechanism capabale of excellent extensibility.

> My assumption is that the transport (common part) needs at 
> most to consider how to go between adjacent hops. Whether the 
> MIH service layer puts them together into a longer route is 
> then invisible.
> 
I am not sure. If moble node knows the peer address, the routing should be
determined by the network(my assumption). I don't know what  you mean.

>    Subir> This is something that need further discussion. Do 
> we need this as a requirement? 
> 
> [reh] I'm not sure what you are referring to as a 
> requirement; I think the paragraph is just a statement of 
> fact. (Unless you believe that the MIH service layer knows 
> explicitly about IP addresses of signalling peers and 
> provides them to the transport.)

I think that Subir's belief is that naming and discovering need to be
discuss further.  As we all know, naming and discovering are those important
aspects impacting on designing of the common functionality of protocol. But
in practice, naming and discovering are kinds of high level services and
correlated with network topology.  If the functionality of naming and
discovering are incorporated into that of the common transportation, there
should be a lot of assumption in advace.
Meanwhile, for  the typical user of MIH service (such as, MIP), there exist
some of bootstraping and AAA mechanisms. In order to reduce the signalling
messages and to improve the efficiency, it is very useful to provide the
users of MIH services with the capability of assisting in discovering MIH
peer.

>    Subir> Secure discovery is a strict requirement. We need 
> to revisit and 
>    IMO, we do not need this one. If at all it is required in 
> some cases, it 
> [reh] when you say 'secure discovery is a strict 
> requirement', by 'strict' do you mean 'essential' or 'difficult'? 
> My expectation would be that any solution we design MUST 
> include this capability; however, it would typically be in 
> the 'mandatory to implement, optional to use' category. Does 
> that answer your question?
> 

I think that  secure discovery is a essential processing. But the setuping
of SA between MIH peers is very expensive. And it's apparent that MIHF in
the peers have to recieve the security parameters from the upper layers,
i.e. the users of MIH service. So it is the easiest way for MIHF to inherit
the SA from the upper layers.

> [reh] this is just a design goal: if deploying MIH services 
> requires configuration in large numbers of nodes, especially 
> nodes outside the access or not administratively controlled 
> by the access, this becomes much harder. (Discovery solutions 
> based on DNS could have this problem, for example.)
> 
This is very close and related with the specific implementation.

>   Subir> I assume this should be transparent to the end 
> users. I can think
>   of two scenarios: 
> i) peer changes while providing the services: this should be 
> taken care by existing mechanisms such as server pooling or 
> backup servers.
> ii) Peer changes while they are not in service: this should 
> be discovered easily if the discovery mechanism uses a 
> logical namespace
> 
> [reh] i think case (ii) is easy and should be a side-effect 
> of the design. (i) is more difficult (but the main issue here 
> is as much mobility as fault handling; maybe there should be 
> some cross references to 3.9 here).
> 
> [reh] Here I disagree. I think you are saying that the 
> solution should force fault management to take place 
> transparently to the end nodes, i.e. on highly available 
> server pools or suchlike. While that is a possible 
> implementation approach, I think if the protocol design makes 

I think that it is early to dicuss the reliabiltiy and fault recovery
because we don't have a roufh sketch now.

>    Subir> My understanding is that MIH services are agnostic 
> to underlying transport. Therefore, I do not understand what 
> do we mean by `Different services might request different 
> levels of transport support from a single instance`. 
> 
> [reh] messages may have different priorities, may need to be 
> delivered in order or not, and so on. In other words, not all 
> messages are the same.
> 
> (congestion avoidance)
>  Subir> We need to discuss this. Currently there is no 
> mechanism in the MIH  Protocol but left as implementation. 
> 

It sounds good that different services request transporting support. Could
you give us some examples, Robert?

> 
> 3.4 State Management
> 
>    Subir> State management for MIH services is within MIH 
> protocol transaction. 
> [reh] At a high level, I think we are all agreed on that. It 
> is just the implications that the transaction model have on 
> the transport that we need to consider (as you mention below).
> 
>    Subir> There is no way .21 can restrict this kind of 
> behavior. Also one 
>    XX: Network Initiated only: where exchanges can only be 
> initiated by the
> [reh] I think I agree. Maybe we should split it differently 
> (as MN initiated and NN initiated, and say these can be 
> mixed). There is another refinement needed: we have to 
> consider two sorts of initiation
> [reh] yes, the list is exhaustive, and certainly some parts 
> would not be visible to the common part. The key question is: 
> what parts. (as the following paragraph discusses.)
> 
> 3.5 Multiplexing
> 
> Of `multiple versions of an MIH service`. What is the version 
> here? Is it
> 802.21 specification version? If so, do we expect to have two 
> versions Implemented within a device?
> 
> [reh] suppose there are two versions of .21 defined, say v1 
> and v2. If nodes only ever support one version, then v1 and 
> v2 nodes will not be able to communicate. If one node 
> supports v1 and v2, how does it choose which one to use to 
> communicate with another node (given that if is tries only v1 
> it may never use v2, if it only tries v2 it may fail and have 
> to fall back to v1, and if it tries both you cause message
> explosions.) Versioning is hard, but IMHO related to the node 
> discovery issue.
> 
> 3.7 Security
> 
> [reh] I think error handling is more related to 3.9 and this 
> aspect could be extended. error handling is one of the harder 
> parts of the protocol design. If you have any suggested 
> concepts here that would be helpful.
> 
> robert h.
> 
> 
> 
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 2 Mar 2007 13:59:46 -0500

Robert, Subir, Sam,

I'm adding some comments to the discussion. I also added one paragraph
for the section 2 discussion, and tagged some of your previous comments
with your initials, just to make it easier for other people to follow (I
hope you don't mind).

Regards,

Juan Carlos

-----Original Message-----
From: Sam Xia [mailto:[email-masked]] 
Sent: March 2, 2007 5:32 AM
To: 'Hancock, Robert'; 'Subir Das'
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi Rober and Subir,
 Please see the inline.

 Best Regards, Sam Xia 

> I would be interested to hear everyone's views on the above point.

JCZ> I believe that what Subir refers to when saying that issues are
under discussion in 802.21 is that actual solutions are being presented
and discussed in the group. This does not make 802.21 a moving target,
but rather puts it ahead of MIPSHOP. The 802.21 draft specification is
not fixed but it is quite stable at this point, and I don't think that
any dramatic change will happen before it gets approved. 
Also, since the work in 21 is moving faster, it makes more sense to
feedback from 802.21 to MIPSHOP than the other way around. BTW, I think
that this is exactly what we (people attending 802.21) are trying to do
here. We should take this constructive feedback and built on top of the
existing MIH functionalities whatever is needed for the transport.

Sam>I think that it is very important to scope the functionality of the
mipshop
work to achieve the clear designing goal. Since the .21 is moving
forward,
so the extensibility mechniasm should be considered carefully. And I
think
that we have to get the feedback when scoping the functionality of the
mipshop work. Here, I have a basic question as following:
The functionality of mipshop work is limited to the internal
implementation
of MIHF merely, isn't it? Could we add some MIH service primitive(s) to
the
users of MIH services or to link layer?

JCZ> Sam: it is 802.21 who defines the internal implementation of the
MIHF, and MIPSHOP helps it with the transporting, discovering, etc, over
L3 networks. Just as an example, 802.11(u) and 802.16(g) are defining
the same transport, discovery, etc when the MIH functions are located in
the same 802 LAN.

> Now for more details:

JCZ> (I'm adding some previous comments from Subir here to make it
easier to follow):

> 
> section 2: (protocol split issues)
   The framework presented in [1] decomposes the MIH protocol problem
   into two parts; the Information and Information Exchange mechanism,
   and the functionality common to all MIH services.  This is
   subsequently referred to as common protocol functionality.  The
   intention of the separation is to allow all MIH services access to
   this functionality from a single protocol module without having to
   re-implement or re-integrate the same functionality individually for
   each MIH service.  The problem statement presents an outline of this
   decomposition; however, the precise details of the split of
   functionality and interaction between the layers need to be refined
   as the design of the common part proceeds.  Indeed, one important
   design consideration is that it should be possible to define these
   interactions precisely and in an easily implementable manner.  This
   section indicates some specific inter-layer interaction issues that
   need to be taken into account in this way.

  Subir> The goal and motivation of this section is not clear. I do not
understand the why MIH protocol needs to be decomposed like this. It
seems that the whole document is based upon this split functionality. We
need some good discussions on this. Information exchange mechanism is a
part of information service and the information database (if that is
meant by information) is a separate thing.

   One of the key questions is how MIH service peer identity knowledge
   is split between the service and the common part.  In other words,
   does the MIH service have knowledge about the location of a peer (in
   terms of IP address), or does it simply pass a message to the common
   protocol functionality and expect it to be delivered.  If the MIH
   service manages the resolution of peer identities to IP addresses,
   issues such as NAT traversal can become more complicated (as
   discussed in Section 3.6). 

Subir> Again why do we need to split the functionality? Are we designing
the MIH function here? IMO, this is no different than any other
application.  

> [reh] Maybe the text here is unclear. The purpose of the section is 

Sam> Splitting between MIH service and the common functinality of
transportation
protocol can be seen as a mechanism capabale of excellent extensibility.

JCZ> The decomposition should be indeed between the MIHF (802.21) and
the MIH Transport (MIPSHOP). There is no need to do any splitting
between service and common part. In fact, we should not mention here MIH
Services at all, because it gives the impression that the transport
should be service-aware and that is not correct. The services are
transparent to the transport. We are supposed to solve the transport
issue for MIH messages, which can carry ES, CS, or IS information. This
level of detail is transparent to the transport layer which only sees a
generic MIH message to be delivered, which comes from the same common
MIH Function (MIHF). Therefore, the transport is indeed a common
protocol, where no service-specific part is needed.

> MIH service layer puts them together into a longer route is 
Sam> I am not sure. If moble node knows the peer address, the routing
should be
determined by the network(my assumption). I don't know what  you mean.

JCZ> Robert, if by 'hops' you mean MIHF to next MIHF, you are definitely
right. This is another issue being discussed in 21, and it is referred
to as MIHF Multi-hop. Since these hops can happen over L3 or L2
networks, the transport should worry about communicating only two MIHF
peers (which in the L3 case could be many IP hops away), and it is
within the MIHF scope to solve the multi-hop issue.

> provides them to the transport.)

Sam> I think that Subir's belief is that naming and discovering need to
be
discuss further.  As we all know, naming and discovering are those
important
aspects impacting on designing of the common functionality of protocol.
But
in practice, naming and discovering are kinds of high level services and
correlated with network topology.  If the functionality of naming and
discovering are incorporated into that of the common transportation,
there
should be a lot of assumption in advace.
Meanwhile, for  the typical user of MIH service (such as, MIP), there
exist
some of bootstraping and AAA mechanisms. In order to reduce the
signalling
messages and to improve the efficiency, it is very useful to provide the
users of MIH services with the capability of assisting in discovering
MIH
peer.

JCZ> I agree, it would be very useful, and in fact we need to provide
the capability to discover MIH peers. Nonetheless, we should make sure
that we cover all cases, and that we do not exclude for instance the
possibility of an MIHF address being hard coded or provided by some
other external means. I think that the best is to make a clear splitting
between the discovery and the transport to avoid further complications.

> that answer your question?

JCZ> This is another one that will require some discussion. The MIH that
requires security (i.e. encryption) would need it regardless of whether
the transport is over L2, L3 or a combination thereof. It seems to me
that a more complete solution would be located within the MIHF, and not
over each specific transport. Besides, there is also the MIHF
authentication issue that once again 802.21 (MIH) has to solve for all
kinds of transport.

> [reh] we should come back to this in a separate thread

Sam> I think that  secure discovery is a essential processing. But the
setuping
of SA between MIH peers is very expensive. And it's apparent that MIHF
in
the peers have to recieve the security parameters from the upper layers,
i.e. the users of MIH service. So it is the easiest way for MIHF to
inherit
the SA from the upper layers.

> based on DNS could have this problem, for example.)
Sam> This is very close and related with the specific implementation.

JCZ> What I understand here is that having as few nodes as possible with
MIH knowledge (i.e. helping discovery) is a good strategy and can save
us some complication time in the future. On the other hand, I'd like to
add that the MIHF information, and the services that it supports are
located only in that function and in any MN that has subscribed to it.
There is no state information needed elsewhere. In fact, the only
state-like information that I can think of in 802.21 is Registration or
Event Subscription, and those again are 802.21 issues and they do not
impose any transport requirements. The 802.21 draft already defines
messages for registration, event subscription etc. 
Regardless, I think that the paragraph needs more clarifications.

> that assumption it will be seen as broken.

Sam> I think that it is early to dicuss the reliabiltiy and fault
recovery
because we don't have a roufh sketch now.

JCZ> Yes, a sketch would help here. I agree that it is early to discuss
detailed fault recovery issues before having defined the high level
requirements. However, because the whole MIH stuff is about mobility,
changing networks and re-discovering should be an MIH day-to-day issue
that we have to discuss, even if not in the context of fault recovery. 
First of all, I insist that there is no service-specific part needed,
but only a common transport protocol which should be separated from the
discovery mechanism. This discussion should affect the discovery
mechanism, but not the common transport protocol part.

> delivered in order or not, and so on. In other words, not all 

JCZ> I completely agree with Subir here. 802.21, has transaction IDs
defined to take care of the reordering issue. Also, is not a transport
issue if someone wants to buffer events and report them later on.
Finally, if ever the prioritising of message is needed, this should be
done for all transport networks (again, L2 or L3) and at the MIH level,
not at the transport level.

> category (which depends partly on what else is provided).

Sam> It sounds good that different services request transporting
support. Could
you give us some examples, Robert?

JCZ> Subir, the current transaction ID can be used for detecting
duplication of messages. I'm not sure what you mean by "left as
implementation."

> The implications come when we start to think about NAT 

JCZ> It seems to me that we all agree on this one.

> explosions.) Versioning is hard, but IMHO related to the node 

JCZ> I disagree that versioning is related to the discovery issue. If
ever needed, a version ID could come as one of the many MIH capability
parameters inside the MIH Capability Discover message. However, it is up
to the MIH to make sure that backwards compatibility is kept.
I cannot think of any other scenario where this sort of multiplexing
would be needed, since the MIH frame already contains all the required
information.

---

From: <[email-masked]>
Date: Fri, 2 Mar 2007 13:30:59 -0600

Hi Sam,
One small clarification. 
>The functionality of mipshop work is limited to the internal
implementation of MIHF merely, isn't it? Could we add some MIH service
primitive(s) to the users of MIH services or to link layer?

MIPSHOP does not define MIHF functionality, it provides a transport
layer functionality for MIH protocol. Services primitives discussed here
are the transport service primitives not the MIH service primitives to
the users or link.

Regards,
Srini

-----Original Message-----
From: ext Sam Xia [mailto:[email-masked]] 
Sent: Friday, March 02, 2007 4:32 AM
To: 'Hancock, Robert'; 'Subir Das'
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi Rober and Subir,
 Please see the inline.

 Best Regards, Sam Xia 

> i've tried to pull out the comments and address them in this mail (for

> ease of access). i think some of them are about clarity issues rather 
> than scope, but see what you think ...
> 
> Several of your comments indicate that something is under discussion 
> in .21 already. This is actually a general point:
> .21 is a moving target, and will continue to move for some time yet, 
> and we need to decide how to deal with that type of uncertainty. I 
> think the right technical approach is to scope the functionality of 
> the mipshop work to achieve a clean design with basic but well thought

> out extensibility mechanisms, in order that wherever .21 ends up the 
> mipshop work will still be applicable. In some cases that may lead to 
> feedback to .21 (saying "it's really important that you do/don't make 
> this assumption"); in other cases, we may make our own assumptions 

I think that it is very important to scope the functionality of the
mipshop work to achieve the clear designing goal. Since the .21 is
moving forward, so the extensibility mechniasm should be considered
carefully. And I think that we have to get the feedback when scoping the
functionality of the mipshop work. Here, I have a basic question as
following:
The functionality of mipshop work is limited to the internal
implementation of MIHF merely, isn't it? Could we add some MIH service
primitive(s) to the users of MIH services or to link layer?

> introduce the fact that there is some protocol definition work in the 
> MIH services (== what .21 is doing for example), and some in the 
> transport (== what mipshop is doing); and that because of this, there 
> needs to be some formalisation of how the different bits of the 
> solution interact. Therefore:

Splitting between MIH service and the common functinality of
transportation protocol can be seen as a mechanism capabale of excellent
extensibility.

> section 2: routing along multiple nodes My assumption is that the 
> transport (common part) needs at most to consider how to go between 
> adjacent hops. Whether the MIH service layer puts them together into a

> longer route is then invisible.
> 
I am not sure. If moble node knows the peer address, the routing should
be determined by the network(my assumption). I don't know what  you
mean.

> [reh] I'm not sure what you are referring to as a requirement; I think

> the paragraph is just a statement of fact. (Unless you believe that 
> the MIH service layer knows explicitly about IP addresses of 

I think that Subir's belief is that naming and discovering need to be
discuss further.  As we all know, naming and discovering are those
important aspects impacting on designing of the common functionality of
protocol. But in practice, naming and discovering are kinds of high
level services and correlated with network topology.  If the
functionality of naming and discovering are incorporated into that of
the common transportation, there should be a lot of assumption in
advace.
Meanwhile, for  the typical user of MIH service (such as, MIP), there
exist some of bootstraping and AAA mechanisms. In order to reduce the
signalling messages and to improve the efficiency, it is very useful to
provide the users of MIH services with the capability of assisting in
discovering MIH peer.

> and
>    IMO, we do not need this one. If at all it is required in some 
> cases, it
> My expectation would be that any solution we design MUST include this 
> capability; however, it would typically be in the 'mandatory to 
> implement, optional to use' category. Does that answer your question?
> 

I think that  secure discovery is a essential processing. But the
setuping of SA between MIH peers is very expensive. And it's apparent
that MIHF in the peers have to recieve the security parameters from the
upper layers, i.e. the users of MIH service. So it is the easiest way
for MIHF to inherit the SA from the upper layers.

> configuration in large numbers of nodes, especially nodes outside the 
> access or not administratively controlled by the access, this becomes 
> much harder. (Discovery solutions based on DNS could have this 
> problem, for example.)
> 

> i) peer changes while providing the services: this should be taken 
> care by existing mechanisms such as server pooling or backup servers.
> mobility as fault handling; maybe there should be some cross 
> references to 3.9 here).
> 

> underlying transport. Therefore, I do not understand what do we mean 
> by `Different services might request different levels of transport 
> support from a single instance`.
> 

>  Subir> We need to discuss this. Currently there is no mechanism in 
> the MIH  Protocol but left as implementation.
> 

It sounds good that different services request transporting support.
Could you give us some examples, Robert?

> [reh] At a high level, I think we are all agreed on that. It is just 
> the implications that the transaction model have on the transport that

> we need to consider (as you mention below).
> 

>    XX: Network Initiated only: where exchanges can only be initiated 
> by the
> - who starts an individual transaction The implications come when we 
> start to think about NAT traversal issues.
> 
> (state classification)
> [reh] yes, the list is exhaustive, and certainly some parts would not 
> be visible to the common part. The key question is:

> nodes only ever support one version, then v1 and
> v2 nodes will not be able to communicate. If one node supports v1 and 
> v2, how does it choose which one to use to communicate with another 
> node (given that if is tries only v1 it may never use v2, if it only 
> tries v2 it may fail and have to fall back to v1, and if it tries both

> you cause message

---

From: <[email-masked]>
Date: Fri, 2 Mar 2007 14:24:13 -0600

Hello all,

Okay, let me contribute my part to make it harder to read.

Regards,
Srini 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Friday, March 02, 2007 1:00 PM
To: Sam Xia; Hancock, Robert; Subir Das
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Robert, Subir, Sam,

Regards,

Juan Carlos

-----Original Message-----
From: Sam Xia [mailto:[email-masked]]
Sent: March 2, 2007 5:32 AM
To: 'Hancock, Robert'; 'Subir Das'
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi Rober and Subir,
 Please see the inline.

 Best Regards, Sam Xia 

Sam>I think that it is very important to scope the functionality of the
mipshop
work to achieve the clear designing goal. Since the .21 is moving
forward, so the extensibility mechniasm should be considered carefully.
And I think that we have to get the feedback when scoping the
functionality of the mipshop work. Here, I have a basic question as
following:
The functionality of mipshop work is limited to the internal
implementation of MIHF merely, isn't it? Could we add some MIH service
primitive(s) to the users of MIH services or to link layer?

> [reh] Maybe the text here is unclear. The purpose of the section is to

SS> I think this more of a terminology issue. What is the common part vs
that is the mih service vs what is the transport. Agreed, we need some
clarity. We should reflect the update based on these comments.

SS> transport hopping should be possible and may be necessary in some
instances e.g. for firewall etc.

protocol.
there should be a lot of assumption in advace.

SS> agree. Discovery if needed, just define how.

SS> I am almost certain that there is NO requirement for secure
discovery.

Sam> I think that  secure discovery is a essential processing. But the
setuping
of SA between MIH peers is very expensive. And it's apparent that MIHF
in the peers have to recieve the security parameters from the upper
layers, i.e. the users of MIH service. So it is the easiest way for MIHF
to inherit the SA from the upper layers.

SS> Again, let's not mix up discovery with transport setup. There is no
SA at upper layer.

SS> Agree.

SS> What this section means is that the event services may ask for one
set of transport options and information services may seek another set.
This is relevant to the real time delivery of events without overhead
due to certain transport setup. With respect to reordering, the MIH
service only knows an MIH packet which could be fragmented to more than
one transport packet. In this case, in-order delivery is not a serious
requirement (as is the reassembled packet) but transaction ids are not
helpful here either. Another related question is, from a MIH level, if
two events were generated one after another, don't you want the
recipient to know in the same order? Can the transaction ids determine
the order?

SS> I agree with Juan. Also, this feature is necessary more than
sensible, since the transport should not provide to the upper layer if
the transport seq numbers are same. The transaction ids are utilized in
cases where even trasnsport seq numbers are different. Yes, this can
happen.

SS> It would be a fair assumption to make that the MN is the one that
makes the first contact to the network node. MIH transport should be
unaware of the MIH payload (which determines the various use cases).
There could be state-information related to transport establishment and
maintenance which is independent of Mih state machine.

SS> I agree that MI must provide versioning. Juan, can we insert this in
mih-capability in Orlando? It should be fair to assume that the
transport is independent of the MIH versions.

---

From: Subir Das <[email-masked]>
Date: Fri, 02 Mar 2007 22:03:59 -0500

Robert,
Pl. see my answers below.  Sorry, for the delay.

Thanks
-Subir

> about the functionality that is useful. 
   Subir>   .21 has already specified their requirements. IMO, these 
requirements will not change
      much for the current PAR. We can not predict what will happen in 
future. Flexibility
      is good but that should not be open-ended. Unless we understand 
what other use
      cases we are targeting on, it will be very difficult to add the 
requirements. I would
      suggest, let's start with what we know  and simple assumptions.
> - else I must have misunderstood your comments 
  Subir>   According to my current understanding, we do not need this 
split. Here is my reason:
     .21 defines MIH protocol and they own the protocol. Mipshop defines 
a transport
     according to the requirements. According to .21, MIH protocol is 
transport agnostic.
     So where do we see the interaction? Of course, I am not saying that 
implementations
     do not need to take care of this. Unless Mipshop changes or adds 
something to the
     MIH protocol, MIH services and protocols are just another 
applications.
    
> layer puts them together into a longer route is then invisible.
   Subir>   After reading this and going through the draft again, I 
think you assume MIH services/protocols
     and transport are tightly coupled. Am I right?   If this right, I 
would say we do not need to
     think that way. Then the routing would be taken care of  by 
Transport or IP.
> signalling peers and provides them to the transport.)
   Subir> I not that we do not need the peer MIH discovery. The above 
paragraph discusses more than
              just an IP address discovery. For example, I am not sure 
if we need a new namespace. To
              understand the scope we need some more understanding.
> to implement, optional to use' category. Does that answer your
   Subir>  As I said, it is not required to be MUST. For example, we do  
lot of discovery today
               via DHCP. How many of them are MUST?  Also I don't know 
if we say MUST, 
               can it be optional to use?  I still think it should be 
SHOULD.
> becomes much harder. (Discovery solutions based on DNS could have this
   Subir> Now I see where you are coming from. But do we need to 
consider this as a design goal?
              Also I do not how does it impact to a transport protocol 
design?
>    to indicate that a peer change has taken place. 
   Subir> I think it worth having some discussions on what is this 
common protocol part. How does it
               relate to .21 MIH protocol and services?
> that assumption it will be seen as broken.
   Subir> I need to understand little more when you say it will be "seen 
as broken". I think we
              also need to ask ourselves: what are the "essential design 
goals" and what are "good
              to have design goals".
             
> in order or not, and so on. In other words, not all messages are the
    Subir> I agree. But is it not taken care by  IP?
> category (which depends partly on what else is provided).
   Subir> Agree.
>    initiated exchanges as a minimum.
  Subir> Ok.
> The implications come when we start to think about NAT traversal issues.
  Subir> Ok.
> following paragraph discusses.)
   Subir> Exactly. Let's make it clear what is this common part.
> explosions.) Versioning is hard, but IMHO related to the node discovery
   Subir> But that should be handled by MIH function and nothing to do 
with the transport, IMO.
> protocol design. If you have any suggested concepts here that would be
  Subir> Again, we need to understand what we are targeting here. 
Certainly, we do not need
             take care how MIH protocol and it's service implementations 
will handle the error. We
             should only consider the transport related error handling 
part.

---

From: Subir Das <[email-masked]>
Date: Mon, 05 Mar 2007 10:44:56 -0500

Sam,
Pl. see my answers below.

regards,
-Subir

> users of MIH services or to link layer?
   Subir> .21 service primitives are generated by MIH users, be it lower 
layers or higher layers. How to
               generate these primitives are purely implementation 
issue, AFAIK.
> protocol can be seen as a mechanism capabale of excellent extensibility. 
   Subir> What is this common functionality? Is it MIH protocol or 
something else?
> users of MIH services with the capability of assisting in discovering MIH
  Subir> Pl. refer to my answer to Robert in an earlier mail.

---

From: Subir Das <[email-masked]>
Date: Mon, 05 Mar 2007 11:08:16 -0500

Juan Carlos,
Pl. find few points below.

Thanks,
-Subir

> protocol, where no service-specific part is needed.
  Subir> Yes, what we need to carry the MIH protocol. MIH protocol 
carries the MIH services
              but that should be transparent to MIH transport. If we 
want to say that MIH protocol is
              the common part, that may be ok. But I think, we do not 
need to address that way. As
              I mentioned in an earlier mail, .21 defines a protocol and 
we in MIPSHOP provide
              the right transport for that until MIPSHOP wants to define 
additional protocol messages
              /headers on top of MIH protocol.
> between the discovery and the transport to avoid further complications. 
  Subir> Here splitting make sense since manual configuration is an 
option too.
> duplication of messages. I'm not sure what you mean by "left as
   Subir> Actually, the comment was general and not only for "duplicate 
message detection", but 
              of several points in this section. For example, head of 
line blocking, ordering, etc.

---

From: Subir Das <[email-masked]>
Date: Mon, 05 Mar 2007 11:32:03 -0500

Srini,
Few comments inline.

regards,
-Subir

> clarity. We should reflect the update based on these comments.

    Subir> That would be great.  I would say it should not be MIH 
service, it should be MIH protocol.
> SS> I am almost certain that there is NO requirement for secure
    Subir> That's even better.  I assume that you are referring  to  no 
requirement from .21.
> SS> Again, let's not mix up discovery with transport setup. There is no
  Subir> I agree and I tried to explain that in an earlier mail.
> recipient to know in the same order? Can the transaction ids determine
    Subir> I agree with that Transaction IDs are not sufficient and 
there is no hook in the MIH protocol
               either. But the question is that who maintains that 
ordering. If the MIH services are agnostic
               to transport, how transport will help that ordering 
either. Now I remember why I said, it
               is left as implementation. We need to something within 
MIHF implementation or at the MIH user
               level to address your example. Also the services may ask 
for different transport but that needs
               be set up in order to exchange the MIH messages anyway. 
So I do not understand your
               point on "overhead due to certain transport setup".
> cases where even trasnsport seq numbers are different. Yes, this can
   Subir> If the transport sequence numbers are same how it will arrive 
to the application in the
             first place?  I still think Transaction IDs are not 
sufficient always. We can discuss this
             more during Orlando meeting.
> transport is independent of the MIH versions. 
   Subir> That's good but AFAIK, MIH protocol has a version field 
already. What additional parameter
               do we need?

---

From: Sam Xia <[email-masked]>
Date: Tue, 06 Mar 2007 17:04:13 +0800

Hi, Subir

 Few comments inline.

 Best Regards, Sam Xia 

> Sent: Tuesday, March 06, 2007 12:08 AM
> To: Zuniga, Juan Carlos
> Cc: Sam Xia; Hancock, Robert; [email-masked]
> Subject: Re: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments
> 
> Juan Carlos,
> > for the section 2 discussion, and tagged some of your previous 
> > comments with your initials, just to make it easier for 
> other people 
> > to follow (I hope you don't mind).
> >
> > Regards,
> >
> > Juan Carlos
> >
> >
> >   
> >
> >
> >   
> >   
> >> to introduce the fact that there is some protocol 
> definition work in 
> >> the MIH services (== what .21 is doing for example), and 
> some in the 
> > between service and common part. In fact, we should not 
> mention here 
> > MIH Services at all, because it gives the impression that the 
> > transport should be service-aware and that is not correct. The 
> > services are transparent to the transport. We are supposed to solve 
> > the transport issue for MIH messages, which can carry ES, CS, or IS 
> > information. This level of detail is transparent to the transport 
> > layer which only sees a generic MIH message to be delivered, which 
> > comes from the same common MIH Function (MIHF). Therefore, the 
> > transport is indeed a common protocol, where no 
> service-specific part is needed.
> >   
>   Subir> Yes, what we need to carry the MIH protocol. MIH 
> protocol carries the MIH services
>               but that should be transparent to MIH 
> transport. If we want to say that MIH protocol is
>               the common part, that may be ok. But I think, 
> we do not need to address that way. As
>               I mentioned in an earlier mail, .21 defines a 
> protocol and we in MIPSHOP provide
>               the right transport for that until MIPSHOP 
> wants to define additional protocol messages

Sam> If Transaction ID could be used to solve the head of line blocking as
well as ordering, it should be increased linearly when being used. But the
.21 does not specify how to generate the Transaction ID.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 6 Mar 2007 15:18:12 -0500

Hi, 

One more comment at the end for the 21 folks.

Regards,

Juan Carlos

-----Original Message-----
From: Sam Xia [mailto:[email-masked]] 
Sent: March 6, 2007 4:04 AM
To: 'Subir Das'; Zuniga, Juan Carlos
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi, Subir

 Few comments inline.

 Best Regards, Sam Xia 

> line blocking, ordering, etc.

Sam> If Transaction ID could be used to solve the head of line blocking
as
well as ordering, it should be increased linearly when being used. But
the
.21 does not specify how to generate the Transaction ID.

JCZ> I agree with Sam. 
Srini, Subir, and other 21-folks: Could we address these versioning,
transaction id numbering, etc. issues all together during the 21 meeting
next week in Orlando?

---

From: <[email-masked]>
Date: Tue, 6 Mar 2007 14:34:07 -0600

JCZ> I agree with Sam. 

Juan,
As subir mentioned earlier it seems, we have version already in
capability exchange. I am doubtful it will work even if it were
monotonical. Sometimes, the trans-ids have to be skipped because the
messages are lost and timed out. We need to understand clearly what we
are trying to do with them. 

Regards,
Srini

-----Original Message-----
Sent: Tuesday, March 06, 2007 2:18 PM
To: Sam Xia; Subir Das

Hi, 

Regards,

Juan Carlos

-----Original Message-----
From: Sam Xia [mailto:[email-masked]]
Sent: March 6, 2007 4:04 AM
To: 'Subir Das'; Zuniga, Juan Carlos
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi, Subir

 Few comments inline.

 Best Regards, Sam Xia 

>               I mentioned in an earlier mail, .21 defines a protocol 
> and we in MIPSHOP provide
>               the right transport for that until MIPSHOP wants to 
> define additional protocol messages
> >>    Subir> This is something that need further discussion. Do we 
> >> need this as a requirement?
> >>
> >> think the paragraph is just a statement of fact. (Unless you 
> >> believe that the MIH service layer knows explicitly about IP 
> >> addresses of signalling peers and provides them to the transport.)
> >>     
> >
> > important aspects impacting on designing of the common functionality
> of protocol.
> > But

> > signalling messages and to improve the efficiency, it is very useful
> to provide the

>    Subir> Actually, the comment was general and not only for 
> "duplicate message detection", but

JCZ> I agree with Sam.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 6 Mar 2007 16:01:52 -0500

True, the MIH version is in the fixed fields of the MIH protocol header.
That's good news. 

For the transaction ids, I think that if we can identify the
requirements, we could come up with a simple rule in 21 that could
address them. However, I agree that we first have to understand what we
want to do, and translate it into clear requirements. Let's talk it over
next week...

Regards,

Jc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: March 6, 2007 3:34 PM
To: Zuniga, Juan Carlos; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

JCZ> I agree with Sam. 

Juan,

Regards,
Srini

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

Hi, 

Regards,

Juan Carlos

-----Original Message-----
From: Sam Xia [mailto:[email-masked]]
Sent: March 6, 2007 4:04 AM
To: 'Subir Das'; Zuniga, Juan Carlos
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] A modest proposal: Subir's comments

Hi, Subir

 Few comments inline.

 Best Regards, Sam Xia 

JCZ> I agree with Sam.