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

Vijay Devarapalli wrote:

>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.
>  
>
I agree. Also specific text on use of the context-id will be incorporated.
However, since we found that the L2 ID has to carry kind of status code
to indicate to the MN in a reply that AR was not able to resolve the
requested L2 ID (issue#39), we can avoid the M-flag and incorporate all 
these
notifications into an 8 bit status code field within the L2 ID sub-option.
This means for example. 0x00 set by default in a CARD Request when
MN sends the L2 ID for resolution to its AR. AR can return 0x01 as an
OK indicator, 0x02 could be the indicator that L2 ID matches with a 
previously
resolved CAR IP address (context-id match, replaces the M-flag), 0x03 could
indicate the error case due to the AR was not able to resolve the L2 ID...

What do you think?

marco
     

>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
>>>>
>>>>
>>>>        
>>>>