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

[Christian Vogt <[e-mail]>]

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

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/



Rajeev Koodli wrote:
> Folks,
> 
> This is the last call for comments on
> 
> draft-irtf-mobopts-l2-abstractions-01.txt
> 
> The last call expires on October 20, 06.
> 
> Please provide your input by then.
> 
> Thanks,
> 
> -Rajeev




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