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

[Rajeev Koodli <[e-mail]>]

Hi Christian,

Thanks for your input. I am sure the authors will find them worthwhile.

I wanted to mention that we as an RG here should focus on the technical
content rather than worrying about the "overlap" with 802.21.
As I have mentioned previously, we should view this as a comprehensive
investigation of L2 and L3 interactions in handovers and not necessarily as
a study of 802.21. As was pointed out earlier in the ML, the authors could
look into the gap between the primitives here and what 802.21 has defined.

So, let's keep the focus on what this ID talks about in perspective. And,
thank you for your other detailed comments.

-Rajeev
 


On 10/8/06 11:49 PM, "ext Christian Vogt" <[e-mail]> 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.
> 
> 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.
> 
> 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.
> 
> - 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.
> 
> 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.
> 
> 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
>         ------------------------------------------------------
> 
> - 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.
> 
> 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.
> 
> - 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?
> 
> 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.
> 
> 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.)
> 
>>    [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.
> 
> So far, so good.
> 
> Best regards,
> - Christian


_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts