[netlmm] Timestamp Option for Message Ordering

Sandesh <sksodhi@gmail.com> Tue, 29 July 2008 12:02 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 3FA8F3A6A73; Tue, 29 Jul 2008 05:02:37 -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 746DE28C0EE for <netlmm@core3.amsl.com>; Tue, 29 Jul 2008 04:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 eUyGznwlraaD for <netlmm@core3.amsl.com>; Tue, 29 Jul 2008 04:59:25 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 8EF4D28C10D for <netlmm@ietf.org>; Tue, 29 Jul 2008 04:59:25 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so4112157rvf.49 for <netlmm@ietf.org>; Tue, 29 Jul 2008 04:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=1rR91+/Y6QAc3vLC/kIfHaAB4CZC8pX/tm6HHliE0jU=; b=MMsn0BPnUXcXkDGgH9c2+iMr82hAyRSSWQRaFYJwHhixoY4VV0FifD69kh6HGUzeaB iRrNoI8SvyFJt6pRhocgrcd+V7m5GbzIdXvmGVvXjbhV6hJL2uVOHlVJFnDq6otb/ewP 3os7HSUA2dRLvOLJyUymBtyJ+Mbs0keTdgLEE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=mUbehXIMm2i4MNK2joXv/Mx6lmCf6st63q5ngLwGCrc2+TOiOyHb+UIcPqQbJKm5nn rLTMDEHPrLbYB/Sx1WWoVbRa1OHPyofSFa25W/Qam1dEj2z/pPkq1tHToBj38jGow6JD dCHoFoXv6EZtqcmT3/x6gOD3kmu0QGZovNnFk=
Received: by 10.140.193.16 with SMTP id q16mr2974460rvf.109.1217332777867; Tue, 29 Jul 2008 04:59:37 -0700 (PDT)
Received: by 10.141.141.10 with HTTP; Tue, 29 Jul 2008 04:59:37 -0700 (PDT)
Message-ID: <e75f55e20807290459m3bd35523tdb22a8fb10e13750@mail.gmail.com>
Date: Tue, 29 Jul 2008 17:29:37 +0530
From: Sandesh <sksodhi@gmail.com>
To: netlmm@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
Subject: [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

Hi All,

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.

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