[Rfid] Management vs. Control vs. Data

[Margaret Wasserman <[e-mail]>]

Another thought on our RFID reader control protocol (whatever we 
decide to name it)...

It seems to me that some of our discussions are mixing together the 
control plane (or control functions) and the data plane (or data 
functions).  We also seem to be combining the concepts of single 
reader control and multi-reader control (which includes concepts such 
as synchronization).  On some level, the management plane also seems 
to be conflated.

I think that we should be very clear about defining/understanding the 
functional blocks to in our RFID network architecture, and I think 
that we need to understand the relationships between those blocks and 
the requirements for each of them _before_ we decide that SLRRP is 
the correct starting place for an RFID reader control protocol.

The SLRRP protocol seems to make some basic assumptions in this area 
that I question.  It seems to assume four things:

(1) That there will be a one-to-many mapping between RFID controllers 
and RFID readers.  In other words, that only one controller (whether 
it is running on the reader, a controller device, a piece of 
networking equipment or a server) will be controlling a given reader 
at any point in time.  Given the nature of RFID readers, this _might_ 
be reasonable, although I would welcome alternatives. (This is a 
control plane function.)

(2) That single reader control functions and multi-reader control 
functions (such as synchronization) will both be controlled by the 
same controller functional unit.  (Another control plane function.)

(3) That the same functional unit that is controlling the reader will 
be the only first-line consumer for all of the readers' tag data and 
other events. (This is a data plane function.)

AND

(3) That the same functional unit will serve as the arbiter for all 
management/monitoring requests (this is a Management plane function.)

Actually, I am not sure that this is really intended in SLRRP, but it 
is implied by this text in the proposed charter:

    We envision a typical RFID deployment comprising of a network of RFID
    readers controlled by one or more reader network controller elements
    (which may be software in a server, RFID reader, control blade of a
    router/switch, or a standalone device). These controller elements in
    turn are connected to hosts/servers running client applications that
    ultimately consume the acquired tag data and management applications
    that monitor the operation of the reader network.

Do these three restrictions/conflations actually make sense?

I understand why (perhaps?) there should be a single controller that 
is taking requests from multiple applications and determining what 
RFID functions a specific reader should perform in order to carry out 
those requests.  This code could run on a smart reader itself, or on 
external node that controls one or more less-smart readers.

However, I see no reason why this one controller should be a choke 
point for the data plane.  The controller could configure the reader 
to know about one or more consumers and set filters that indicate 
what data should be sent to those consumers.  Then, the reader could 
transmit the data to the consumers directly.  This removes a 
third-party dependency on the controller in order for a reader that 
is operating autonomously (perhaps as configured by the controller) 
to send its data to a set of consumers.

I also understand that there might be a multi-reader coordination 
function that would generally run external to any of the readers. 
Although this is also a control-plane function, it might be better to 
break the single-reader control and multi-reader control into two 
separate functional boxes in our architecture, so that they can run 
in independent locations.  What do others think?

And, I certainly don't understand why an RFID controller should be 
involved in the management/monitoring of a reader -- I should be able 
to use a commercial management station (like Tivoli or HP Open View) 
to monitor the health of my readers and the state of their RFID 
functions via SNMP or other protocols without involving any third 
party.  Right?  For much-less-smart readers that are not capable of 
supporting SNMP, a proxy could run somewhere, I suppose...  But this 
doesn't have to be the same functional unit as the controller.

Are there specific reasons why the SLRRP architecture has a single 
controller handle the control, data and management functions?

Breaking these things into separate functional units in our 
architecture would not stop someone from running all of them on a 
single CPU, but it would allow us the flexibility to place different 
types of functionality at different places in the RFID network.

Margaret


_______________________________________________
Rfid mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rfid