RE: [Rfid] Control Plane Architectural Elements
Margaret Wasserman <margaret@thingmagic.com> Sat, 23 July 2005 13:33 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK8L-0002zM-Vz; Sat, 23 Jul 2005 09:33:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK8K-0002zH-E5 for rfid@megatron.ietf.org; Sat, 23 Jul 2005 09:33:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24908 for <rfid@ietf.org>; Sat, 23 Jul 2005 09:33:38 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwKcm-0005DK-I0 for rfid@ietf.org; Sat, 23 Jul 2005 10:05:08 -0400
Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449704; Sat, 23 Jul 2005 09:27:30 -0400
Mime-Version: 1.0
Message-Id: <p062007e6bf07f4498da8@[192.168.1.105]>
In-Reply-To: <0E03681B885F3B4296B999E34435A16EBFF395@ms08.mse3.exchange.ms>
References: <0E03681B885F3B4296B999E34435A16EBFF395@ms08.mse3.exchange.ms>
Date: Sat, 23 Jul 2005 09:33:31 -0400
To: "P. Krishna" <pkrishna@revasystems.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Subject: RE: [Rfid] Control Plane Architectural Elements
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: rfid@ietf.org
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Control and Access of Infrastructure for RFID Operations Discussion List <rfid.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rfid>
List-Post: <mailto:rfid@lists.ietf.org>
List-Help: <mailto:rfid-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=subscribe>
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org
Hi Krishna, Yes, I saw your response earlier. Thanks for reminding me about it. Your response addressed the question of whether the reader can be set to run autonomously without continuous commands sent from the controller to the reader. I didn't remember that SLRRP included this functionality, so it may be time for me to re-read the SLRRP document. I do think that we should define how/if a reader is expected to continue this autonomous operation across a reboot (there are tradeoffs on both sides), but that is a detail, perhaps. There are three other parts of the operational mode that I am discussing that I do not think are captured in SLRRP: (1) I do not believe that the control and data connections should be conflated the way that they are in SLRRP. Even if we decide that a reader can only be controlled by a single controller, it should be possible for a reader to send tag data to more than one consumer and to maintain different filters and different event lists for different consumers. In addition to improving the scaling properties of the system, this would reduce the brittleness of the system (caused by the dependence on a single controller being up at all times). (2) It should not be necessary for a reader to maintain connectivity to the consumer(s) in order for the consumer(s) to see all of the applicable tag reads and events. If connectivity is lost, I believe that readers should cache tag reads and events until the connectivity can be reestablished (or until the cache wraps, of course). (3) I'd also like to see the reader support multiple paradigms for how tag reads and events are sent to consumers, including (at least): the reader and consumer maintain a constant connection over which tag reads and events are transmitted as they occur, the consumer polls the reader periodically for tag reads and events, and the reader actively notifies the consumer when tag reads or events of interest occur (sensor tripped, first tag detected, timeout expired, etc.). After such a notification, the consumer could poll for tag reads, establish a connection to receive tag reads, or do whatever made sense. In fact, it might even make sense to break the data and events out into separate sub-systems and maintain separate concepts of tag data consumers and event consumers. Margaret At 8:47 AM -0400 7/23/05, P. Krishna wrote: > but I think that this same type of > autonomous operation would also be valuable for basic readers that > only implement the lower-level reader control protocol (the RP level > in the EPC Global architecture). > Margaret Pls see ... <http://www1.ietf.org/mail-archive/web/rfid/current/msg00197.html>http://www1.ietf.org/mail-archive/web/rfid/current/msg00197.html This msg was sent couple of days ago and addresses the same concern raised in this email. /Krishna _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid
- [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements Scott Barvick
- Re: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- RE: [Rfid] Control Plane Architectural Elements P. Krishna
- RE: [Rfid] Control Plane Architectural Elements Margaret Wasserman
- Re: [Rfid] Control Plane Architectural Elements P. Krishna