Re: [netlmm] Timestamp Option for Message Ordering

"Vijay Devarapalli" <vijay@wichorus.com> Tue, 29 July 2008 13:06 UTC

Return-Path: <netlmm-bounces@ietf.org>
X-Original-To: netlmm-archive@optimus.ietf.org
Delivered-To: ietfarch-netlmm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422443A68EB; Tue, 29 Jul 2008 06:06:01 -0700 (PDT)
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D0A28C266 for <netlmm@core3.amsl.com>; Tue, 29 Jul 2008 06:06:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvLqawiWC11r for <netlmm@core3.amsl.com>; Tue, 29 Jul 2008 06:05:55 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B17813A68EB for <netlmm@ietf.org>; Tue, 29 Jul 2008 06:05:55 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 29 Jul 2008 09:06:03 -0400
Message-ID: <DE33046582DF324092F2A982824D6B0303CB9FD0@mse15be2.mse15.exchange.ms>
In-Reply-To: <e75f55e20807290459m3bd35523tdb22a8fb10e13750@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Timestamp Option for Message Ordering
Thread-Index: AcjxcwalFVkK8L9UQeuzuNtcHpQjKgACLQMg
References: <e75f55e20807290459m3bd35523tdb22a8fb10e13750@mail.gmail.com>
From: Vijay Devarapalli <vijay@wichorus.com>
To: Sandesh <sksodhi@gmail.com>, netlmm@ietf.org
Subject: Re: [netlmm] Timestamp Option for Message Ordering
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: netlmm-bounces@ietf.org
Errors-To: netlmm-bounces@ietf.org

Sandesh,

> I am proposing a solution for the problem which
> section '5.5 Timestamp Option for Message Ordering'
> of draft-ietf-netlmm-proxymip6-18.txt intends to solve.
> Please ignore this mail if this approach has been discussed earlier.
> 
> IMO problem can be defined as following -
> ------------------------------------------
> When LMA has received two or more PBU message for binding
> lifetime extension
> from two or more MAGs (and has not received PBUs from with
> lifetime = 0
> indicating MN detachment from all except one) then (in the
> absence of sequence
> number and timestamp) how can it be find out which MAG the MN is
> actually connected to. 

One of the approaches, the timestamp or the sequence number is always
used. So we don't have a scenario where neither are present. 

Vijay

> 
> SOLUTION
> ------------------------------------------
> In this solution a new trigger type in BRI (from LMA to MAG)
> is added which
> indicate 'PBU Registration Confusion'.
> 
> MAG Procedures -
> MAG PROCEDURE 1. MAG retransmits PBU if matching PBA is not
> received before
>   retransmission timeout. If MN is attached to MAG it keeps on
>   retransmitting PBU until it receives matching PBA. If MN detaches
>   from MAG it retransmits PBU with lifetime = 0 a number of times (N).
> MAG PROCEDURE 2. MAG sends PBU again if it receives BRI (Trigger =
>   PBU Registration Confusion). And after that it does PBU
> retransmissions as per MAG PROCEDURE 1. 
> 
> LMA procedures -
> LMA CASE 1: LMA received two or more PBUs (with lifetime !=0)
> and it has not
> sent PBA to any of the MAGs.
> It does not send PBA to any MAG. Soon it will receive the PBUs
> with lifetime = 0 from MAGs from which MN has detached and
> PBU(lifetime !=0) retransmission from MAG to which MN is actually
> attached. 
> MN is considered to be attached to a MAG if and only all MAGs
> except one sends
> PBUs(lifetime = 0) and that one MAG sends PBU (lifetime !=0).
> A max timer can be defined to declare that MN is not attached
> to the MAG if no
> PBUs are received from a MAG (which first sent PBU with
> lifetime !=0) for
> that max timer duration.
> After the decision has been taken about which MAG an MN is
> attached to PBAs
> (status =0) are sent to all the MAGs.
> 
> 
> LMA CASE 2: LMA received two or more PBUs (with lifetime !=0)
> and it has
> sent PBA (Status = 0) to one of the MAGs.
> LMA send BRI(Trigger = PBU Registration Confusion) to the MAG to
> which it has sent PBA (Status = 0). After that LMA follows the
> procedure defined in Case 
> 
> Sequence number in PBU can be considered per MAG and can be
> used to drop
> old/duplicate PBUs from the same MAG.
> 
> Disadvantage of this approach is that it will take little
> longer to declare
> which MAG a MN is attached to.
> 
> Advantages of this solution are -
> - MAG need not send timestamp to LMA in PBUs
> - MAG need not sync sequence number with other MAGs.
> 
> Thanks and Regards,
> Sandesh
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www.ietf.org/mailman/listinfo/netlmm