Internet Engineering Task Force X. Wei Internet-Draft L. Zhu Intended status: Standards Track Huawei Expires: October 3, 2013 April 2013 PAWS Database Discovery draft-wei-paws-database-discovery-01 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 October 3, 2013. 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 October 3, 2013 [Page 1] Internet-Draft Abbreviated Title April 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Mechanism overview . . . . . . . . . . . . . . . . . . . . 3 1.3. Brief introduction of LoST . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. System Architecture Description . . . . . . . . . . . . . . . 6 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Issues to be clarified . . . . . . . . . . . . . . . . . . 9 4.1.1. Service Identifier . . . . . . . . . . . . . . . . . . 9 4.1.2. Conveying of regulatory domain . . . . . . . . . . . . 10 4.1.3. Database administrator information . . . . . . . . . . 10 4.2. Discovery procedures . . . . . . . . . . . . . . . . . . . 10 4.2.1. Discovery Request procedure . . . . . . . . . . . . . 10 4.2.2. Discovery Response procedure . . . . . . . . . . . . . 11 4.2.3. Recursion and Iteration . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wei & Zhu Expires October 3, 2013 [Page 2] Internet-Draft Abbreviated Title April 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 [PAWS RQMTS] 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 manufacturer 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) or the device can be configured by certain provisioning process after attaching to operator's network. But in some scenarios the methods above may not work well. For example, to pre-configure a device, the user has to know the available database(s) that can be used in the regulatory domain, and it may be inconvenient to do so especially when the device is moved to a different regulatory domain. So a dynamic database discovery mechanism is provided here, and 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. Besides, 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. 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 the discovery procedure, the URL for the database SHOULD be Wei & Zhu Expires October 3, 2013 [Page 3] Internet-Draft Abbreviated Title April 2013 obtained from an authorized and authenticated entity. The master device provides its current geo-location information to the entity in a Database Discovery Request message, and the entity will return a list of available databases and the regulatory body 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. The database discovery mechanism is based on LoST protocol [RFC5222]. 1.3. 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 URLs. +-----------+ +-----------+ |LoST Client| |LoST Server| +------.----+ +------.----+ | | | Request(Location info,service id) | |------------------------------------->| | | | +---------------------------------+ | |Mapping location and serivice id | | | | | to service URL(s) | | +---------------------------------+ | | | Response(Service URL(s)) | | <----------------------------------- | | | | | | | | ' Figure 1: An 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 URLs. The LoST server maintains the mapping relationship between location and service URL, and 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. Wei & Zhu Expires October 3, 2013 [Page 4] Internet-Draft Abbreviated Title April 2013 LoST can operate in either recursive or iterative mode, on a request- by-request basis. 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 contacted cannot provide an answer itself. 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 PAWS RQMTS [PAWS RQMTS] 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 (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. Service boundary A service boundary circumscribes the region within which all locations map to the same service URL or set of URLs for a given service. A service boundary may consist of several non-contiguous Wei & Zhu Expires October 3, 2013 [Page 5] Internet-Draft Abbreviated Title April 2013 geometric shapes. 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 PAWS RQMTS [PAWS RQMTS]. 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 2, where WSDB DB (WSDB Discovery Server) plays the role of LoST server and Master device acts as LoST client. +----------+ +----------+ | Master | <--------> | WSDB DS | +----------+ +----------+ Figure 2: 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. Wei & Zhu Expires October 3, 2013 [Page 6] Internet-Draft Abbreviated Title April 2013 The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. When the WSD does not have the address of a serviceable WSDB (e.g. at power-up), 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) to the WSD. An overview of procedures of how master device gets available spectrum from WSDB is depicted in Figure 3. +-----------+ +-----------+ +----------+ | | | WSDB | | | | WSD | | Discovery | | WSDB | | | | Server | | | +-----------+ +-----------+ +----------+ | | | | Discovery Request | | |(location information, etc) | | |--------------------------->| | | | | | Discovery Response | | | (address information, etc) | | |<---------------------------| | | | | | | | | /--------------------------|-----------------------\ | |/ | \| |\ | (PAWS) /| | \--------------------------|-----------------------/ | | | | | | | Figure 3: An overview of procedures of how master device gets available spectrum from WSDB (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 Wei & Zhu Expires October 3, 2013 [Page 7] Internet-Draft Abbreviated Title April 2013 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. Figure 4 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| +---+--+ +---+---+ | | | Request(location,service id) | ------------------------------------>| | | | Response(a list of URLs of DB) | |<-----------------------------------| | | +----------------------------------------+ | |Select an available DB that can be used | | | by master to query for white space | | +----------------------------------------+ | | | | | | | Figure 4: High level view of white space database discovery In the response message a list of databases that cover the location are included, when a database is included, it only means the location is in its coverage range but not means the master device can get service from the database, because the database may need the master device has service agreement or some other relationship with it. So master device needs to select an available database from the database list. After master device has selected a available database for service, it can then use the PAWS protocol PAWS PROTOCOL [PAWS PROTOCOL] to retrieve the available spectrum for its location. Wei & Zhu Expires October 3, 2013 [Page 8] Internet-Draft Abbreviated Title April 2013 4. Specification LoST (Location to Service Translation Protocol) is a protocol for mapping a service identifier (URN) and location information to one or more service URLs and associated information. LoST mapping queries can contain either civic or geodetic location information. LoST queries can be resolved recursively or iteratively. 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. +------------+ | LoST + +------------+ | HTTPS + +------------+ | TCP + +------------+ | IP + +------------+ Figure 5: Protocol stack for discovery mechanism 4.1. Issues to be clarified 4.1.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 Wei & Zhu Expires October 3, 2013 [Page 9] Internet-Draft Abbreviated Title April 2013 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.1.2. Conveying of regulatory domain The name of regulatory domain can be conveyed using element in the LoST response message. [Note: the format and content of the regulatory domain information are TBD.] 4.1.3. Database administrator information The WSDB DS can return one or more databases to master device, but because the databases are in the form of URL so it may be difficult to decide which one has service agreement with the master device. Here an extension to LoST is needed: for every element that used for conveying URL a new attribute (admin) which contains the database's administrator information needs to be added. Based on the newly added attribute master device can choose the database that it has agreement with. 4.2. Discovery procedures 4.2.1. Discovery Request procedure The discovery request procedure uses the query message of LoST for conveying parameters. Master device's location information will be included in the element. The service identifier defined in Section 4.1.1 is specified in the element. The following is an example of discovery request procedure message, using geodetic coordinates. Wei & Zhu Expires October 3, 2013 [Page 10] Internet-Draft Abbreviated Title April 2013 37.775 -122.422 urn:service:paws.discovery 4.2.2. Discovery Response procedure The discovery response procedure uses the response message of LoST for conveying parameters. After receiving the query message, the WSDB DS will map the location information and service identifier to one or more available WSDBs' URL. Then in the 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 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 October 3, 2013 [Page 11] Internet-Draft Abbreviated Title April 2013 Federal Communications Commission 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 urn:service:paws.discovery database1.example1.com database2.example2.com 4.2.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 October 3, 2013 [Page 12] Internet-Draft Abbreviated Title April 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 October 3, 2013 [Page 13] Internet-Draft Abbreviated Title April 2013 draft-ietf-paws-protocol-01 (work in progress), December 2012. [PAWS RQMTS] Probasco, S. and B. Patil, "Protocol to Access White Space database: PS, use cases and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-12 (work in progress), January 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 October 3, 2013 [Page 14]