Subject: [Rfid] SLRRP and SNMP

From: "Frederico, Gustavo" <[email-masked]>
Date: Thu, 21 Jul 2005 08:28:04 -0400

Can anyone please compare SLRRP and SNMP in their intentions?

Thanks,

Gustavo Frederico

Allstream

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

---

From: "Howard Kapustein" <[email-masked]>
Date: Thu, 21 Jul 2005 09:26:11 -0400

One delta:

SNMP = management

SLRRP = operations

SNMP = *management* of network 'things' (not merely one type of device) 

SLRRP = *operational* processing of rfid network readers

SLRRP targets questions like "how do I know what tags are passing by a
reader"

SNMP targets questions like "how do I know the reader is working"

Things like Tivoli/OpenView/... care about the latter.

Things like warehouse management systems care about the former.

            - Howard

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Frederico, Gustavo
Sent: Thursday, July 21, 2005 8:28 AM
To: [email-masked]
Subject: [Rfid] SLRRP and SNMP

 

Thanks,

Gustavo Frederico

Allstream

---

From: "Mountain, Highland M" <[email-masked]>
Date: Thu, 21 Jul 2005 09:17:37 -0700

Howard wrote>SNMP targets questions like "how do I know the reader is
working"

But if the tags are not passing through the reader, then the reader is
not working ~ SNMP issue with an RFID twist?  Is there not potential for
some overlap here?

Howard wrote>

One can look at other device classes and see device operations outside
of network operations captured by standard MIBs.  Take the printer mib
for example.  

Thoughts?

Highland Mary Mountain

(480) 552-3817

From: Howard Kapustein [mailto:[email-masked]] 
Sent: Thursday, July 21, 2005 6:26 AM
To: Frederico, Gustavo; [email-masked]
Subject: RE: [Rfid] SLRRP and SNMP

One delta:

SNMP = management

SLRRP = operations

            - Howard

 

 

Thanks,

Gustavo Frederico

Allstream

---

From: "Mountain, Highland M" <[email-masked]>
Date: Thu, 21 Jul 2005 11:05:01 -0700

>>One can look at other device classes and see device operations outside
of network operations captured by standard MIBs.

>>Take the printer mib for example.  

>Yes, very true.  >>Good, at least we agree on something.

>But SNMP doesn't fit very well for operational behaviors
(reading/writing/killing), for a variety of reasons.

Right, I never proposed SNMP should be used for such operational
behaviors, nor did I say the Printer MIB promotes printing docs through
SNMP.  What I see is the usefulness of the data being discussed in SLRRP
within SNMP.

Are you promoting SNMP= *management* using only those well known mibs
which have gone before (MIB-2, HOST-RESOURCES) without the potential of
new MIBs in the RFID reader space?

Let me rephrase one of my original statements:

But if the tags are not passing through the reader, because there is a
problem with the Reader, then the reader is not working and someone
should be notified to fix it ~ SNMP issue with an RFID twist?  

Once an SNMP manager receives a trap relating to the above, would it not
be useful to at least *view* relevant RFID related
operational/configuration info through an RFID reader MIB to aid in
diagnosing the problem.  Data like Antenna Configuration, Reader
Capabilities, and General tag read statistics could be useful in some
cases.  

How do Warehouse Management systems handle device faults and
troubleshooting?  Is their a notion of traps/alerts in these systems?

Highland Mary Mountain

(480) 552-3817

From: Howard Kapustein [mailto:[email-masked]] 
Sent: Thursday, July 21, 2005 9:41 AM
To: Mountain, Highland M; Frederico, Gustavo; [email-masked]
Subject: RE: [Rfid] SLRRP and SNMP

>But if the tags are not passing through the reader, then the reader is
not working ~ SNMP issue with an RFID twist?

If the reader reports no tags, is that because the reader's broken, the
tags are broken, or there really are no tags to read?

I'd expect 0 tag reads for a reader monitoring a dock door if nothing
goes thru the dock door.

>Is there not potential for some overlap here?

No.

Take a reader with a wire to the antenna and fry the antenna, where the
reader will power up but the antenna won't work. Some readers have no
built-in diagnostics and will blithely run, never reading anything from
that antenna.

Or even better, bake in diagnostics but now have a *partially* working
antenna, only working at, say, half the expected range/power/whatever.

SNMP is designed for such use cases.

The *consumers* of the data is very different.

Management vs. Operation data.

Management vs. Operation systems.

Tivoli cares about very different events and information than Warehouse
Management systems.

There's some overlap between "management" and "configuration" (where the
latter can be viewed as a subset of the former), but pragmatically you
can't divorce "configuration" from the operations side of the system.
[Well, you can, but it creates other headaches.]

The use cases and issues surrounding "management" and "operations" are
different, hence the reason SNMP may be a strong candidate for the
former (well, the SNMP protocol plus some MIBs), but a poor option for
the latter.

FYI there's enough of a delta here that EPCglobal has 2 workgroups,
Reader Protocol and Reader Management; RP 1.0's goal was "Reading,
Writing and Killing tags, and operations needed to support that" vs. RM
1.0's goal was (loosely stated) "managing readers".

That said, the RP+RM workgroups had a lot of overlap, and frequently
collaborated to varying degrees to jointly design solutions.

>One can look at other device classes and see device operations outside
of network operations captured by standard MIBs.

>Take the printer mib for example.  

Yes, very true.

But SNMP doesn't fit very well for operational behaviors
(reading/writing/killing), for a variety of reasons.

Certainly you -could- use SNMP to read tag info from a reader, but it's
not a good option.

Do *you* know of any application that uses SNMP to print a document on a
printer, instead of a "print" api/protocol? 

Here's a simpler way to think of your original question:

Change "RFID reader" + "SLRRP" to "web server" + "HTTP".

Can you please compare HTTP and SNMP in their intentions?

            - Howard

From: Mountain, Highland M [mailto:[email-masked]] 
Sent: Thursday, July 21, 2005 12:18 PM
To: Howard Kapustein; Frederico, Gustavo; [email-masked]
Subject: RE: [Rfid] SLRRP and SNMP

Howard wrote>

Thoughts?

Highland Mary Mountain

(480) 552-3817

One delta:

SNMP = management

SLRRP = operations

            - Howard

 

 

Thanks,

Gustavo Frederico

Allstream

---

From: "Howard Kapustein" <[email-masked]>
Date: Thu, 21 Jul 2005 14:21:59 -0400

>Once an SNMP manager receives a trap relating to the above, would it
not be useful to at least *view* relevant

>RFID related operational/configuration info through an RFID reader MIB
to aid in diagnosing the problem. 

One would think, which is one example why it's hard to cleanly divorce
"configuration" from "management".

OTOH, taking the previous example further, HTTP defines how you
interoperate with a web server, doesn't say anything about managing the
web server, but DOES refer to configuration-related elements, e.g. URLs.
Hard for an operational system to be totally divorced from at least some
key aspects of "configuration".

troubleshooting?

Depends on the system, but generally they consume and produce
'operational data' and management facilities handle 'management data'.

WM can get notified a box just rolled down a conveyor, but typically
wouldn't know or care that the conveyor is overheating (or whatever).

Is their a notion of traps/alerts in these systems?

Not in this level of conversation.

Ever hear of a Warehouse Control System? WCS?

Semi-common term for 'communication system that on the left side deals
with material handling equipment (MHE) like automated sorters and
conveyors, and on the right side deals with applications interested in
exchanging information them'.

So yeah, it's a sexy high falutin' term, but a WCS is basically a
communication subsystem.

Not universally common, there's lots of point-to-point interaction among
other things, but that's one scenario some may be familiar with.

In that picture, I think SLRRP targets the 'left' side of that picture -
MHE<->WCS

In the WCS/MHE world, there are no common standards that I'm aware of.

De facto standards sure, e.g. you could safely call the
Siemens-Diematic(sp?) WCS interface exposed to applications a 'de facto
standard'.

But I'm not aware of any 'formal' (standards body) standards for such
things (not any significant ones).

And it's even more diverse on the other side.

A standard protocol exposed by automated sorters or other MHE equipment?

Hahahahaha...

            - Howard

From: Mountain, Highland M [mailto:[email-masked]] 
Sent: Thursday, July 21, 2005 2:05 PM
To: Howard Kapustein
Cc: Frederico, Gustavo; [email-masked]
Subject: RE: [Rfid] SLRRP and SNMP

 

 

Highland Mary Mountain

(480) 552-3817

 

No.

 

 

 

Yes, very true.

 

            - Howard

Howard wrote>

Thoughts?

Highland Mary Mountain

(480) 552-3817

One delta:

SNMP = management

SLRRP = operations

            - Howard

 

 

Thanks,

Gustavo Frederico

Allstream