Subject: [Rfid] Control Plane Architectural Elements

From: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Jul 2005 14:55:02 -0400

Hi All,

I made this diagram of what I think the architectural elements should 
be in the Reader control plane:

                    +----------+   +----------+
		   |  Single  |   |  Multi-  |
                    |  Reader  |   |  Reader  |
		   |   App    |   |   App    |
                    +----------+   +----------+
       +- - - - - - - - -|- - - - - - - |- - - - -+
       | Basic           |       +- - - |- - - - -|- - - - - - +
       | Reader          |       | +----V-----+   |      Smart |
       | Controller      |       | |  Multi-  |   |     Reader |
       |                 |       | |  Reader  |   | Controller |
       |                 |       | |Controller|   |            |
       |                 |       | +----------+   |            |
       |                 |       +- - - |- - - - -|- - - - - - +
+- - -|- - - - - - - - -|- - - - - - - |- - - -+ |
|     |            +----V--------------V----+  | |
|     |            |         Single         |  | |
|     |            |         Reader         |  | |
|     |            |       Controller       |  | |
|     |            +------------------------+  | |
|     +- - - - - - - - - - - - -|- - - - - - - |-+
|                +- - - - - - - |- - - - - - - |- - - - - - - +
|                | +------------V-----------+  |              |
|                | |        Low-Level       |  |              |
|                | |          RFID          |  |              |
|                | |        Funcitons       |  |        Basic |
|Smart           | +------------------------+  |       Reader |
|Reader          +- - - - - - - - - - - - - - -|- - - - - - - +
+- - - - - - - - - - - - - - - - - - - - - - - +

As you can see, I think that we should separate the control plane 
into separate multi-reader and single reader control elements, to 
allow flexibility regarding the "intelligence" level of readers and 
the corresponding interface for controllers.

If I get a chance, I will make a similar diagram for the data plane, 
where I also beleive that there shold be more than two architectural 
elements.

Thoughts?

Margaret

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

---

From: Scott Barvick <[email-masked]>
Date: Fri, 22 Jul 2005 16:32:15 -0400

Margaret, 

Before we start down this path, I think we need to step back and note
that we have been working with Bert and the folks at EPCGlobal to make
sure that outputs from this group are compatible with the interacting
layers of the EPCGlobal Architecture Framework Version 1.0 which can be
found at:
http://www.epcglobalinc.org/standards_technology/specifications.html

The original charter proposal from the SLRRP BoF is quite consistent
with the definition of the Reader Protocol (Interface) in Section 9.1.5
of the Architecture Framework.  In fact, you'll find concepts from the
original SLRRP draft used directly in specifying this interface, and
SLRRP appropriately referenced in the References section.   

I am concerned that starting to work on a general reader architecture
would lead us into conflict with the architecture work that is done and
published by EPCGlobal.  I believe that many of your concerns
(autonomous operation, XML interface) are satisfied by the Filtering and
Collection (Interface), also known as Application Level Events or ALE,
in the EPCGlobal Architecture, and we have never wanted to duplicate
this effort with this proposed working group.  As you know, ALE is an
interface that higher end readers will choose to run, but EPCGlobal also
recognizes that there is a need for an interface to readers that is at a
lower level in the architecture.

Therefore, I think we need to stay more true to the CAIRO proposed
charter until the group and/or Bert/IESG decides to change it to take it
in a different direction.  We have made a lot of progress with the spec
and resulting implementations on the reader, RNC, and tools ends of
things based on the current charter proposal, and I strongly recommend
we stay focused.  

Thanks,
Scott

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Jul 2005 17:15:44 -0400

Actually the architectural diagram I sent is quite consistent with 
the EPC Global architecture -- you can view ALE as the multi-reader 
controller and RP as the single reader controller.  Both interfaces 
might be exposed by a smart reader (for different types of 
applications/middleware), and so I think that there is a large 
benefit to having them be consistent (i.e. having them use the same 
terminology for the same concepts, and the same respresentations for 
shared data types, etc.)

For example, I am not sure how you can claim that the fact that XML 
is used at a higher-level interface argues _against_ it being used at 
a lower level.  Quite the opposite, I would think.

Also, I wonder how we can design a reader control protocol that is 
consistent with the EPC Global architecture given two important 
facts:  (1) We (the whole IETF community) can't see the current 
versions of the EPC Global architecture and the protocols that would 
exist on top, below and beside this protocol, because documents under 
development in EPC Global are only available to members, and (2) EPC 
Global already has a effort for every protocol included in their 
architecture, so we would presumably be developing a suite that is a 
technical competitor to theirs.

Is it your idea that the IETF reader control protocol would be 
required to plug into the EPC Global architecture in the place of the 
RP element?  Or the RP and RM elements?  Or the RP, RM & ALE 
elements?  Your current and future charter items seems to range 
pretty far outside of RP alone.

The last charter I saw is certainly not clear on this point, as it 
refers to EPC Global as an "air interface standards body", which is 
about as inaccurate as referring to the IETF as a "layer 3 standards 
body".

>things based on the current charter proposal, and I strongly recommend

I am not really sure what this means...  Are you saying that 
discussing whether or not SLRRP is based on the right architectural 
and technical choices is out-of-scope for this WG and that we are 
just here to standardize SLRRP more-or-less as-is?  This isn't even 
an IETF WG yet, so being so set on a particular solution at this 
point doesn't seem reasonable to me.  As far as I know, only one 
vendor was involved in the definition of SLRRP and few (if any) 
reader vendors have been significantly involved in its evolution.

I also have to admit to being somewhat uncomfortable about the fact 
that someone from Reva is shutting down discussion about whether or 
not SLRRP is the correct architectural choice, given that this is 
currently your company's proprietary protocol.  Does that seem at all 
strange to you?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Jul 2005 17:21:19 -0400

At 4:32 PM -0400 7/22/05, Scott Barvick wrote:
>  I believe that many of your concerns

BTW, the idea that a reader could be told to function autonomously, 
delivering its data directly to a set of consumers without dependence 
on a third-party controller is not even touched upon by ALE, since 
ALE is an interface between higher level applications and middleware. 
It is true that this interface may be available (at some point in the 
future) on a smart reader, 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