PAWS Database Discovery
draft-wei-paws-database-discovery-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xinpeng Wei , Lei Zhu | ||
| Last updated | 2013-10-15 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| 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-wei-paws-database-discovery-02
Internet Engineering Task Force X. Wei
Internet-Draft L. Zhu
Intended status: Informational Huawei
Expires: April 4, 2014 Oct 2013
PAWS Database Discovery
draft-wei-paws-database-discovery-02
Abstract
This document provides a Database Discovery mechanism for PAWS. By
this mechanism the master device gets the available WSDBs with which
it should communicate as well as the regulatory domain information.
The mechanism is based on the LoST protocol .
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 4, 2014.
Copyright Notice
Copyright (c) 2013 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.
Wei & Zhu Expires April 4, 2014 [Page 1]
Internet-Draft Abbreviated Title Oct 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Mechanism overview . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. System Architecture Description . . . . . . . . . . . . . . . 5
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Brief introduction of LoST . . . . . . . . . . . . . . . . 8
4.2. Issues to be clarified . . . . . . . . . . . . . . . . . . 10
4.2.1. Service Identifier . . . . . . . . . . . . . . . . . . 10
4.2.2. Conveying of regulatory domain . . . . . . . . . . . . 10
4.2.3. URL-related information . . . . . . . . . . . . . . . 10
4.3. Discovery procedures . . . . . . . . . . . . . . . . . . . 11
4.3.1. Discovery Request procedure . . . . . . . . . . . . . 11
4.3.2. Discovery Response procedure . . . . . . . . . . . . . 11
4.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative references . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Wei & Zhu Expires April 4, 2014 [Page 2]
Internet-Draft Abbreviated Title Oct 2013
1. Introduction
1.1. Motivations
In the PAWS protocol, the master device queries the database for
available spectrum, but the device MUST determine the URL for the
database before it can send any PAWS messages. Brief discussions of
database discovery can be found in [RFC6953] and [PAWS PROTOCOL].
Several different choices can be taken for the device to determine
the appropriate URL(s) for connection. There are some possible
methods for this purpose (not all methods are included here): (1) The
manufacture or the user of device can manually pre-configure
statically the URL(s) of one or more databases that is available for
the device to query white space spectrum (e.g. the device and
database have agreements with each other.), for example, if the
device is to be used in US, it will be configured with the database
of US, and then it directly connects to the database in US, or if the
device is to be used in several countries it can be configured with
different database for each country. (2) The device can be configured
by certain provisioning process after attaching to operator's
network. (3) An entity of Listing server[PAWS PROTOCOL], providing
the URLs for one or more Spectrum Databases, could be deployed in a
regulatory domain, then the device queries and checks available
databases from the Listing server. (4) When the database which the
device currently connects to cannot provide service for this device
any more, it can redirects this device to anther database that can
serve the master [PAWS PROTOCOL].
But in some scenarios the methods above may not work well: (1) To
pre-configure device, the user has to know the available database(s)
that can be used in the regulatory domain, it may be inconvenient
especially when the device is moved to a different regulatory domain.
(2) It is possible that some databases are not available any more or
some new databases are setup, the pre-configuring and provisioning
method may not cope with it very well. (3) It is possible that in
pre-configuring method the available databases of several regulatory
domains may be pre-configured in device, and whether it is convenient
for a device to know which regulatory domain it currently locates at
the beginning. (4) In the method that database provides redirecting
to the master device some security related issues have to be
considered. It might be ok for a database to provide master device
with URL of another database in the same regulatory domain. But in
case when master moves from regulatory domain A to regulatory domain
B, it might not all seems right for database of A to provide
regulatory domain information and available databases or Listing
server of B to the device, because PAWS databases and master devices
are each certified to operate in certain regulatory domains.
Wei & Zhu Expires April 4, 2014 [Page 3]
Internet-Draft Abbreviated Title Oct 2013
So a dynamic database discovery mechanism is provided here, the
mechanism can be used independently or cooperate with other methods,
e.g. device can first connect to the configured or provisioned
databases, if that fails then the device can use the dynamic
mechanism to find out available databases.
The discovery mechanism discussed here will provide master device
with two kind of information: the regulatory domain where the device
locates now and the available list of DBs or a Listing server in that
domain.
The mechanism discussed in this memo will be provided as an OPTIONAL
method as described in PAWS PROTOCOL [PAWS PROTOCOL].
1.2. Mechanism overview
The dynamic database discovery mechanism provided here is used by a
device to discover the available white space databases for its
current location and related regulatory domain information.
In discovery procedure, the URI for the database SHOULD be obtained
from an authorized and authenticated entity. The master device
provides its current geo-location information to the entity in
Database Discovery Request message, and the entity will return a list
of available databases/or Listing server and the regulatory body
related information that has jurisdiction over the master device's
location.
When the master device gets the information about available database
and regulatory body, it can choose the proper database for querying
white space spectrum by PAWS procedures.
2. Terminology and Conventions
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 RFC2119 [RFC2119].
The terminology from PAWS: problem statement, use cases and
requirements RFC6953 [RFC6953] is applicable to this document.
White Space Database (WSDB)
In the context of white space and cognitive radio technologies, the
database is an entity which contains, but is not limited to, current
information as required by the regulatory policies about available
spectrum at any given location and time, and other types of related
Wei & Zhu Expires April 4, 2014 [Page 4]
Internet-Draft Abbreviated Title Oct 2013
(to the white space spectrum) or relevant information.
White Space Database Discovery Server (WSDB DS)
A server function provided to a white space device, the client. The
white space device contacts a white space database discovery server
to receive the service of discovering or identifying one or more
white space databases. The white space database discovery server is
a known entity to the white space device, which knows at least a
useable internet address for the white space database discovery
server. The white space database discovery server takes as input
positioning information from the white space device and returns both
URLs of white space databases that cover white space device's current
location and indication of the regulatory domain governing at the
white space device's current location. A single white space database
discovery server may have global scope, serving clients located
globally.
Mapping
Mapping is a process that takes a location and a service identifier
as inputs and returns one or more URLs. Those URLs can point either
to a host providing that service or to a host that in turn routes the
request to the final destination.
Device
The device in this memo is equivalent to the master device described
in RFC6953 [RFC6953].
3. System Architecture Description
Before the WSD can query a trusted WSDB for a list of available
frequencies or channels for use in the white space spectrum, the WSD
must first discover the available databases and addresses serving the
regulatory domain in which the device is currently located. At
power-up the WSD does not reliably know the regulatory domain
corresponding to its current location, and therefore does not
reliably know with which white space database(s) it can communicate.
Furthermore it is essential that the WSD connect with a trusted WSDB
for proper operation and indeed regulatory compliance.
The discovery system is based on client-server model; the basic model
is shown in Figure 1.
Wei & Zhu Expires April 4, 2014 [Page 5]
Internet-Draft Abbreviated Title Oct 2013
+----------+ +----------+
| Master | <--------> | WSDB DS |
+----------+ +----------+
Figure 1: DB discovery system model
The WSDB DS takes as input location information from the WSD and
returns to the WSD one or more addresses of WSDBs or WSDB Listing
servers as appropriate to the WSD.
For the discovery mechanism to work well, some assumptions have to be
considered:
(1) Master device can get its geo-location directly or indirectly.
(2) Master device has gotten the URL (or IP address) of a trusted
WSDB DS before starting the discovery procedure.
The URL or IP address of WSDB DS can be found by any method such as
DNS, manually configuring etc, and it is out of scope of this
document.
The WSDB DSs can be deployed independently without knowledge of each
other; a lot of WSDB DS can be deployed all around the world.
When the WSD does not have the address of a serviceable WSDB (e.g. at
power-up or failed to get the current regulatory domain etc), the WSD
sends a Discovery Request message to a WSDB DS. The WSD includes in
the Discovery Request information about its current location. The
WSDB DS uses this location information to determine the regulatory
domain where the WSD is located, and returns a Discovery Response
message which includes the address of one or more WSDBs (or WSDB
listing server as appropriate) and regulatory domain related
information to the WSD.
An overview of procedures of how master device gets available
spectrum from WSDB is depicted in Figure 2.
Wei & Zhu Expires April 4, 2014 [Page 6]
Internet-Draft Abbreviated Title Oct 2013
+-----------+ +-----------+ +----------+
| | | WSDB | | |
| WSD | | Discovery | | WSDB |
| | | Server | | |
+-----------+ +-----------+ +----------+
| | |
| | |
0.Discovery Trigger | |
| 1.Discovery Request | |
|(location information, etc) | |
|--------------------------->| |
| | |
| 2.Discovery Response | |
| (address information, etc) | |
|<---------------------------| |
| | |
| | |
| /--------------------------|-----------------------\ |
|/ | \|
|\ | 3.(PAWS) /|
| \--------------------------|-----------------------/ |
| | |
| | |
Figure 2: An overview of procedures of how master device gets
available spectrum from WSDB
(0) Discovery trigger. There are several conditions that could
trigger the database discovery procedure, for example, after master
device's power-up, or when master device moves into a new regulatory
domain, or when master device fails to connect to all of the pre-
configured databases etc.
(1) Discovery Request procedure. This message is used by master
device to query available WSDB from WSDB DS; it conveys master's
location and some other related information to WSDB DS.
(2) Discovery Response procedure. This procedure conveys the
regulatory domain and either the address of a listing server or the
address of one or more WSDB authorized to provide service where the
WSD is physically located to the master device. If spectrum access
is not authorized at the WSD physical location, the response will
contain an error code and no address information.
(3) After WSDB discovery procedure, the master device can query
available white space spectrum from the WSDB using PAWS protocol.
Wei & Zhu Expires April 4, 2014 [Page 7]
Internet-Draft Abbreviated Title Oct 2013
Figure 3 shows at a high level how white space master devices
discover a suitable trusted white space database. In this document
we describe how the master device may collect the addresses of one or
more white space database. Procedures to contact a white space
database are specified in PAWS PROTOCOL. [PAWS PROTOCOL]
+------+ +-------+
|Master| |WSDB DS|
+---+--+ +---+---+
| |
| 1.Request(location,service id) |
------------------------------------>|
| |
| 2.Response(a list of URLs of DB)|
|<-----------------------------------|
| |
+-----------------------------------------+ |
|3.Select an available DB that can be used| |
| by master to query for white space | |
+-----------------------------------------+ |
| |
| |
| |
Figure 3: High level view of white space database discovery
After master device has selected a available database for service, it
can then use the PAWS protocol [PAWS PROTOCOL] to retrieve the
available spectrum for its location.
4. Specification
In this document, a dynamic database discovery mechanism based on
existing LoST protocol [RFC5222] is discussed.
4.1. Brief introduction of LoST
LoST (Location-to-Service Translation Protocol) is an XML-based
protocol for mapping service identifiers and geodetic or civic
location information to service contact URIs and associated
information.
Wei & Zhu Expires April 4, 2014 [Page 8]
Internet-Draft Abbreviated Title Oct 2013
+-----------+ +-----------+
|LoST client| |LoST server|
+-----------+ +-----------+
| |
| |
1.Request Message(Location info,service identifier |
|--------------------------------------------------> |
| |
| +-------------------------------+
| |2.mapping location info+service|
| |to service URL(s) |
| +-------------------------------+
| |
| |
| 3.Response Message(Service URL(s)) |
|<---------------------------------------------------|
| |
| |
Figure 4: n overview of procedures in LoST protocol
The LoST client sends its location information and service type it
wants to LoST server to retrieve one or more service URIs.
The LoST server maintains the mapping relationship between location
and service URI, on receiving request message it maps the location
and service identifier in the request to one or more service URLs
that can offer the service in the location.
LoST messages are carried in HTTP and HTTPS protocol exchanges,
facilitating use of TLS for protecting the integrity and
confidentiality of requests and responses.
This discovery mechanism utilizes LoST to communicate between master
device and WSDB DS, the master device acts as LoST client and WSDB DS
plays the role of LoST server. The protocol stack is shown in Figure
5. To use LoST for this discovery mechanism, several issues have to
be clarified.
Wei & Zhu Expires April 4, 2014 [Page 9]
Internet-Draft Abbreviated Title Oct 2013
+------------+
| LoST +
+------------+
| HTTPS +
+------------+
| TCP +
+------------+
| IP +
+------------+
Figure 5: Protocol stack for discovery mechanism
4.2. Issues to be clarified
4.2.1. Service Identifier
A new service identifier for PAWS database discovery needs to be
defined, according to RFC5031 [RFC5031], a top-level service and a
sub-service are defined here.
+----------------+-------------------------------------+
| Service | Description |
+----------------+-------------------------------------+
| paws | top-level service of PAWS |
| paws.discovery | the PAWS database discovery service |
+----------------+-------------------------------------+
Table 1
So according to the service-identifying labels defined above, the
service URN for PAWS database discovery service is as follow:
urn:service:paws.discovery
4.2.2. Conveying of regulatory domain
The name of regulatory domain can be conveyed using <displayName>
element in the LoST response message.
[Note: the format and content of the regulatory domain information
are TBD.]
4.2.3. URL-related information
The WSDB DS may return database or Listing server to master device,
but because the database and Listing server are all in the form of
URL, so it may be difficult for mater device to distinguish between
Wei & Zhu Expires April 4, 2014 [Page 10]
Internet-Draft Abbreviated Title Oct 2013
database URL and Listing server URL. Here an extension to LoST is
needed: for every <URI> element that used for conveying URL a new
attribute ("indicator") which indicates whether it is a URL of
database or a URL of Listing server.
When the URL is for a database, then master device can run PAWS
protocol to query white space spectrum from the database; or when the
URL is for a Listing server, then master device connects to the
Listing server for available database(s) in the domain.
4.3. Discovery procedures
4.3.1. Discovery Request procedure
The discovery request procedure uses the <findService> query message
of LoST for conveying parameters. Master device's location
information will be included in the <location> element.
The service identifier defined in Section 4.2.1 is specified in the
<service> element.
The following is an example of discovery request procedure message,
using geodetic coordinates.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:paws.discovery</service>
</findService>
4.3.2. Discovery Response procedure
The discovery response procedure uses the <findServiceResponse>
response message of LoST for conveying parameters.
After receiving the <findService> query message, the WSDB DS will map
the location information and service identifier to one or more
available WSDBs' URL.
Wei & Zhu Expires April 4, 2014 [Page 11]
Internet-Draft Abbreviated Title Oct 2013
Then in the <findServiceResponse> message, a list of WSDBs' URL and
regulatory domain that has jurisdiction over the current location
will be conveyed to master device. The regulatory domain is
contained in <displayName> element.
The service boundary of the WSDB can also be included in the response
message to indicate the region for which the service URL returned
would be the same as in the actual query. Or a service boundary
reference can be returned to master device, and master device
retrieve service boundary by this reference as needed. Next time
when the master device powers up, if its location is within the
service boundary it then may use the WSDB retrieved before.
An example of discovery response procedure message is shown as
follow:
Wei & Zhu Expires April 4, 2014 [Page 12]
Internet-Draft Abbreviated Title Oct 2013
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2013-05-01T01:44:33Z"
lastUpdated="2012-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">
Federal Communications Commission
</displayName>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<service>urn:service:paws.discovery</service>
<uri indicator="database">database1.example1.com</uri>
<uri indicator="database">database2.example2.com</uri>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
4.3.3. Recursion and Iteration
If the WSDB DS can not provide available WSDB for master device, then
it may wish other WSDB DS to serve the master device's query request.
In LoST, recursion and iteration patterns are provided for this
purpose.
In recursive mode, the LoST server initiates queries on behalf of the
requester and returns the result to the requester.
In iterative mode, the server contacted returns a redirection
response indicating the next server to be queried if the server
Wei & Zhu Expires April 4, 2014 [Page 13]
Internet-Draft Abbreviated Title Oct 2013
contacted cannot provide an answer itself.
5. Security Considerations
TBD.
6. IANA Consideration
Registration of service URN for PAWS database discovery service.
+----------------+-------------------------------------+
| Service | Description |
+----------------+-------------------------------------+
| paws | top-level service of PAWS |
| paws.discovery | the PAWS database discovery service |
+----------------+-------------------------------------+
Table 2
7. Acknowledgements
Thanks to my colleagues for their sincerely help and comments when
drafting this document.
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
8.2. Informative References
[PAWS PROTOCOL]
Chen, V., Das, S., Zhu, L., McCann, P., and J. Malyar,
"Protocol to Access Spectrum Database",
Wei & Zhu Expires April 4, 2014 [Page 14]
Internet-Draft Abbreviated Title Oct 2013
draft-ietf-paws-protocol-06 (work in progress), June 2013.
[RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to
Access White-Space (PAWS) Databases: Use Cases and
Requirements", RFC 6953, May 2013.
Authors' Addresses
Xinpeng Wei
Huawei
Phone: +86 134 3682 2355
Email: weixinpeng@huawei.com
Lei Zhu
Huawei
Phone: +86 139 1015 7020
Email: lei.zhu@huawei.com
Wei & Zhu Expires April 4, 2014 [Page 15]