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
- [netlmm] Timestamp Option for Message Ordering Sandesh
- Re: [netlmm] Timestamp Option for Message Ordering Sri Gundavelli
- Re: [netlmm] Timestamp Option for Message Ordering Vijay Devarapalli
- Re: [netlmm] Timestamp Option for Message Ordering Sandesh