Re: Comments on draft-irtf-mobopts-l2-abstractions-01 (was Re: [Mobopts] RG last call)

Hi Christian,

Thank you very much for your detailed comments.
I am sorry for my delayed reply.

Please find my comments inline:

On 2006/10/09, at 15:49, Christian Vogt wrote:

> Hi authors,
>
> cross-layer interaction between L2 and L3 is an important topic given
> the increasing use of mobility and multi-homing across heterogeneous
> networks.  I think it is good that you are working on this.
>

Thanks.

> OTOH, I do concur with the observation recently raised on the ML that
> there is an obvious overlap between your work and the ongoing work of
> the IEEE 802.21 working group.  (IEEE 802.21 is working on the  
> topic in
> a broader context.  E.g., it also considers over-the-network events,
> commands, and information retrieval.)  I won't further comment an any
> potential conflicts between your work and the work of IEEE 802.21, but
> do state my personal opinion that the two proposals should be  
> harmonized
> and possibly merged.
>

I agree that two proposals should be harmonized.
We are looking forward how we can process that.

> Architectural differences compared to IEEE 802.21
>
> - Your proposal does not strictly differentiate between events,
> commands, and information retrieval services, as the IEEE 802.21 work
> does.  (I recognize that you are using different "types" of  
> primitives,
> but nonetheless.)  It may be of benefit if you stated at some place in
> the beginning of the draft that you don't make/need this
> differentiation.  It's one of the main architectural differences  
> between
> your work and the IEEE 802.21 work.
>

Right.
Our approach works fine for simple handover scenarios (e.g. same  
domain, same network access), but we may need more information for a  
complex handover scenarios (e.g. inter domain, mixed network  
access).  I am not sure now.  So we need to discuss how much impact  
the difference has.

> - You may also want to mention in the very beginning that your  
> approach
> does not use an intermediate shim layer through which primitives are
> exchanged.  This is another architectural difference between your work
> and the IEEE 802.21 work, which defines an MIH function between L2  
> and L3.
>

Right.
We would like to have something works with the current deployed  
wireless networks.
We do not want to add new entities in the network.

> Section 2, Terminology.
>
> - You should do without the definition of "peer" IMO; use "point of
> attachment" or "attachment point" instead.  "Peer" has a widely  
> accepted
> end-to-end meaning, where a peer of node X is another node Y with  
> which
> X communicates at application layer.  Defining the peer to be an  
> access
> point may be confusing.
>

OK, I agree to use another world.

> Section 3, Primitives for L2 Abstractions
>
> - The draft defines a Confirm primitive to be the reply for a Request
> primitive, and the Response primitive to be the reply for an  
> Indication
> primitive.  Intuitively, I would have matched Request with  
> Response, and
> Indication with Confirm, in which case figure 1 would look like this:
>
>         ------------------------------------------------------
>                   Request                    Confirm
>                     ||      /\          /\      ||
>         Layer N     ||      ||          ||      ||
>         ------------||------||----------||------||------------
>                     ||      ||          ||      ||
>                     \/      ||          ||      \/
>         Layer N-m        Response   Indication
>         ------------------------------------------------------

Agree.  less confusing.

> - You define Protocol Layer ID and Protocol ID fields to be  
> included in
> all primitives.  Are these fields really necessary?  After all, the
> primitives are delivered directly from a protocol instance at one  
> layer
> to a protocol instance at another layer, so what is the purpose of
> having the destination field?  The primitives are not relayed or
> distributed anywhere where the destination fields might have to be
> consulted, as they would by an intermediate shim like like the MIH
> function in IEEE 802.21.
>

We are thinking that the messages are exchanged between layers by  
using e.g. routing socket.   It is an information method in which lll  
entities can hear all message.  The protocol layer ID is used to  
filter unnecessary message, for example.

> Section 4.7, L2-LinkGoingDown (Type 2)
>
> - The text in this section describes the registration process for the
> Link Going Down event:
>
>>                                    In the registration processing,  
>> the
>>    L2-LinkGoingDown.request primitive carries the "Network  
>> Interface ID"
>>    parameter and the "Enable/Disable" parameter.
>
> According to section 3, /all/ type 2 primitives use registration, but
> the registration process is explained only here.  I'd therefore
> recommend to move the above text to the beginning of the section, and
> generalize it so that it becomes applicable to all type 2 primitives.
>

I agree.

> - It is not clear whether a protocol interested in a type 2 primitive
> must re-register for the primitive after it has received the primitive
> once.  E.g., if a movement detection daemon on a mobile node registers
> for the Link Going Down primitive and eventually receives one such
> primitive, does it have to register again in order to receive a Link
> Going Down primitive for the next handoff?
>

Such re-registration is not necessary.  I will make it clear in the  
draft.

> Section 6.2, Condition
>
> - You may want to state that the conditions provided should be limited
> to those which do not change rapidly for other reasons than the  
> behavior
> of the node implementing L2 abstractions.  E.g., another interesting
> link condition might be the access latency for the medium.  But the
> access latency may be a function of the number of other nodes  
> competing
> for bandwidth, and hence is a very dynamic condition even if the node
> implementing L2 abstractions does not move and does not change
> communications patterns.  It may hence be difficult to implement  
> another
> "access latency" link condition.
>

Right.  Do you think the state is needed to be more clear?

> Section 7, Architectural Considerations
>
>>    [4]   Upper layers should utilize a timely recovery step so as to
>>          limit the potential damage from link indications  
>> determined to
>>          be invalid after they have been acted on.
>>
>>          The proposed L3-driven handover described in Appendix D uses
>>          the L2-LinkGoingDown indication as the trigger for starting
>>          handover.  L2-LinkGoingDown is indicated when the link  
>> quality
>>          goes down below the specific threshold.  This indication  
>> is not
>>          canceled even if the link quality goes up soon.  As  
>> described
>>          above, L2-LinkStatus can be used to detect the most suitable
>>          AP.  The IP layer can cancel a handover if it finds that the
>>          current AP is the most suitable one by using L2- 
>> LinkStatus when
>>          L2-LingGoingDown is notified.
>
> You could avoid possible issues with anticipatory indications if you
> replaced the Link Going Down indication (which is the only  
> anticipatory
> indication in your draft) by periodic or on-demand link status reports
> which notify an interested upper-layer protocol of link status  
> changes.
>  The upper-layer protocol can then make its own projections about when
> the current link attachment will go down due to decreasing signal  
> quality.
>
> (Note that an additional use case for the similar Link Going Down
> indication in IEEE 802.21 is for the network to warn a mobile node  
> about
> a forthcoming shutdown of a base station.  You don't define
> over-the-network indications in your draft, so you may not actually
> depend on the Link Going Down indication.)
>

Sorry, I do not see your point.

>>    [8]   Proposals should avoid race conditions, which can occur  
>> where
>>          link indications are utilized directly by multiple layers of
>>          the stack.
>>
>>          Since our proposal defines the link indications to only  
>> the IP
>>          layer, race conditions between multiple layers never happen.
>
> But there may be race conditions between protocols on the same layer.
> Take, e.g., Mobile IPv6 and Stateless Address Autoconfiguration.  If
> Mobile IPv6 tries to register a new care-of address once it receives
> a Link Up indication, Stateless Address Autoconfiguration may not yet
> have such a new care-of address configured.  The configuration of a  
> new
> care-of address further depends on router and prefix discovery, which
> may also be triggered by the same Link Up indication.  So there are
> plenty of race conditions, and all of them are within the IP layer.
>

Hum..  You are right.  I will change the text.

Thank you very much again,
Koshiro

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts