Note: Descriptions are shown in the official language in which they were submitted.
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
METHODS AND DEVICES FOR LOCATING AND PROVISIONING RFID
DEVICES AND RELATED NETWORK DEVICES
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to provisioning RFID devices and related
network devices.
2. Description of the Related Art
Bar codes containing a Universal Product Code ("UPC") have become a
nearly ubiquitous feature of modern life. The vast majority of products, as
well as
packages, containers and other elements in the stream of commerce now bear a
bar
code to allow for convenient tracking and inventory control.
However, bar codes have some drawbacks. Bar codes are "read only," in that
they are merely a printed set of machine-readable parallel bars that cannot be
updated.
Bar codes cannot transmit information, but instead must be read by a scanner.
Bar
codes must be scanned within a relatively short distance and must be properly
oriented for the bar code to be read.
"Smart labels," generally implemented by RFID tags, have been developed in
an effort to address the shortcomings of bar codes and add greater
functionality.
RFID tags have been used to keep track of items such as airline baggage, items
of
clothing in a retail environment, cows and highway tolls.
In theory, RFID tags and associated RFID devices (such as RFID readers and
printers) could form part of a network for tracking a product (or a group of
products)
and its history. However, various difficulties have prevented this theory from
being
realized. One problem that has required considerable time and energy from RF
engineers is the development of lower-cost RFID tags with acceptable
performance
levels. Inductively-coupled RFID tags have acceptable performance levels.
These
tags include a microprocessor, a metal coil and glass or polymer encapsulating
material. Unfortunately, the materials used in inductively-coupled RFID tags
make
them too expensive for widespread use: a passive button tag costs
approximately $1
and a battery-powered read/write tag may cost $100 or more.
- 1 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
Capacitively-coupled RFID tags use conductive ink instead of the metal coil
used in inductive RFID tags. The ink is printed on a paper label by an RFID
printer,
creating a lower-cost, disposable RFID tag. However, conventional capacitively-
coupled RFID tags have a very limited range. In recent years, RF engineers
have
been striving to extend the range of capacitively-coupled RFID tags beyond
approximately one centimeter.
In part because of the significant efforts that have been expended in solving
the foregoing problems, prior art systems and methods for networking RFID
devices
are rather primitive. RFID devices have only recently been deployed with
network
interfaces. Device provisioning for prior art RFID devices is not automatic,
but
instead requires a time-consuming process for configuring each individual
device.
Prior art RFID devices and systems are not suitable for large-scale deployment
of
networks of RFID devices.
Conventional RFID devices also have a small amount of available memory.
A typical RFID device may have approximately .5 Mb of flash memory and a total
of
1 Mb of overall memory. The small memories of RFID devices place restrictions
on
the range of possible solutions to the problems noted herein. In addition, an
RFID
device typically uses a proprietary operating system, e.g., of the
manufacturer of the
microprocessor(s) used in the RFID device.
Moreover, many RFID devices are deployed in a hostile industrial
environment (such as a warehouse or factory) by relatively unskilled "IT"
personnel.
If a device deployed in one location fails, for example, it may simply be
removed and
replaced by a functioning device that was deployed in another location.
Moreover, RFID devices are being deployed with "static" knowledge of
where the device was deployed at the original time of deployment. In practice,
RFID
devices are moved if another device is damaged or not functioning. In general,
it is
desirable to allow for the movement of RFID devices. However, if an RFID
device is
moved, prior art systems do not know to what location the RFID device has been
moved.
It is becoming commonplace for devices, including but not limited to RFID
readers, RFID printers, VoIP telephones and devices used in manufacturing, to
be
deployed in large numbers within some networks. These devices often have
unique
characteristics, such as traffic type, bandwidth requirements, security
demands, etc.
Accordingly, such devices require specific network configurations, e.g.,
quality of
- 2 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
service ("QoS"), security settings, VLANs or VSANs, etc. to properly support
their
desired functionality.
Within network 1000, a large number of devices and associated
network devices may be deployed. In general, it is a tedious and time-
consuming
process for users to deploy devices and to manage the associated
infrastructure
components, such as switches and other network devices. For example, the
process
of configuring switch port settings is currently a manual process, in which
each
desired attribute must be individually selected and enabled for a port.
This manual configuration process is currently inhibiting the deployment of
large-scale RFID networks, manufacturing device networks, etc. It would be
desirable to provide improved methods and devices that overcome at least some
limitations of the prior art.
SUMMARY OF THE INVENTION
Methods and devices are provided for identifying and provisioning individual
RFID devices in a network. According to some implementations of the invention,
a
combination of EPC code information and existing networking standards form the
basis of identifying and provisioning methods. For example, MAC address
information and EPC information can be combined to identify a particular
device and
its location in a network. Upper-level applications can be notified, for
example, that a
particular RFID device is available for use.
For implementations using the Dynamic Host Configuration Protocol
("DHCP"), DHCP Options may be used to pass identification, location and
provisioning information. For example, selected DHCP Options may be used to
indicate whether a device is an RFID device, to provide an EPC code uniquely
identifying the particular device, indicating the company name using the
device and
indicating how the device is being used.
Some such implementations of the invention use DHCPREQUEST and
DHCPINFORM (RFC 2131) and DHCP Options (RFCs 2132 and 3004) to pass
current provisioning and personality information. Moreover, some such
implementations of the invention use the DHCPFORCERENEW command (RFC
3203) from a DHCP server to initiate an update or to complete reconfiguration,
as
required.
- 3 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
In order to secure the DHCPFORCERENEW command, some
implementations provide for a cached secret to be hashed with a client EPC
that is
included with the DHCPREQUEST from the RFID device and the response from the
DHCP server. Some implementations employ Domain Name Service ("DNS") and
dynamic DNS ("DDNS") to allow easy identification of RFID devices.
Some aspects of the invention provide a method for uniquely provisioning a
radio frequency identification ("RFID") device. The method includes the
following
steps: receiving a provisioning request on a network; automatically
identifying an
RFID device according to a media access control ("MAC") address and an
electronic
product code ("EPC") included in the provisioning request; and automatically
locating the RFID device according to location information included in the
provisioning request. The method may be performed by a network device such as
a
Dynamic Host Configuration Protocol ("DHCP") server.
The method may include the step of comparing information in the
provisioning request with other information, in order to validate the RFID
device.
The method may also include the steps of determining whether the RFID device
has
previously booted and/or of determining whether provisioning information has
previously been established for the RFID device.
The RFID device may be provisioned when it is determined that provisioning
information has previously been established for the RFID device. The RFID
device
may be categorized as an untrusted device if it is determined that
provisioning
information has not previously been established for the RFID device.
Alternative aspects of the invention provide another method for uniquely
provisioning an RFID device. The method includes the following steps: forming
a
DHCPDISCOVER request that includes an EPC of an RFID device and location
information indicating a location of the RFID device; sending the DHCPDISCOVER
request to a DHCP server; and receiving provisioning information from the DHCP
server that is specifically intended for the RFID device.
The forming step may involve including the EPC in an Option field (e.g.,
Option 61) of the DHCPDISCOVER request. The forming step may involve
including information (e.g., in Option 60) of the DHCPDISCOVER request that
indicates that the DHCPDISCOVER request comes from an RFID device. The
forming step may also involve including information in the DHCPDISCOVER
request that indicates a name of a company that provides, owns or operates the
RFID
- 4 -
T8470440CA\TOR_LAW\ 6924772\l
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
device. Moreover, the forming step may involve including information (e.g., in
Option 77) of the DHCPDISCOVER request regarding the type of RFID device that
formed the DHCPDISCOVER request.
An RFID device may include the EPC during a first part of the forming step.
A relay agent may include the location information in the DHCPDISCOVER request
during a second part of the forming step. Alternatively, the RFID device may
include
the location information in the DHCPDISCOVER request.
Some embodiments of the invention provide an RFID device, including: a
flash memory; a processor configured to form a DHCPDISCOVER request that
includes an EPC of an RFID device in Option 61, according to instructions in
the
flash memory; and a network interface for sending the DHCPDISCOVER request to
a
DHCP server.
Other embodiments of the invention provide a computer program embodied in
a machine-readable medium, the computer program including instructions for
controlling one or more elements of an RFID network to perform the following
steps:
form a DHCPDISCOVER request that includes an EPC of an RFID device and
location information indicating a location of the RFID device; send the
DHCPDISCOVER request to a DHCP server; and receive provisioning information
from the DHCP server that is specifically intended for the RFID device.
Still other embodiments of the invention provide a computer program
embodied in a machine-readable medium, the computer program including
instructions for controlling a network device to perform the following steps:
receive a
provisioning request on a network; identify an RFID device according to a MAC
address and an EPC included in the provisioning request; and locate the RFID
device
according to location information included in the provisioning request.
Yet other aspects of the invention provide methods for deploying an RFID
device in a network. One such method includes the following steps: forming a
DHCPDISCOVER request that includes an EPC of an RFID reader and location
information indicating that the RFID reader is positioned at an exit door of a
retail
store; sending the DHCPDISCOVER request to a DHCP server; receiving
provisioning information from the DHCP server that is specifically intended
for the
RFID reader; and provisioning the RFID reader according to the provisioning
information, thereby enabling the RFID reader to read RFID tags passing
through the
- 5 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
exit door and to transmit RFID tag information to an RFID network. The RFID
tag
information may include product information and/or shopper information.
The method may involve the step of using the RFID tag information to cause a
financial account to be debited for the cost of the products. The RFID tag
information may be used to automatically update a database maintained by the
retail
store and/or a database maintained by a manufacturer/producer, wholesaler
and/or a
distributor of at least one of the products. The RFID tag information may be
used to
update a business plan, such as a marketing, manufacturing, distribution or
sales plan.
Still other embodiments of the invention provide an RFID network, including:
a plurality of RFID devices; a plurality of switches connecting the RFID
devices to
the RFID network; and a DHCP server. In some such embodiments, at least some
of
the RFID devices are configured to do the following: form a DHCPDISCOVER
request that includes an EPC of an RFID device; send the DHCPDISCOVER request
to the DHCP server via a switch; and receive provisioning information from the
DHCP server that is specifically tailored for the RFID device. The switch is
configured to add location information to the DHCPDISCOVER request indicating
a
location of the RFID device. The DHCP server is configured to receive a
DHCPDISCOVER request, to automatically identify an RFID device according to a
MAC address and an EPC included in the DHCPDISCOVER request and to
automatically locate the RFID device according to location information
included in
the DHCPDISCOVER request.
Methods and devices are also provided for identifying end devices and
automatically configuring associated network settings. Preferred
implementations of
the invention do not require users to manually identify connection types
(e.g., RFID,
IPphone, manufacturing device, etc.) or to manually configure the network
device.
Accordingly, such implementations allow automatic switch configuration, even
for
devices that use inconsistent protocols and/or protocols that are not well
known.
Some methods of the invention employ DHCP options combined with traffic
snooping to identify devices and automatically apply appropriate switch port
configuration. Some such implementations of the invention trigger Cisco
Systems'
SmartPortsTM software to configure ports of network devices. However, the
present
invention is not limited to implementation via SmartPortsTM; any convenient
software
for the automated configuring of network device ports may be used in
accordance
with the present invention.
- 6 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
Some implementations of the invention provide a method for establishing
network device port settings. The method includes the steps of receiving a
DHCPDISCOVER request from a device and of determining, based on information in
the DHCPDISCOVER request, whether an appropriate macro is available to
configure a port of a network device on which the DHCPDISCOVER request was
first received.
The method may also include the step of applying the appropriate macro when
it is determined to be available. The method preferably includes the step of
determining whether the port has already been configured in a manner
appropriate for
the device.
The determining step may involve determining a device personality,
identifying the device and/or examining at least one DHCP option or other
component of the DHCPDISCOVER request. The "other component" could be, for
example, one or more parts of the DHCP message header. The determining step
may
or may not be performed by the network device on which the DHCPDISCOVER
request was first received. For example, the DHCPDISCOVER request may first be
received by a switch port and the determining step may be performed by one of
a
DHCP server, an edge services management server, an authentication server and
a
device dedicated to port configuration..
Some embodiments of the invention provide at least one apparatus for
establishing network device port settings. Such embodiments include a port for
receiving a DHCPDISCOVER request from a device and at least one logic device
configured for determining, based on information in the DHCPDISCOVER request,
whether an appropriate macro is available to configure the port.
A logic device may examine one or more DHCP options of the
DHCPDISCOVER request. The port and the logic device(s) may be included within
a single device or may be disposed in separate devices. For example, the port
and
the logic device(s) may be included within a single switch or a DHCP server.
Alternative embodiments of the invention provide a network device that
includes these elements: a plurality of ports; a storage device; and at least
one logic
device configured to receive a DHCPDISCOVER request from a device via a first
port and configure the first port with appropriate configuration parameters
for the
device.
- 7 -
T8470440CA\TOR_LAW\ 6924772\I
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
A logic device may be further configured to forward a copy of the
DHCPDISCOVER request to a second device. A logic device may configure the
first
port according to instructions received from the second device. The second
device
may be, for example, a DHCP server, an edge services management server, an
authentication server or a device dedicated to port configuration.
The methods of the present invention may be implemented, at least in part, by
hardware and/or software. For example, some embodiments of the invention
provide
computer programs embodied in machine-readable media. The computer programs
include instructions for controlling one or more devices to perform the
methods
described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a diagram illustrating an RFID tag.
Fig. 2 illustrates an exemplary RFID network according to the present
invention.
Fig. 3 is a block diagram of an exemplary RFID reader that may be configured
to perform some methods of the present invention.
Fig. 4 is a block diagram of an exemplary RFID printer that may be
configured to perform some methods of the present invention.
Fig. 5 is a block diagram of an exemplary RFID system that may be
configured to perform some methods of the present invention.
Fig. 6 is a flow chart that provides an overview of some methods of the
present invention.
Fig. 7 is a flow chart that provides an overview of alternative methods of the
present invention.
Fig. 8 is a flow chart that provides an overview of some implementations of
the present invention.
Fig. 9 illustrates an example of a network device that may be configured to
implement some methods of the present invention.
Fig. 10 is a network diagram illustrating a switch and attached RFID devices.
Fig. 11A illustrates an exemplary SmartPortsTM macro.
Fig. 11B illustrates an exemplary set of commands to be used for configuring
a port according to a SmartPortsTm macro.
- 8 -
T8470440CA\TOR_LAW\ 6924772\l
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
Fig. 12A is a flow chart that provides an overview of a method of the present
invention.
Fig. 12B is a network diagram that illustrates an implementation of the
method outlined in Fig. 12A.
Fig. 13 is a flow chart that provides an overview of an alternative method of
the present invention.
Fig. 14 is a block diagram that illustrates a network device for implementing
some aspects of the invention.
- 9 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
DETAILED DESCRIPTION OF THE INVENTION
In this application, numerous specific details are set forth in order to
provide a
thorough understanding of the present invention. It will be obvious, however,
to one
skilled in the art, that the present invention may be practiced without some
or all of
these specific details. In other instances, well known process steps have not
been
described in detail in order not to obscure the present invention.
Although the present invention involves methods and devices for identifying
and provisioning individual RFID devices in a network, many aspects of the
present
invention can be applied to identifying and provisioning other types of
devices in a
network. Similarly, although much of the discussion herein applies to
implementations using the DHCP protocol, the present invention is not protocol-
specific and may be used, for example, in implementations using UPnP, 802.1ab
or
similar discovery protocols. Likewise, while the implementations described
herein
refer to exemplary DHCP Options, other DHCP Options may advantageously be used
to implement the present invention.
RFID devices perform different functions and may interface to the upstream
systems differently depending on where they are located. The functions they
perform, as well as the unique settings to perform those functions, will be
referred to
herein as the device "personality." As used herein, "provisioning" a device
can
include, but is not limited to, providing network configuration, providing
personality
configuration, incorporating the device into a network database and enabling
the
device with software (e.g., business process software).
The methods and devices of the present invention have very broad utility, both
in the public and private sectors. Any enterprise needs to keep track of how
its
equipment is being deployed, whether that equipment is used for commercial
purposes, for military purposes, etc. RFID devices that are networked
according to
the present invention can provide necessary information for allowing
enterprises to
track equipment and products (or groups of products). The information that
will be
provided by RFID devices that are networked according to the present invention
will
be of great benefit for enterprise resource planning, including the planning
of
manufacturing, distribution, sales and marketing.
Using the devices and methods of the present invention, RFID tags and
associated RFID devices (such as RFID readers and printers) can form part of a
- 10 -
T8470440CAA OR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
network for tracking a product and its history. For example, instead of
waiting in a
checkout line to purchase selected products, a shopper who wishes to purchase
products bearing RFID tags can, for example, transport the products through a
door
that has an RFID reader nearby. The EPC information regarding the products can
be
provided to an RFID network by the reader and can be used to automatically
update a
store inventory, cause a financial account to be debited, update
manufacturers',
distributors' and retailers' product sales databases, etc.
Read/write RFID tags can capture information regarding the history of
products or groups of products, e.g., temperature and other environmental
changes,
stresses, accelerations and/or vibrations that have acted upon the product. It
will be
particularly useful to record such information for products that relatively
more subject
to spoilage or other damage, such as perishable foods and fragile items. By
using the
methods of the present invention, this information will be used to update
databases
maintained by various entities (e.g., manufacturers, wholesalers, retailers,
transportation companies and financial institutions). The information will be
used not
only to resolve disputes (for example, regarding responsibility for product
damage)
but also to increase customer satisfaction, to avoid health risks, etc.
As shown in Fig. 1, an RFID tag 100 includes microprocessor 105 and
antenna 110. In this example, RFID tag 100 is powered by a magnetic field 145
generated by an RFID reader 125. The tag's antenna 110 picks up the magnetic
signal 145. RFID tag 100 modulates the signal 145 according to information
coded in
the tag and transmits the modulated signal 155 to the RFID reader 125.
RFID tags use the Electronic Product Code ("EPC" or "ePC") format for
encoding information. An EPC code includes variable length bits of information
(common formats are 64, 96 and 128 bits), which allows for identification of
individual products as well as associated information. As shown in Fig. 1, EPC
120
includes header 130, EPC Manager field 140, Object class field 150 and serial
number field 160. EPC Manager field 140 contains manufacturer information.
Object class field 150 includes a product's stock-keeping unit ("SKU") number.
Serial number field 160 is a 40-bit field that can uniquely identify the
specific
instance of an individual product i.e., not just a make or model, but also
down to a
specific "serial number" of a make and model.
Fig. 10 illustrates a portion of a network 1000, in which network device 1005
(in this
example, a CatalystTM switch provided by Cisco Systems, Inc.) is connected to
a
- 11 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
plurality of devices, including RFID reader 1010. In this example, RFID reader
1010
is connected to port 1020 via a fast Ethernet connection. For each port of
network
device 1005, a variety of attributes may be configured, such as QoS, security,
port
speed, description, etc.
Some aspects of the invention use a combination of EPC code information and
modified versions of existing networking standards for identifying, locating
and
provisioning RFID devices, such as RFID readers and RFID printers, that are
located
in a network. An example of such a network is depicted in Fig. 2. Here, RFID
network 200 includes warehouse 201, factory 205, retail outlet 210, financial
institution 215 and headquarters 220. As will be appreciated by those of skill
in the
art, network 200 could include many other elements and/or multiple instances
of the
elements shown in Fig. 2. For example, network 200 could include a plurality
of
warehouses, factories, etc.
In this illustration, products 227 are being delivered to warehouse 201 by
truck 275. Products 227, which already include RFID tags, are delivered
through
door 225. In this example, RFID reader 252 is connected to port 262 of switch
260.
Here, switches 230 and 260 are connected to the rest of RFID network 200 via
gateway 250 and network 225. Network 225 could be any convenient network, but
in
this example network 225 is the Internet. RFID reader 252 reads each product
that
passes through door 225 and transmits the EPC code corresponding to each
product
on RFID network 200.
RFID tags may be used for different levels of a product distribution system.
For example, there may be an RFID tag for a pallet of cases, an RFID tag for
each
case in the pallet and an RFID tag for each product. Accordingly, after
products 227
enter warehouse 201, they are assembled into cases 246. RFID printer 256 makes
an
RFID tag for each of cases 246. In this example, RFID printer 256 is connected
to
port 266 of switch 260. RFID printer 256 could operate under the control of PC
247
in warehouse 201, one of PCs 267 in headquarters 220, or some other device.
RFID reader 224, which is connected to port 214, reads the EPC code of each
case 246 and product 227 on conveyor belt 244 and transmits this information
on
network 200. Similarly, RFID reader 226, which is connected to port 216, reads
the
EPC code of each case 246 and product 227 that exits door 204 and transmits
this
- 12 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
information on network 200. Cases 246 are loaded onto truck 285 for
distribution to
another part of the product chain, e.g., to retail outlet 210.
Each of the RFID devices in network 200 preferably has a "personality"
suitable for its intended use. For example, device 252 could cause reassuring
tone to
sound and/or a green light to flash if an authorized person or object enters
door 225.
However, device 252 might cause an alarm to sound and/or an alert to be sent
to an
administrator on network 200 if a product exits door 225 or an unauthorized
person
enters or exits door 225.
Fig. 3 illustrates an RFID reader that can be configured to perform methods of
the present invention. RFID reader 300 includes one or more RF radios 305 for
transmitting RF waves to, and receiving modulated RF waves from, RFID tags. RF
radios 305 provide raw RF data that is converted by an analog-to-digital
converter
(not shown) and conveyed to other elements of RFID reader 300. In some
embodiments, these data are stored, at least temporarily, by CPU 310 in memory
315
before being transmitted to other parts of RFID network 200 via network
interface
325. Network interface 325 may be any convenient type of interface, such as an
Ethernet interface.
Flash memory 320 is used to store a program (a "bootloader") for
booting/initializing RFID reader 300. The bootloader, which is usually stored
in a
separate, partitioned area of flash memory 320, also allows RFID reader 300 to
recover from a power loss, etc. In some embodiments of the invention, flash
memory
320 includes instructions for controlling CPU 310 to form "DHCPDISCOVER"
requests, as described below with reference to Fig. 6, to initiate a
provisioning/configuration cycle. In some implementations, flash memory 320 is
used to store personality information and other configuration information
obtained
from, e.g., a DHCP server during such a cycle.
However, in preferred implementations, such information is only stored in
volatile memory 415 after being received from, e.g. a DHCP server. There are
advantages to keeping RFID devices "dumb." For example, a network of dumb RFID
devices allows much of the processing load to be centralized (e.g., performed
by
server 270 of network 200), instead of being performed by the RFID devices.
Alternatively, the processing load can be decentralized, but only to trusted
devices
(such as PC 247 of network 200).
- 13 -
T8470440CA\TOR_LAW\ 6924772 \ I
CA 02565099 2014-05-13
CISCP377.WO
those described above with reference to Figs. 3 and 4. Interconnect 530 of
control
portion 501 is configured for communication with interconnect 535 of RF radio
portion 502. The communication may be via any convenient medium and format,
such as wireless, serial, point-to-point serial, etc. Although only one RF
radio portion
502 is depicted in Fig. 5, each control portion 501 may control a plurality of
RF radio
portions 502. RFID system 500 may be deployed on a single framework or chassis
(e.g., on a forklift) or in multiple chassis.
The DHCP protocol is used in some preferred implementations of the present
invention because it offers various convenient features. For example, the DHCP
protocol allows pools or "scopes" of TCP/IP addresses to be defined. A DHCP
server
can temporarily allocate or "lease" these TCP/IP addresses to host devices. An
IP
address that is not used for the duration of the lease is returned to the pool
of
unallocated IP addresses. In addition, the DHCP server will provide all
related
configuration settings, such as the default router, Domain Name Service
("DNS")
servers, subnet mask, etc., that are required for the proper functioning of
TCP/IP.
For implementations using the DHCP protocol, DHCP Options may be used
to pass provisioning information. The DHCP protocol is defined in RFC 2131 and
DHCP Options are set forth in, for example, RFCs 2132, 3004 and 3046.
In some preferred implementations, an EPC corresponding to an RFID device
is put inside a DHCP request sent from the RFID device to a DHCP server. The
EPC
uniquely identifies the RFID device. Some implementations employ Domain Name
Service ("DNS") and dynamic DNS ("DDNS") to allow yet easier identification of
RFID devices.
An overview of some such implementations of the present invention will now
be described with reference to Fig. 6. A device that sends out an initiation
for an IP
address to a DHCP server does so by way of a packet that includes a
"DHCPDISCOVER" request. This command includes the media access control
("MAC") address of the device. According to some preferred implementations,
the
RFID device (e.g., CPU 310 of RFID Reader 300) forms a "DHCPDISCOVER"
request packet that includes information in various DHCP Option fields (step
601).
The RFID device encodes DHCP "class identifier" Option 60 with a code
indicating
that the device is an RFID device. In other words, "RFID" will be a new type
of
"class," encoded in Option 60.
- 14 -
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
can temporarily allocate or "lease" these TCP/IP addresses to host devices. An
IP
address that is not used for the duration of the lease is returned to the pool
of
unallocated IP addresses. In addition, the DHCP server will provide all
related
configuration settings, such as the default router, Domain Name Service
("DNS")
servers, subnet mask, etc., that are required for the proper functioning of
TCP/IP.
For implementations using the DHCP protocol, DHCP Options may be used
to pass provisioning information. The DHCP protocol is defined in RFC 2131 and
DHCP Options are set forth in, for example, RFCs 2132, 3004 and 3046. RFCs
2131,
2132, 3004 and 3046 are hereby incorporated by reference for all purposes.
In some preferred implementations, an EPC corresponding to an RFID device
is put inside a DHCP request sent from the RFID device to a DHCP server. The
EPC
uniquely identifies the RFID device. Some implementations employ Domain Name
Service ("DNS") and dynamic DNS ("DDNS") to allow yet easier identification of
RFID devices.
An overview of some such implementations of the present invention will now
be described with reference to Fig. 6. A device that sends out an initiation
for an IP
address to a DHCP server does so by way of a packet that includes a
"DHCPDISCOVER" request. This command includes the media access control
("MAC") address of the device. According to some preferred implementations,
the
RFID device (e.g., CPU 310 of RFID Reader 300) forms a "DHCPDISCOVER"
request packet that includes information in various DHCP Option fields (step
601).
The RFID device encodes DHCP "class identifier" Option 60 with a code
indicating
that the device is an RFID device. In other words, "RFID" will be a new type
of
"class," encoded in Option 60.
In this example, the RFID device encodes its own EPC in the field reserved
for Option 61, The RFID device also encodes a company name, e.g., of the
company
that supplies, owns or is using the RFID device, in DHCP Option 43.
Option 77 may be used in various ways according to different
implementations of the invention. In some implementations, Option 77 will be
used
to indicate the type of RFID device, e.g., that the RFID device is an RFID
reader or
an RFID printer. In some implementations, Option 77 can also include
information
regarding the functionality or "personality" of the RFID device. For example,
Option
77 could indicate that the RFID device is an inbound RFID reader, an outbound
RFID
reader, an RFID reader or printer on an assembly line, a retail store, etc.
- 15 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
Referring once again to Fig. 2, if the request is from RFID device 252, that
device would encode information in Option 77 indicating that the device is an
RFID
reader. In some implementations, Option 77 also indicates that RFID device 252
has
a personality suitable for being positioned at an entrance door. Some
implementations include more detailed information about the current
personality of
device 252. For example, Option 77 may indicate that in addition to reading
EPC
codes and uploading them to the RFID network, device 252 will also cause a
green
light to flash if an authorized person or object enters door 225 and will
cause a red
light to flash, an alarm to sound and an alert to be sent to an administrator
on the
network if a product exits door 225. This information could be encoded, for
example,
according to a number that corresponds to one of a range of suitable
personalities for
an RFID reader at an entrance door.
It is desirable to determine and provide location information for RFID devices
in a network. Switches and wireless bridges with Ethernet or switch ports are
considered static and have assigned names and locations. According to some
implementations of the invention, location information is added, for example
to an
RFID device's DHCPDISCOVER request, by the network device to which the RFID
device is attached (step 610).
Some such implementations use DHCP Option 82 (RFC 3046) in a new way
to determine the switch port and switch to which an RFID device is connected.
For
example, a switch may insert the following two information elements into any
DHCP
request from an attached RFID device: Option 82, Sub-Option 1: Agent Circuit
ID
and Option 82, Sub-Option 2: Agent Remote ID. The Agent Circuit ID is the name
or
identifier of the switch. The Agent Remote ID is the name or identifier of the
switch
port.
For example, if the request is from RFID device 226 of Fig. 2, network device
230 adds location information to the request in step 610. Here, the location
information would be encoded in Option 82 and would include information
identifying network device 230 and port 216, to which RFID reader 226 is
attached.
In alternative embodiments wherein the RFID device is capable of
determining its own location (e.g., from GPS coordinates), the RFID device may
encode location information in the DHCPDISCOVER request or in other commands.
There can be multiple DHCP servers serving the same network. How the
servers respond can depend, for example, on whether each server is busy,
whether it
- 16 -
T8470440CA\TOR_LAW\ 6924772 \ I
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
has served out all its addresses, etc. As RFID pilot networks emerge and
develop,
they will be interleaved with existing networks, including networks that
employ the
DHCP protocol. DHCP servers that are provisioning RFID devices (e.g. server
270
of Fig. 2) will respond to "DHCPDISCOVER" commands identifying a class of the
device as "RFID," e.g., encoded in Option 60. Those of skill in the art will
appreciate
that other Options may be used for this purpose. Conversely, DHCP servers that
are
not provisioning RFID devices will not respond to "DHCPDISCOVER" commands
identifying a class of the device as "RFID." Further, if a non-RFID DHCP
server
does respond, the RFID device will be able to determine from the DHCP options
response that it has received an incomplete DHCP response and will discard it
and
will prefer responses from RFID DHCP servers. Accordingly, the methods of the
present invention allow for the integration of RFID networks within the
existing
framework of the DHCP protocol.
In step 615, the DHCP server determines whether there is information
regarding the requesting device within a database of information regarding
known
RFID devices, their intended functions, configurations, etc. For example, the
DHCP
server may inspect the EPC encoded in a request and determine whether there is
information for a device with a corresponding EPC in the database.
If so, in step 620, the server compares information in the DHCP request with
stored information regarding the RFID device. This information may be in a
database
(e.g., stored in one of storage devices 265) that is updated, for example, by
IT
personnel responsible for the RFID network. For example, MAC address
information
and EPC information can be combined to identify a particular device and its
location
in a network. Upper-level applications can be notified, for example, that a
particular
RFID device is available for use.
By inspecting the received data, the server can then determine the type,
identity, location and personality (if any) of the RFID device. By comparing
the
received data with information in the database, the server can then determine,
for
example, if that precise RFID device has moved and where it is now located. In
preferred implementations, the DHCP server may determine the current
personality of
the RFID device (e.g., by inspecting the Option 77 data) and may compare the
current
personality with a desired personality.
In step 625, the DHCP server provides the RFID device with configuration
information, etc., indicated in the database. For example, the DHCP server may
- 17 -
T8470440CAVIOR_LAW\ 6924772\!
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
indicate the RFID device's time server, SYSLOG server, the location of the
device's
configuration files, image files, etc. If the RFID device's current
personality does not
match the desired personality (or if the request does not indicate a current
personality), according to some implementations the DHCP server can provide
the
device with information (e.g., a computer program, configuration settings,
etc.) for
enabling the desired personality.
For example, suppose that the EPC code indicates that the device is RFID
reader 252 and Option 77 indicates that RFID device 252 has a personality
suitable
for being positioned at an entrance door. However, the location information in
the
request may indicate that the requesting device has been moved and is now
located at
an exit door. Alternatively, the database may indicate that the device is
positioned at
a door that has been used as an entrance door, but which now will be used as
an exit
door. This may be a periodic (e.g. hourly, daily, weekly, or monthly) change
at a
manufacturing facility or warehouse, or may be due to a reconfiguration of the
facility.
Therefore, the desired personality for RFID device 252 is now a personality
appropriate for an exit door. However, there may be a range of different "exit
door"
personalities that could be provided to device 252 depending, for example, on
the
capabilities of the device making the request, the expected uses of the exit
door, etc.
For example, a device with fewer capabilities (e.g., a smaller memory) may be
enabled for relatively simpler exit door functionality. For example, such a
device
may be enabled to, e.g., make a green light flash when particular type of
product is
exiting the door and to transmit a notification message to IT personnel and/or
cause
an alarm to sound if other items are exiting the door.
However, a device with greater capabilities may be enabled for relatively
more complex exit door functionality. For example, the device could be enabled
to
cause a green light to flash if a particular type of product is exiting at an
expected
time, if the number of products exiting the door is within a predetermined
range, etc.
This flexibility in reassigning device personality allows an RFID network to
cause the same device type to have multiple personalities based upon location,
time of
day, or any other suitable criteria. Moreover, this flexibility allows for
movement or
relocation of devices (whether or not this movement has been approved in
advance)
and then having devices automatically "repersonalized," as appropriate for the
new
- 18 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
location. In addition, it allows for specialized functionality on a per
device, per locale
basis.
However, in some circumstances there may be no information in the database
regarding the device. For example, the device may be a new RFID device that
has
just been activated in the RFID network for the first time (step 630). In this
example,
the device is placed in a "walled garden" for devices that are not trusted
devices.
Step 630 may involve assigning the device a non-routable IP address for a
predetermined length of time via a DHCPOFFER command. According to some
implementations, the DHCP server performs step 630 when there is information
in
the database regarding the device that is inconsistent with information in the
request.
Preferably, step 630 includes notifying an upper-layer application that the
device has made the request. In this way, IT personnel responsible for the
site within
which the RFID device is located will be notified that the RFID device exists
and has
made a request.
According to some implementations, step 630 involves setting the DHCP Ti
timer for a short time interval, for example, 60 seconds. In this example, the
RFID
device will continue to send DHCP requests to the server every 60 seconds and
the
server will send "ACKs" to the device until one of two events occurs: (1) the
server
has been updated (e.g., by IT personnel responsible for the site within which
the
RFID device is located); or (2) the connection between the server and the RFID
device goes down. (Step 635.)
If the server is updated within the predetermined time, this indicates that an
IT
person has determined that the RFID device making the request is a trusted
device.
Accordingly, the method proceeds to step 625. If not, the device remains
classified as
an untrusted device (step 630). Preferably, the device's status may still be
changed to
that of a trusted (and therefore provisioned) device, e.g., according to
subsequent
input from IT personnel.
After an initial provisioning configuration cycle (e.g., as described above),
RFID devices may need to be reprovisioned or have their personalities changed.
As
noted above, it is desirable for an RFID device to take on unique provisioning
and
personalities depending on the desired functionality of the RFID device at a
particular
time. The desired functionality may be determined according to the location
and
capabilities of the RFID device. Some devices may be provided with the same
personality for a relatively longer time, e.g., months or years. However, it
may be
- 19 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2014-05-13
CISCP377.WO
The request is sent in step 710. Preferably, a relay agent updates the request
with location information, as described above (step 715).
In step 720, the server compares the information in the request with stored
information (e.g., in a lookup table or a database) to determine whether an
update or a
complete reconfiguration of the RFID device is required. If not, the process
returns to
step 701. If so, the server provides the RFID device with the necessary update
and/or
reconfiguration information (step 725).
The RFID device triggers the update and/or reconfiguration determination in
the foregoing example. However, in other implementations, another device
(e.g., the
DHCP server) and/or a person initiates this determination. For example, the
DHCP
server could initiate a periodic process of comparing a desired RFID device
personality with the last known RFID device personality. Alternatively, an IT
worker
could send information (e.g., to the DHCP server, to the RFID device or to
another
device) indicating a desired change in personality.
According to some implementations of the invention, a DHCP server causes
an update or a complete reconfiguration using a DHCPFORCERENEW command as
defined by RFC 3203. The CPU of the RFID device registers the ForceRenew
command and starts a new provisioning cycle, for example as described above
with
reference to Fig. 6.
In order to secure the command, in this example a cached secret is hashed
within the command. For example, the secret can be included with the EPC code
of
the RFID device.
One method for creating an authentication key is as follows:
MD-5 (EPC, Challenge, Secret)
By adding in the variable of a random Challenge, no replay attacks of the hash
code could be used. Because the EPC is included, the authentication can be
further
validated to come from a specific device.
The foregoing methods allow for unique determination and provisioning of
RFID devices by time of day, not simply by device "type," "class" or
"location."
Moreover, the foregoing methods allow for ongoing verification/auditing of
what the
end device roles are. In addition, these methods allow operation managers to
have
enterprise resource planning systems control end devices to allow for
increased
functionality.
-20-
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
personality with the last known RFID device personality. Alternatively, an IT
worker
could send information (e.g., to the DHCP server, to the RFID device or to
another
device) indicating a desired change in personality.
According to some implementations of the invention, a DHCP server causes
an update or a complete reconfiguration using a DHCPFORCERENEW command as
defined by RFC 3203, which is hereby incorporated by reference in its
entirety. The
CPU of the RFID device registers the ForceRenew command and starts a new
provisioning cycle, for example as described above with reference to Fig. 6.
In order to secure the command, in this example a cached secret is hashed
within the command. For example, the secret can be included with the EPC code
of
the RFID device.
One method for creating an authentication key is as follows:
MD-5 (EPC, Challenge, Secret)
By adding in the variable of a random Challenge, no replay attacks of the hash
code could be used. Because the EPC is included, the authentication can be
further
validated to come from a specific device.
The foregoing methods allow for unique determination and provisioning of
RFID devices by time of day, not simply by device "type," "class" or
"location."
Moreover, the foregoing methods allow for ongoing verification/auditing of
what the
end device roles are. In addition, these methods allow operation managers to
have
enterprise resource planning systems control end devices to allow for
increased
functionality.
Fig. 8 is a flow chart that illustrates an exemplary business application of
the
present invention. Those of skill in the art will appreciate that the example
described
below with reference to Fig. 8 is but one of many applications of the
invention.
In step 805, an RFID device has already been provisioned according to one of
the previously-described methods. The condition of the RFID device is
comparable
to that of a device at step 640 in method 600, shown in Fig. 6 and described
above. In
this example, the RFID device is an RFID reader that is positioned near an
exit door
of a retail store. Therefore, in the previous steps, the device has been
provisioned
with a personality that is appropriate for its role.
In step 810, a shopper exits the door with a number of selected products. In
step 815, the RFID reader reads the RFID tags of each product and extracts the
EPC
codes and related product information (e.g., the price of each product).
-21 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
The RFID reader also reads an RFID tag that identifies the shopper and the
shopper's preferred account(s) that should be debited in order to purchase the
products. For example, the shopper may have an RFID tag embedded in a card, a
key
chain, or any other convenient place in which this information is encoded. The
accounts may be various types of accounts maintained by one or more financial
institutions. For example, the accounts may be one or more of a checking
account,
savings account, a line of credit, a credit card account, etc. Biometric data
(e.g.,
voice, fingerprint, retinal scan, etc.) from the shopper may also be obtained
and
compared with stored biometric data in order to verify the shopper's identity.
In step 820, the RFID reader transmits the product information, including the
EPC codes, on the RFID network. In this example, the information is first sent
to a
financial institution indicated by the shopper's RFID tag.
In step 825, the financial institution that maintains the shopper's selected
account determines whether there are sufficient funds (or whether there is
sufficient
credit) for the shopper to purchase the selected products. If so, the
shopper's account
is debited and the transaction is consummated (step 830).
In this example, the shopper has the option of designating one or more
alternative accounts. Accordingly, if the first account has insufficient funds
or credit,
it is determined (e.g., by a server on the RFID network) whether there the
shopper has
indicated any alternative accounts for making purchases (step 835). If so, the
next
account is evaluated in step 825. If it is determined in step 835 that there
are no
additional accounts designated by the shopper, in this example some form of
human
intervention takes place. For example, a cashier of the retail store could
assist the
shopper in making the purchases in a conventional manner.
If some or all of the products are purchased, information regarding the
purchased products (including the EPC codes) are transmitted on the RFID
network.
For example, this information is preferably forwarded to one or more devices
on the
RFID network that are configured to update one or more databases maintained by
the
retail store or the manufacturers/producers, distributors, wholesalers, etc.,
of the
purchased products (step 840). In some implementations, information regarding
the
shopper is also transmitted on the RFID network (e.g., if the shopper has
authorized
such information to be released). This product information (and optionally
shopper
information) may be used for a variety of purposes, e.g., in the formation of
various
- 22 -
T8470440CA\ TOR_LAW \ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
types of business plans (e.g., inventory re-stocking, marketing, sales,
distribution and
manufacturing/production plans).
Fig. 9 illustrates an example of a network device that may be configured to
implement some methods of the present invention. Network device 960 includes a
master central processing unit (CPU) 962, interfaces 968, and a bus 967 (e.g.,
a PCI
bus). Generally, interfaces 968 include ports 969 appropriate for
communication with
the appropriate media. In some embodiments, one or more of interfaces 968
includes
at least one independent processor 974 and, in some instances, volatile RAM.
Independent processors 974 may be, for example ASICs or any other appropriate
processors. According to some such embodiments, these independent processors
974
perform at least some of the functions of the logic described herein. In some
embodiments, one or more of interfaces 968 control such communications-
intensive
tasks as media control and management. By providing separate processors for
the
communications-intensive tasks, interfaces 968 allow the master microprocessor
962
efficiently to perform other functions such as routing computations, network
diagnostics, security functions, etc.
The interfaces 968 are typically provided as interface cards (sometimes
referred to as "line cards"). Generally, interfaces 968 control the sending
and
receiving of data packets over the network and sometimes support other
peripherals
used with the network device 960. Among the interfaces that may be provided
are
Fibre Channel ("FC") interfaces, Ethernet interfaces, frame relay interfaces,
cable
interfaces, DSL interfaces, token ring interfaces, and the like. In addition,
various
very high-speed interfaces may be provided, such as fast Ethernet interfaces,
Gigabit
Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI
interfaces, ASI interfaces, DHEI interfaces and the like.
When acting under the control of appropriate software or firmware, in some
implementations of the invention CPU 962 may be responsible for implementing
specific functions associated with the functions of a desired network device.
According to some embodiments, CPU 962 accomplishes all these functions under
the control of software including an operating system (e.g. Linux, VxWorks,
etc.),
and any appropriate applications software.
CPU 962 may include one or more processors 963 such as a processor from
the Motorola family of microprocessors or the MIPS family of microprocessors.
In
an alternative embodiment, processor 963 is specially designed hardware for
- 23 -
T8470440CA\TOR_LAW\ 6924772\!
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
controlling the operations of network device 960. In a specific embodiment, a
memory 961 (such as non-volatile RAM and/or ROM) also forms part of CPU 962.
However, there are many different ways in which memory could be coupled to the
system. Memory block 961 may be used for a variety of purposes such as, for
example, caching and/or storing data, programming instructions, etc.
Regardless of network device's configuration, it may employ one or more
memories or memory modules (such as, for example, memory block 965) configured
to store data, program instructions for the general-purpose network operations
and/or
other information relating to the functionality of the techniques described
herein. The
program instructions may control the operation of an operating system and/or
one or
more applications, for example.
Because such information and program instructions may be employed to
implement the systems/methods described herein, the present invention relates
to
machine-readable media that include program instructions, state information,
etc. for
performing various operations described herein. Examples of machine-readable
media include, but are not limited to, magnetic media such as hard disks,
floppy
disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical
media; and hardware devices that are specially configured to store and perform
program instructions, such as read-only memory devices (ROM) and random access
memory (RAM). The invention may also be embodied in a carrier wave traveling
over an appropriate medium such as airwaves, optical lines, electric lines,
etc.
Examples of program instructions include both machine code, such as produced
by a
compiler, and files containing higher level code that may be executed by the
computer using an interpreter.
Although the system shown in Fig. 9 illustrates one specific network device of
the present invention, it is by no means the only network device architecture
on which
the present invention can be implemented. For example, an architecture having
a
single processor that handles communications as well as routing computations,
etc. is
often used. Further, other types of interfaces and media could also be used
with the
network device. The communication path between interfaces/line cards may be
bus
based (as shown in Fig. 9) or switch fabric based (such as a cross-bar).
Some exemplary implementations of the invention involve using the
SmartPortsTM "macro" functionality for configuring ports of network devices.
However, other such tools could be used. In other implementations of the
invention,
- 24 -
T8470440CA \ TOR_LAW \ 6924772 \ 1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
a command line interface ("CLI") or another programmatic interface such as
Simple
Network Management Protocol ("SNMP") or Netconf is used for this purpose.
Prior implementations of SmartPortsTM macros required users to manually
identify connection types (e.g., RFID, manufacturing, IPphone) and then to
configure
a network device according to the identified connection type. As used herein,
the
term "macro" will sometimes be used to mean both the commands used to
configure,
e.g., a port of a network device and a configuration resulting from the
application of
such a macro. The network device could be configured, for example, using a
command line interface or a network management tool such as CMS on a per-port
basis.
An exemplary Cisco SmartPortsTM macro for configuring a port for an RFID
device will now be described with reference to Fig. 11A. Line 1101 is used to
establish the macro's name, which in this case is RFID Macro1. It is helpful
to use a
name that is easy to recognize as one type of macro for RFID devices, to allow
for the
possibility of having macros for multiple device types and multiple macros for
RFID
devices.
Line 1103 will cause an RFID VLAN to be assigned and line 1105 puts a
switch port in "access" mode. Line 1107 assigns a generic description to the
interface
indicating its use, which is a connection to an RFID device in this example.
Lines
1109 enable port security and limit the port to a single media access control
("MAC")
address.
According to line 1111, when the maximum number of MAC addresses is
exceeded, traffic from additional source MAC addresses are dropped. In
addition, an
SNMP trap and a syslog message are generated. Lines 1113 cause the secure MAC
address to age out after 10 minutes of inactivity.
Lines 1115 configure the port as an edge device port that does not need to
behave according to a spanning tree protocol. Accordingly, bridge port data
unit
("BPDU") packets are not be allowed to enter the network from this port.
"Spanning-
tree portfast" allows the port to move into the forwarding state quickly.
Lines 1117 set broadcast and multicast storm control limits to 20% of the
interface bandwidth. As with other settings in this example, this limit should
be
based upon the anticipated requirements of the device to be in communication
with
the port. Line 1119 applies a rate limiting of DHCP packets coming from the
device
to 100 packets per second.
- 25 -
T8470440CA\TOR_LAW\ 6924772 \ 1
CA 02565099 2014-05-13
CISCP377.WO
Some exemplary implementations of the invention will now be described with
reference to Figs. 12A and 12B. Fig. 12A is a flow chart that outlines method
1200
according to the invention. Fig. 12B is a simplified network diagram of
network
1250 that provides one example of how method 1200 may be implemented.
Those of skill in the art will appreciate that some steps of the methods
discussed herein, including method 1200, need not be performed (and in some
implementations are not performed) in the order shown. Moreover, some
implementations of the methods discussed herein may include more or fewer
steps
than those shown, e.g., in Fig. 12A.
Similarly, those of skill in the art will appreciate that the elements of Fig.
12B
are both simplified and merely illustrative. Fig. 12B illustrates switches
1265, 1280
and 1285, all of which have attached devices. In this example, switch 1265 is
a Cisco
Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750
Series switches. However, one of skill in the art will appreciate that other
types of
network devices could be used to implement the invention. Moreover, switches
1265,
1280 and 1285 could be in the same location (e.g., in the same warehouse or
factory)
or could be in different locations. Switches 1265, 1280 and 1285 can
communicate
with DHCP server 1270, host device 1290 and storage devices 1295 via network
1275. Accordingly, network 1275 may include portions of one or more private
networks and part of the Internet.
The devices attached to switches 1265, 1280 and 1285 are not necessarily all
of the same type. In this example, device 1255 is an RFID reader and device
1257 is
an IP telephone. As discussed elsewhere herein, even devices that are of the
same
general type may have different capabilities and/or different desired
functions.
A device that sends out an initiation for an IP address to a DHCP server does
so by way of a packet that includes a "DHCPDISCOVER" request. This command
includes, inter alia, the media access control ("MAC") address of the device.
Accordingly, in step 1201 of method 1200, device 1255 of Fig. 12B initializes
and then sends DHCPDISCOVER request 1256 to port 1260 of switch 1265. Switch
1265 is configured not only to forward DHCPDISCOVER request 1256 to DHCP
server 1270 via network 1275, but also to analyze the contents of DHCPDISCOVER
request 1256. The steps performed by switch 1265 according to method 1200 may
be
- 26 -
CA 02565099 2014-05-13
CISCP377.WO
controlled by one or more logic devices 1268, which is an ASIC in this
example. However, logic device(s) 1268 could be any convenient logic
device(s).
In step 1215, switch 1265 attempts to identify device 1255 according to
information in DHCPDISCOVER request 1256. In this example, switch 1265 applies
"snooping" techniques to analyze the contents of Options in DHCPDISCOVER
request 1256. Switch 1265 may, for example, examine the contents of DHCP
Option
60 to determine a device type or vendor identifier. Switch 1265 may examine
the
"Enterprise number" field of DHCP Option 125 to determine the EPCGlobal
enterprise number of the device.
Alternatively, or additionally, switch 1265 may examine other DHCP options.
For example, switch 1265 may examine DHCP Option 150 to identify device 1255;
this Option is used, for example, by IPPhones provided by Cisco Systems, Inc.
R.
Johnson's draft "TFTP Server Address DHCP Option" Switch 1265 may examine a
"PXE boot" option to determine an appropriate configuration for port 1260. M.
Johnston's draft "DHCP Preboot eXecution Environment (PXE) Options" (Dynamic
Host Configuration Working Group Jan. 21, 2005) describes relevant
information.
Switch 1265 may examine Option 43 to obtain vendor-specific information
regarding
device 1255. Switch 1265 may examine Option 61 to determine an EPC identifier
of
device 1255.
In some implementations, switch 1265 also determines an appropriate
personality for device 1255 in step 1215. In some such implementations, switch
1265
examines the DHCP Option 77 to determine a device personality. In other
implementations, switch 1265 can determine an appropriate personality for
device
1255 indirectly, e.g., by cross-referencing a look-up table or a similar data
structure
based on other information in DHCPDISCOVER request 1256. The look-up table
could be stored locally (e.g., in memory 1267), on an attached device or on
another
device that switch 1265 can access via network 1275, part of which is the
Internet in
this example.
If switch 1265 cannot identify device 1255, the process ends in this example
(step 1240 of Fig. 12A). Alternatively (or additionally), a network
administrator
could be alerted, e.g., by causing switch 1265 to send a message to host
device 1290.
-27 -
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
Feb. 6, 2005) describes relevant information and is hereby incorporated by
reference.
Switch 1265 may examine a "PXE boot" option to determine an appropriate
configuration for port 1260. M. Johnston's draft "DHCP Preboot eXecution
Environment (PXE) Options" (Dynamic Host Configuration Working Group Jan. 21,
2005) describes relevant information and is hereby incorporated by reference.
Switch
1265 may examine Option 43 to obtain vendor-specific information regarding
device
1255. Switch 1265 may examine Option 61 to determine an EPC identifier of
device
1255.
In some implementations, switch 1265 also determines an appropriate
personality for device 1255 in step 1215. In some such implementations, switch
1265
examines the DHCP Option 77 to determine a device personality. In other
implementations, switch 1265 can determine an appropriate personality for
device
1255 indirectly, e.g., by cross-referencing a look-up table or a similar data
structure
based on other information in DHCPDISCOVER request 1256. The look-up table
could be stored locally (e.g., in memory 1267), on an attached device or on
another
device that switch 1265 can access via network 1275, part of which is the
Internet in
this example.
If switch 1265 cannot identify device 1255, the process ends in this example
(step 1240 of Fig. 12A). Alternatively (or additionally), a network
administrator
could be alerted, e.g., by causing switch 1265 to send a message to host
device 1290.
However, if switch 1265 can identify the device, the method proceeds to step
1220, wherein switch 1265 determines port 1260 is already configured. (In the
flow
chart of Fig. 12A it is presumed that a port configuration (if any) has
resulted from
the application of a macro, though this need not be the case.)
If port 1260 has not yet been configured, it is determined whether there is a
configuration macro available (e.g., locally available and stored in memory
1267) that
is appropriate for device 1255. (Step 1230.) Table 1266 is one exemplary data
structure that may be used for such a purpose. Table 1266 includes macro field
1272,
for defining a plurality of configuration macros, each of which corresponds to
a
device of device ID field 1274. Accordingly, a device ID determined as
described
above with reference to step 1215 (or otherwise) can be used to determine
whether
there is a corresponding macro.
If port 1260 is already configured, it is determined in step 1225 whether the
configuration is suitable for the device identified in step 1215. If so, the
process ends.
- 28 -
T8470440CA\TOR_LAW\ 6924772\1
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
If the port does not have a desired configuration, it is determined in step
1230
whether there is an appropriate macro available for the device. If there is an
appropriate macro available for the device, the macro is applied (step 1235)
and then
the process ends (step 1240). If not, the process ends without a macro being
applied.
Preferably, a network administrator is notified, e.g., by sending a message
from
switch 1265 to host device 1290.
In the preceding example, switch 1265 had the intelligence for determining
how to automatically configure a port on which a DHCPDISCOVER request is
received. The switch itself analyzed the DHCPDISCOVER request and configured
the port with an appropriate combination of attributes. These combinations of
attributes, along with the necessary software for applying them, were stored
in the
switch itself.
However, in other implementations of the invention, both the intelligence for
determining how appropriately to configure the port and the instructions for
so
configuring the port may be owned by another device. For example, the
intelligence
may reside in DHCP server 1270, an edge services management server, an
authentication server and a device dedicated to port configuration. Some such
implementations are illustrated by the flow chart of Fig. 13.
In steps 1301 and 1305, a device initializes and sends a DHCPDISCOVER
request to a switch port. In this example, switch 1265 forwards the
DHCPDISCOVER request with an indication of the port on which the
DHCPDISCOVER request was received. (Step 1310.) The port ID could be
provided, for example, in DHCP Option 82. Preferably, the switch also forwards
information regarding the current port configuration to DHCP server 1270.
According to some implementations, DHCP server 1270 attempts to identify
the device. (Step 1312.) If DHCP server 1270 can identify the device, DHCP
server
1270 performs steps 1320, 1325 and 1330, which are analogous to steps 1220
through
1230 of method 1200.
DHCP server 1270 then instructs switch 1265 to configure the port in an
appropriate manner, e.g., by applying a macro. (Step 1335.) Macros (or the
like) for
this purpose could be stored in switch 1265, could be sent from DHCP server
1270 to
switch 1265, or could be obtained by switch 1265 from another device. For
example,
DHCP server 1270 could send switch 1265 a pointer to a memory space wherein
such
instructions are stored (e.g., in one of storage devices 1295).
- 29 -
T8470440CA\TOR LAW\ 6924772\1
CA 02565099 2014-05-13
CISCP377.WO
However, as illustrated in Fig. 14, some embodiments of the invention
combine many of the components necessary to implement the invention within a
single chassis. Here, chassis 1400 is a router that includes switch module
1405, with
ports 1410 that can be configured for appropriately communicating with devices
1415. In this example, router 1400 also includes DHCP server 1420, which may
be
implemented in software and/or hardware (e.g., as a line card or "blade"). In
alternative implementations, DHCP server 1420 could be implemented in a
separate
device that is in communication with router 1400.
Instead of being implemented in a router having a switch module, alternative
embodiments of the invention provide a chassis 1400 that is a switch that runs
Layer
3, running 10S. As above, chassis 1400 could also include DHCP server 1420,
implemented in software and/or hardware, or DHCP server 1420 could be
implemented in a separate device that is in communication with chassis 1400.
It will be appreciated by those of skill in the art that other types of
devices,
including but not limited to point-of-sale devices (e.g., "cash registers")
VoIP
telephones and devices used in manufacturing, may be advantageously configured
according to the methods of the present invention. For example, one or more
defined
fields could indicate the type of device, device personality, etc.
In one such example, DHCP Option 60 could indicate that the device is a cash
register and DHCP Option 77 could indicate the "personality" of the cash
register,
e.g., that it is a cash register used by a particular type of restaurant.
There could be
predefined macros for configuring a switch port appropriately for each type of
device,
e.g., for a cash register.
Other Embodiments
Although illustrative embodiments and applications of this invention are
shown and described herein, many variations and modifications are possible and
these
variations would become clear to those of ordinary skill in the art after
perusal of this
application.
-30-
CA 02565099 2008-08-01
Application No. 2,565,099
Replacement Pages
It will be appreciated by those of skill in the art that other types of
devices,
including but not limited to point-of-sale devices (e.g., "cash registers")
VoIP
telephones and devices used in manufacturing, may be advantageously configured
according to the methods of the present invention. For example, one or more
defined
fields could indicate the type of device, device personality, etc.
In one such example, DHCP Option 60 could indicate that the device is a cash
register and DHCP Option 77 could indicate the "personality" of the cash
register,
e.g., that it is a cash register used by a particular type of restaurant.
There could be
predefined macros for configuring a switch port appropriately for each type of
device,
e.g., for a cash register.
Other Embodiments
Although illustrative embodiments and applications of this invention are
shown and described herein, many variations and modifications are possible
which
remain within the concept, scope, and spirit of the invention, and these
variations
would become clear to those of ordinary skill in the art after perusal of this
application.
Accordingly, the present embodiments are to be considered as illustrative and
not restrictive, and the invention is not to be limited to the details given
herein, but
may be modified within the scope and equivalents of the appended claims.
- 31 -
T8470440CA\TOR_LAW\ 6924772 \ 1
