Device to Database Protocol for White Space
draft-das-paws-protocol-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | John P. Malyar , Dan Harasty , Subir Das | ||
| Last updated | 2011-11-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-paws-protocol-00
Applications Area Working Group John P Malyar
Internet-Draft Dan Harasty
Intended status:Standards Track Subir Das
Expires: May 14, 2012 Telcordia Technologies Inc
November 14, 2011
Device to Database Protocol for White Space
<draft-das-paws-protocol-00.txt>
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 12, 2012.
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This version of the document describes a protocol design framework for
Whitespace Devices to access Whitespace Database.
Das et al. Expires May 14, 2012 [Page 1]
Internet-Draft WS Protocol November 2011
Table of Contents
1. Convention used in this document . . . . . . . . . . . . . . . . 2
2. Terminology and abbreviations used in this document . . . . . . . 2
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol layering . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Features/Functionalities . . . . . . . . . . . . . . . . 6
5.1. Device Bootstrapping . . . . . . . . . . . . . . . . . . . . . 6
5.2. Device Registration . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Querying the Database . . . . . . . . . . . . . . . . . . . . . 10
5.4. Device Validation . . . . . . . . . . . . . . . . . . . . . . . 13
6. Encoding Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Consideration . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . . . 16
10. Authors` Address . . . . . . . . . . . . . . . . . . . . . . . 16
1. Convention used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
White Space (WS) and TV White Space (TVWS) are often used
interchangeably in this document.
2. Terminology and abbreviations used in this document
Following definitions are copied from [[I-D.ietf-paws-problem-stmt-usecases-rqmts]
TV White Space
TV white space refers specifically to radio spectrum which has been
allocated for TV broadcast, but is not occupied by a TV broadcast, or
other licensed user (such as a wireless microphone), at a specific
location and time.
White Space
Radio spectrum which has been allocated for some primary use, but is not
fully occupied by that primary use at a specific location and time.
White Space Device
A device which is a secondary user of some part of white space
spectrum. A white space device can be an access point, base station,
a portable device or similar. In this context, a white space device is
required to query a database with its location to obtain information
about available spectrum
Das et al. Expires May 14, 2012 [Page 2]
Internet-Draft WS Protocol November 2011
Database
In the context of white space and cognitive radio technologies, the
database is an entity which contains current information about available
spectrum at any given location and other types of information.
Master Device
A device which queries the WS Database to find out the available
operating channels.
Following definitions are copied from [FCC].
TV Bands Database (TVBD)
A database system that maintains records of all authorized services in
the TV frequency bands, is capable of determining the available channels
as a specific geographic location.
Fixed Device
A TVBD that transmits and/or receives radio communication signals at a
specified fixed location.
Mode I personal/portable device
A personal/portable TVBD that does not use an internal geolocation
capability and access to a TV bands database to obtain a list of
available channels.
Mode II personal/portable device
A personal/portable TVBD that uses an internal geo-location capability
and access to a TV bands database, either through a direct connection to
the Internet or through an indirect connection to the Internet by way of
fixed TVBD or another Mode II TVBD, to obtain a list of available
channels.
3. Introduction
Services offered via the TV Whitespaces initiative will require a
variety of devices and services each acting in accord with rules
provided by the regulatory bodies and industries. In this document, we
focus on one aspect of that overall system: the interface between a
`Device` and `WS Database`. The `Device` type definition may differ from
one regulatory authority to another. For example, by United States (US)
FCC rules, `Device` is referred to a `Fixed` and `Personal/Portable
device` (e.g. `Mode II personal/portable device` [FCC]).
The Fixed and personal/portable TVWS devices may additionally support
other Whitespace devices (e.g. Mode I personal/portable device per US
FCC rules [FCC]) to establish wireless broadband services. Several use
cases and requirements for use of White Space spectrum are described in
draft document [I-D.ietf-paws-problem-stmt-usecases-rqmts].
Das et al. Expires May 14, 2012 [Page 3]
Internet-Draft WS Protocol November 2011
Whitespace protocol must satisfy the requirements that are specified by
the regulatory authorities. As an example, here we list some US specific
requirements as specified by Federal Communications Commission [FCC]:
- The TVWS devices are required to periodically access the TV Whitespace
Database to obtain the list of available TV frequencies (channels) that
could be utilized at their location.
- Along with the list of frequencies/channels, the database should also
return maximum permissible power levels that could be used by the TVWS
devices.
- Fixed and Mode II devices are required to access TVWS database every
24 hours to get a list of available TV bands.
- The Mode II device must additionally do the same upon power-up, and
whenever they change their position by 50 meters or more.
- When a Fixed or Mode II device will serve as an access point for Mode I
devices, the serving Fixed or Mode II must check with the TVWS database
to ensure that the specified Mode I devices are valid devices at the
given location.
On the other hand, there may be different rules and requirements
Specified by other regulatory bodies (e.g., Ofcom) and countries. The
protocol design should be flexible enough to not only address these
requirements but also future requirements.
4. Protocol Layering
Figure 1 provides a high level overview of the protocol layers. The
Whitespace application protocol should use existing Internet protocols
to provide security and reliable transport. For example, the protocol
proposed here could be supported over HTTPS, TCP, and IP.
+-+-+-+-+-+-+-+-+-+-+-+-+
| WS Appl. Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+
| HTTPS |
+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliable Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+
| IP |
+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example Protocol Layers
The details of adapting the White space application protocol to this or
other supporting protocol stacks is not addressed at this time.
5. Protocol Features/Functionalities
WS protocol must support several regulatory requirements and include
features that are essential between the `Device` and the `WS database`.
Das et al. Expires May 14, 2012 [Page 4]
Internet-Draft WS Protocol November 2011
`Device` refers to an entity that queries the WS Database to find out
the available operating channels. This is same as `Master Device` as
defined in [I-D.ietf-paws-problem-stmt-usecases-rqmts]. In this
document, we list some of the protocol functionalities that we believe
are required. These features are by no means required to be performed
in a sequential manner. It is important to note that there may be additional
features that need to be supported by the interface.
5.1. Device Bootstrapping
Device bootstrapping is the process whereby device establishes an
Initial connection to the database. For example, each time the device
powers up or opens up a communication with the database; it requires
exchanging some messages. These messages for example, will help the
device to obtain the security parameters so that the subsequent messages
can be authenticated and integrity protected. We propose to perform the
authentication at the application layer, so as to allow a greater range
of deployment scenarios. However, one can argue that the device
authentication and message integrity can be provided by lower protocol
layers.
INIT-REQ and INT-RESP are proposed for bootstrapping the device with
the database. Figure 2 depicts the message flow and example message
parameters are then discussed.
Device WS Database
| |
| INT-REQ |
|---------------------->|
| INT-RESP |
|<----------------------|
| |
| |
Figure 2: Device Bootstrapping Message Flow
INIT-REQ:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Identity (e.g., Regulatory ID, Serial Number..) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Das et al. Expires May 14, 2012 [Page 5]
Internet-Draft WS Protocol November 2011
Authority - Indicates the regulatory rules that need to be applied
to the device
Device Type - Type of devices , for example, in US FCC rules this
is called Fixed or Mode II device
Device Identity - Information that identifies the class of
device (e.g., FCC ID in case of US, Manufacturer
Serial number, and so on)
INIT-RESP:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Information (e.g., authentication parameters ) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Result Code - Indicates success or failure
Security Information - Information required to initiate the
authentication process or perform the
capability negotiation
5.2. Device Registration
Device registration is the process of a device establishing certain
operational parameters with the database, as required by the spectrum
management authority. FCC rules require, for example, that Fixed
devices register owner and/or operator contact information. `Fixed
Devices` may also register their fixed location and antenna height
parameters so as to obviate sending that information in other messages
that would otherwise require them. Registration thus should not,
therefore, be performed upon each power-up; rather, only once upon
initial contact with the database, and thereafter, only when its
registered parameters change (e.g., a Fixed device is redeployed at a
new location, or its antenna height is adjusted.) or registration life-
time expires. It is to be noted that this functionality may be optional
in certain regulatory domains.
Das et al. Expires May 14, 2012 [Page 6]
Internet-Draft WS Protocol November 2011
REG-REQ and REG-RESP messages are used for device registration with
the database. Figure 3 depicts the message flow and example message
parameters are then discussed:
Device WS Database
| |
| REG-REQ |
|---------------------->|
| REG-RESP |
|<----------------------|
| |
| |
Figure 3: Device Registration Message Flow
REG-REQ:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Identity (e.g.,Regulatory ID, Device serial number,) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Location Information(e.g., Geo-location (latitude, |
| longitude, Antenna Height, and so on)) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Owner |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Device Type - Type of devices , for example, in US FCC rules this
is referred to as Fixed or Mode II device
Device Identity - Information that identifies the class of
device (e.g., FCC ID in case of US, Manufacturer
Serial number, and so on)
Device Location - Location information of the device, for example,
Geo-location, information about lat, long, antenna
Das et al. Expires May 14, 2012 [Page 7]
Internet-Draft WS Protocol November 2011
height and so on (location encoding of location is TBD)
Device Owner - Owner of the device
Message Authentication Code - Code that authenticates the ownership
Of the message
REG_RESP:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device Operator
Sequence no - Represents the message sequence
Result Code - Success or failure of device registration
Message Authentication Code - Code that authenticates the ownership
of the message
5.3. Querying the Database
In order to obtain the available channel and other associated
parameters, the device needs to query the database. In certain
regulatory environments, it may be required to be authenticated and
registered before a device can query the database. In other domains,
requirements may be vary. When the `Device` sends a query to the `WS
Database`, it sends its location (e.g., Geo-location) along with other
parameters. `WS Database` returns an array/set of channels within the
scope of the request (e.g. VHF/UHF) and regulatory authority where the
returned elements contain the channel frequency range, availability
indicator, operating power, event management (indicator when channel is
scheduled is or is not available), and so on. It may also include other
parameters depending upon the regulatory requirements.
AVAIL-CHAN-REQ and AVAIL-CHAN-RESP messages are used by devices for
querying the available channel in a given location. Figure 4 depicts
Das et al. Expires May 14, 2012 [Page 8]
Internet-Draft WS Protocol November 2011
the query message flow and example message parameters are then
discussed:
Device WS Database
| |
| AVAIL-CHAN-REQ |
|---------------------->|
| AVAIL-CHAN-RESP |
|<----------------------|
| |
| |
Figure 4: Query Message Flow
AVAIL-CHAN-REQ:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Identity (e.g.,Regulatory ID, Device serial number,) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Location (e.g., Geo-location (latitude, longitude, |
| Antenna Height, and so on) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Device Type - Type of devices , for example, in US FCC rules this
is referred to as Fixed or Mode II device
Device Identity - Information that identifies the class of
device (e.g., FCC ID in case of US, Manufacturer
Serial number, and so on)
Device Location - Location information of the device for example,
Geo-location, information about lat, long, antenna
height and so on (location encoding of location is
TBD)
Message Authentication Code - Code that authenticates the owner of
the Message
Das et al. Expires may 14, 2012 [Page 9]
Internet-Draft WS Protocol November 2011
AVAIL-CHAN-RESP:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number| Available Channel(s)(e.g., List[Channel |
| Frequency Range, Availability, Scope, |
| Max power and so on]) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Result Code - Success or failure of device registration
Sequence number - Represents the message sequence
Available Channel(s) - An array or set of channels within the scope
Of the request and regulatory authority
where the returned elements contain for
example, the channel frequency range,
availability indicator, operating power,
event , and so on.
Message Authentication Code - Code that authenticates the ownership
of the message
5.4. Device Validation
Device validation is the process by which devices can be validated by
the database. For example, by US FCC rule, the TVWS fixed or Mode II
device provides service to a Mode I device only after the Mode I is
validated by the TVWS database. To facilitate this validation, the WS
server needs to support `Device Validation` capability.
DEV-VALID-REQ and DEV-VALID-RESP messages are used for device
Validation with the database. Figure 5 depicts the message flow of the
Device validation and example message parameters are then discussed:
Das et al. Expires May 12, 2012 [Page 10]
Internet-Draft WS Protocol November 2011
Device WS Database
| |
| DEV-VALID-REQ |
|---------------------->|
| DEV-VALID-RESP |
|<----------------------|
| |
Figure 5: Device validation Message Flow
DEV-VALID-REQ:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Device Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Identity(e.g.,Regulatory ID, Device serial number,..) |
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Location (e.g., Geo-location (latitude, longitude, |
| Antenna Height, and so on) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device List (e.g., ID, Serial number..) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Device Type - Type of devices , for example, in US FCC rules this
is referred to as Fixed and Mode II device
Device Identity - Information that identifies the class of
device (e.g., FCC ID in case of US, Manufacturer
Serial number, and so on)
Device Location - Location information of the device for example,
Geo-location, information about lat, long, antenna
height and so on (location encoding of location is
TBD)
Device List - List of one or more devices that needs the validation
with ID, manufacturer serial number and so on..
Das et al. Expires May 14, 2012 [Page 11]
Internet-Draft WS Protocol November 2011
Message Authentication Code - Code that authenticates the ownership
of the message
DEV-VALID-RESP:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Authority | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device List (List/Array [result code]) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - Protocol version
Authority - Indicates the regulatory rules that need to be applied
to the device
Sequence number - Represents the message sequence
Device list - List/Array of devices with success or failure
Message Authentication Code - Code that authenticates the
ownership of the message
6. Encoding Considerations
The examples above suggest the message structure will have bit-oriented
fields, similar to the definition of TCP headers. However, such should
be taken as an illustrative example only. Other encodings (message
marshalling techniques) which convey the same semantic information can
and should be considered. For example, using XML or JSON to encode the
same fields discussed above should be an acceptable way forward. This
may in fact provide development and operational benefits.
7. Security Consideration
Following security requirements should be satisfied:
- Mutual Authentication
- Message Integrity
Das et al. Expires May 14, 2012 [Page 12]
Internet-Draft WS Protocol November 2011
- Confidentiality (optional)
- Replay protection
Others are TBD.
The requirement for the protocol to meet these may be considered in
conjunction with the underlying services and transports. For example,
the above protocol framework provides device authentication, replay-
protection, and message integrity at the application level. However,
the confidentiality is assumed to be provided by the underlying
transport protocol.
8. Acknowledgements
TBD
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
9.2. Informative References
[FCC] Second Memorandum Opinion and Order, FCC 10-174, September,
2010
[I-D.ietf-paws-problem-stmt-usecases-rqmts]
Probasco, S., Bajko, G., Patil, B., and B. Rosen,
"Protocol to Access White Space database: PS, use cases
and rqmts", draft-ietf-paws-problem-stmt-usecases-
rqmts01(work in progress), November 2011
10. Authors` Address
John P. Malyar
Telcordia Technologies Inc
One Telcordia Drive
Piscataway, NJ, 08854
Email: jmalyar at Telcordia dot com
Dan Harasty
Telcordia Technologies Inc
331 Newman Springs Road
Room NVC 2Z-447
Red Bank, NJ 07701
Email: dharasty at Telcordia dot com
Das et al. Expires May 14, 2012 [Page 13]
Internet-Draft WS Protocol November 2011
Subir Das
Telcordia Technologies Inc
One Telcordia Drive
Piscataway, NJ, 08854
Email: subir at research dot Telcordia dot com
Das et al. Expires May 14, 2012 [Page 14]