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