Transcript - IEEE Mentor

May 2005
doc.: IEEE 802.11-yy/xxxxr0
Firmware Updates
Date: 2005-May-17
Authors:
Name
Company
Address
Phone
email
John Klein
Symbol
6480 Via Del Oro,
San Jose, CA
408-528-2625
[email protected]
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in
this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE
Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement
"IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is
essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being
developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
Submission
Slide 1
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Abstract
Ideas for the Firmware upgrade requirements in
TGv.
Submission
Slide 2
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Contents
•
•
•
•
•
Purpose / Motivation
General Requirements Overview
Client STA scenarios
Infrastructure scenarios
Possible Implementation
Submission
Slide 3
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Purpose / Motivation
•
•
•
•
•
•
As 802.11 continues to mature, new services and features
continue to be deployed in the MAC.
Frequent upgrades require that devices be upgraded with new
firmware from the OEM vendor to enable new services or fix
bugs.
Ensuring the latest FW deployments in the enterprise WLAN
devices helps the IT Administrator keep tight control of the
network.
Few vendors are provide firmware updates over the air today
and automatically upgrade devices easily and securely.
Proliferation of devices from many OEM vendors makes
manually upgrading firmware to 802.11 devices difficult and
time consuming. The logistics quickly become unmanageable
for large enterprise networks.
Automating firmware upgrades over a secure wireless
interface eliminates the manual hassle factor and saves time
and money for the enterprise IT department.
Submission
Slide 4
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Client Scenario
•
•
•
•
•
•
IT Department has 10K clients on campus representing 12 different
802.11 hardware vendors and 36 different platforms.
They have new firmware for 6 of their HW platforms representing
2300 client devices they need to upgrade.
They want to distribute the new FW to the client devices with a
minimum of disruption to the overall network and to the users that
are affected.
The IT department publishes the FW images on an internal server and
issues policies for the wireless network that informs client devices
that the FW is available and allows the client devices to download the
FW at non-peak periods and locations around campus for the first 3
days. After the first 3 days or after 75% of all devices have been
updated, the FW can be downloaded at anytime and from any
location.
Per the policy, devices are directed to upgrade the firmware in the
actual device after the next system boot to avoid service disruption.
Devices that refuse to accept the FW directive are logged for
notification and manual upgrade.
Submission
Slide 5
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Infrastructure Scenario
•
•
•
•
•
•
IT Department has 2000 APs spread around campus representing 3
different HW vendors. Some are stand alone (FAT) APs from one
vendor, and some systems are connected to Wireless Switching (WS)
Infrastructures from two different vendors.
All APs or WSs are (as well as the clients) managed using a TGv
compatible NMS system over the campus wired infrastructure.
They have new FW to upgrade one of the WS systems as well as the
APs connected to those WSs. In addition, they have FW for the Stand
Alone APs.
The IT department publishes the FW images on an internal server and
issues policies for the wireless network that informs AP and WS
devices that the FW is available and allows the infrastructure devices
to download the FW immediately.
Per the policy, devices are directed to upgrade the firmware in the
actual devices at a pre-determined late-night schedule to minimize
service disruption.
Devices that refuse to accept the FW directive are logged for manual
inspection.
Submission
Slide 6
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
General Requirements
Overview
• Must operate over the air or over the wire
• Must be secure
– Any TGv frames used must be secure to ensure the management
entity sending the TGv frame is authentic.
• Must be deniable by the recipient
– Since devices visit many different networks, the recipient must be
able to refuse FW from say… Starbucks while accepting FW from
the employer’s IT department.
• Must be reliable. Can’t render device unusable.
– Must preserve current network settings (profiles) such that the
device can return to normal operation the network once the FW
has been upgraded.
• Must be compatible with CAPWAP with regard to WS
and APs connected to WS infrastructures.
Submission
Slide 7
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
One Possible Suggestion
• TGv Firmware Upgrade Management Message
– An L2 message from a TGv management station that alerts upper
layer software that a firmware upgrade for the device is available.
– Provides information and policies so the 802.11 device or upper
layer application can locate and download the firmware image for
the device.
– Might include server IP/Name, protocol(s) to use, required security
credentials, for higher level app to obtain and download the
firmware.
– Could be a location or time based service. (I.e. only upgrade
devices that are associated to the APs in the control room, only
after 6PM)
– Does not specify the how the firmware image is programmed into
the 802.11 OEM device itself. Beyond scope of TGv.
Submission
Slide 8
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Another Possible Suggestion
• TGv Firmware Upgrade image download
– An L2 protocol built into the 802.11 MAC for downloading
the actual firmware image to the targeted device.
– Low level packet TLV w/ packet ids and ack.
– Does not require that the target device have any upper layer
network services over 802.11 (i.e. UDP/IP services)
– Does not require an “Agent” utility on any device.
– Does not specify the how the firmware image is
programmed into the 802.11 OEM device itself. Beyond
scope of TGv.
Submission
Slide 9
John Klein, Symbol Technologies
May 2005
doc.: IEEE 802.11-yy/xxxxr0
Questions?
Submission
Slide 10
John Klein, Symbol Technologies