Re: CARD issue#29: more text on use of "Context-ID" and"M-flag"required

Marco Liebsch wrote:
> 
> This is exactly what the current protocol description proposes. But only
> adding the L2_ID sub-option in the reply does not solve the problem. You
> can see in the
> example below that in case two or more L2_IDs connect to the "same" CAR,
> this is indicated with the M-flag (M=matched) in the L2_ID coming back
> to the MN with the
> CARD Reply. Sending back L2_ID with a CARD Reply in case this
> particular L2 ID does "not" connect to a CAR that has been already
> previously resolved, is redundant. Actually, a L2 ID that comes back with
> a CARD Reply could be taken already as an indicator that the respective
> context-ID
> has been adjusted to a previously received conext, this could avoid the
> M-flag.
> 
> What do you think?

this sounds fine. but now there is a need to explain how
the Context-ID is managed at the MN. the MN needs to store
the Context-ID along with the information it stores for
a particular L2-ID. and it probably makes sense to use a 
linearly increasing number space for the Context-ID so that 
Context-IDs are not reused often.

Vijay


> 
> marco
> 
> Vijay Devarapalli wrote:
> 
> >I am against using this mechanism. why not just include
> >the L2_ID suboption in the CARD reply too? ofcourse it
> >would increase the number of bytes in the CARD reply,
> >but I think it helps in reducing the overall complexity
> >of the CARD protocol.
> >
> >Vijay
> >
> >Marco Liebsch wrote:
> >
> >
> >>Hi all,
> >>
> >>going through the remaining open issues, there are some
> >>important ones, which have not been discussed during the
> >>meeting in Vienna. Here is one:
> >>
> >>There was a comment that more text w.r.t use of Context-ID
> >>and the M-flag is required. The proposal is to briefly describe
> >>the mechanism again and to solicit comments. After having agreed
> >>on a mechanism, more text will be added to the document.
> >>Please find a desciption/example of the proposed mechanism below:
> >>
> >>Since the L2 ID, a CAR's IP address and associated capabilities come
> >>with separate sub-options in a CARD Request/Reply message,
> >>association is indicated using a Context-ID.
> >>Example:
> >>
> >>MN listens to L2_ID(1) and L2_ID(2), sends them to its current AR
> >>in a CARD Request for resolution:
> >>
> >>CARD Request (MN->AR)
> >>L2_ID(1) comes with one L2_ID sub-option, Conext-ID=1
> >>L2_ID(2) comes with one L2_ID sub-option, Conext-ID=2
> >>
> >>Now, first assume both L2_IDs (APs) connect to 2 different
> >>CARs, hence, associated IP address and capability container
> >>is identified with the respective Context-ID :
> >>
> >>CARD Reply (AR->MN)
> >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
> >>IP address of CAR(2) comes with capability container(2), both carry Context-ID=2.
> >>
> >>Now assume L2_ID(2) and L2_ID(1) connect to the "same" CAR:
> >>IP address of CAR(1) comes with capability container(1), both carry Context-ID=1.
> >>L2_ID(2) comes back with "Context-ID=1", "M-flag=1".
> >>
> >>M-flag avoids to send IP address and capability container of the same CAR
> >>back the the MN twice. Hence, Context-ID of L2_ID(2) has been re-addressed
> >>to Context-ID=1, M-flag indicates that Context-ID has been modified by the
> >>AR and that associated CAR IP address and associated capability container
> >>is the same as for a previously received IP-address/capability
> >>container pair, here indicated with Context-ID=1.
> >>
> >>Comments?
> >>
> >>marco
> >>
> >>_______________________________________________
> >>Seamoby mailing list
> >>[email protected]
> >>https://www1.ietf.org/mailman/listinfo/seamoby
> >>
> >>