Internet Engineering Task Force X. Wei Internet-Draft L. Zhu Intended status: Informational Huawei Expires: July 5, 2014 Jan 2014 PAWS Database Discovery draft-wei-paws-database-discovery-03 Abstract This document provides a Database Discovery mechanism for PAWS. By this mechanism the master device gets the available WSDBs it can communicate. 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 July 5, 2014. Copyright Notice Copyright (c) 2014 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 July 5, 2014 [Page 1] Internet-Draft Abbreviated Title Jan 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative references . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Wei & Zhu Expires July 5, 2014 [Page 2] Internet-Draft Abbreviated Title Jan 2014 1. Introduction 1.1. Motivations In the PAWS protocol, the master device queries the database for available spectrum, but it 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]. Different regulatory domains might deploy their own WSDB and several WSDBs might be deployed in the same regulatory domain, so before querying the WSDB master device should find out which WSDB can provide service for it. And there are some WSDB discovery scenarios. S1: Master device locates in its own regulatory domain, master device needs to know the available WSDBs that can provide service for it in the regulatory domain. S2: In the regulatory domain, when some WSDBs are not available any more or some new WSDBs are setup, master device should accommodate to the change of available WSDBs. S3: A portable master device could move from its home regulatory domain to a different regulatory domain, and it should find available WSDB in target regulatory domain. For example, when a person, named Bob, travels and takes a Wi-Fi AP (could be integrated with laptop PC) with him, if there is a port of wired network, it is easy for him to setup a wireless network for use. But if Bob takes an AP using white space spectrum, it must find an available WSDB in that regulatory domain before setup the wireless network. Several different methods could be used for master device to determine the appropriate URL(s) for connection. Here we list some possible methods for this purpose (not all methods are included here): M1: The manufacture or the user of master device can manually pre- configure statically the URL(s) of one or more WSDBs that is available for master device to query white space spectrum (e.g. master device and WSDB have agreements with each other.). For example, if master device is to be used in U.S., it will be configured with the WSDB of U.S., and then it directly connects to the WSDB in U.S., or if master device is to be used in several countries it can be configured with different WSDBs for each country. M2: Master device might be configured by certain provisioning process after attaching to operator's network. The provisioning process might be DHCP process, OSS process etc. Wei & Zhu Expires July 5, 2014 [Page 3] Internet-Draft Abbreviated Title Jan 2014 M3: An entity of Listing server [PAWS PROTOCOL], providing the URLs for one or more WSDBs, could be deployed in a regulatory domain, then master device queries and checks available WSDBs from the Listing server. M4: When WSDB, which master device currently connects to, cannot provide service any more, it can redirects the master device to another WSDB that can provide service [PAWS PROTOCOL]. But in some scenarios the methods above may not work very well: (1) To pre-configure master device, the user has to know the available WSDB (s) that can be used in the regulatory domain, it may be inconvenient especially when master device is moved to a different regulatory domain. (2) It is possible that some WSDBs are not available any more or some new WSDBs are setup, the pre-configuring and provisioning method may not cope with it very well. (3) In pre-configuring method, it is possible for master device to be pre-configured with available WSDB of several regulatory domains. But master device must decide which regulatory domain it locates in before choosing the available WSDB. (4) The network provision method might work well only in case of WSDBs are maintained by network operators or there should be some agreement relationship between network operator and WSDB maintainer. (5) In the method that WSDB provides redirecting to the master device, some security related issues have to be considered. It might be feasible for a WSDB to provide master device with URL of another WSDB in the same regulatory domain. But in case when master device moves from regulatory domain A to regulatory domain B, it might seem not right for WSDB of A to provide regulatory domain information and available WSDBs or Listing server of B to the master device, because WSDB and master devices are each certified to operate in certain regulatory domains. At power-up master device does not reliably know the regulatory domain corresponding to its current location, and therefore does not reliably know with which WSDB(s) it can communicate to. Furthermore it is essential that master device connects with a trusted WSDB for proper operation and indeed regulatory compliance. So a dynamic WSDB discovery mechanism is provided here, the mechanism can be used independently or cooperate with other methods, e.g. master device could first connect to the configured or provisioned Wei & Zhu Expires July 5, 2014 [Page 4] Internet-Draft Abbreviated Title Jan 2014 WSDB, if that fails then the master device can use the dynamic mechanism described in this document to find out available WSDB. The dynamic WSDB discovery mechanism is used by master device to discover available WSDBs for its current location and related regulatory domain information. After master device gets the information about available WSDB and regulatory domain information, it then chooses the proper WSDB for querying white space spectrum using PAWS procedures. The discovery mechanism discussed here will provide master device with two kinds of information: the regulatory domain where the device currently locates and the available list of WSDBs or a Listing server in current domain. The mechanism discussed in this memo will be provided as an OPTIONAL method as described in [PAWS PROTOCOL]. 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. Master Device A device that queries the database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information. 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 WSDB DS to receive the service of discovering or identifying one or more white space databases. RB_server Wei & Zhu Expires July 5, 2014 [Page 5] Internet-Draft Abbreviated Title Jan 2014 Master device can query its current regulatory body domain information from RB_server. RB_server setup by vendor or by third party. Besides regulatory domain information, RB_server might provide additional information (TBD). LoST LoST (Location-to-Service Translation Protocol)RFC5222 [RFC5222] is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs and associated information. 3. Solutions Considering of different business models, regulations in different regulatory domain and some existing deployments, in this version of draft, several possible solutions are discussed. [NOTE1: Although several solutions are discussed here, but finally we may only choose the best one.] 3.1. Solution 1 It's reasonable for the regulatory body to know all the WSDBs deployed in its domain, because when a WSDB is deployed it must get the permission of regulatory body. So it is suitable for each regulatory body to deploy a WSDB DS. In this solution, each regulatory body maintains its own WSDB DS, which records all the WSDBs for the regulatory domain. When master device operates in certain regulatory domain, it gets available WSDB from regulatory domain's WSDB DS. Besides WSDB DS deployed by each regulator body, an entity named RB_Server is also deployed. RB_Server is a server which provides WSDB DS information to master device according to geo-location provided by master device. The DNS domain name or IP address of RB_Server should pre-configured in master device. There are two considerations on how to deploy RB_Server. (a) RB_Server(s) could be setup according to international agreement among various spectrum regulators. In this case a query protocol between master device and RB_Server is needed, and LoST protocol would be an appropriate candidate. RB_Server and WSDB DS act as LoST server and master device acts as LoST client. (b) Absent such an international agreement, each radio vendor would Wei & Zhu Expires July 5, 2014 [Page 6] Internet-Draft Abbreviated Title Jan 2014 be responsible (under its certification agreement with each regulator) to ensure that its devices operate properly when they are in the geographic territory for which they have been certified, RB_Server could be setup by the vendor of master device, and each vendor's RB_Server provides service to its own master device. An example of deployment is shown in Figure 1. There are three regulatory domains, named A, B and C; one or more WSDBs and one WSDB DS are deployed in each domain. +------------------------------------------------+ | +--------+ | +--------+ | | |Domain A| | |Domain B| | | +--------+ | +--------+ | | +-----+ | | | |WSDB1| +-----+ | +------+ | | +-----+ |WSDB2| | |WSDB 3| | | +-----+ | +---------+ +------+ | | +---------+ | |WSDB DS#B| | | |WSDB DS#A| | +---------+ | | +---------+ | +-------------+ | | | |master device| | | | +--_----------+ | +------------------------'----,'-----------------+ , ' ,' +---------+ |RB_Server| +---------+ Figure 1: Solution 1: Framework of WSDB discovery 3.2. Solution 2 This solution provides a more flexible WSDB discovery method. In this solution, RB_Server and DNS system are used. It is possible that regulatory bodies get an agreement each one deploys its own WSDB DS, and under such an agreement solution1 would be a good choice for WSDB discovery. But if regulatory bodies cannot reach such an agreement, i.e. not all regulatory bodies would deploy WSDB DS, then solution2 would be a good choice. The framework of WSDB discovery for solution 2 is shown in Figure 2. Wei & Zhu Expires July 5, 2014 [Page 7] Internet-Draft Abbreviated Title Jan 2014 +------------------------------------------------+ | +--------+ | +--------+ | | |Domain A| | |Domain B| | | +--------+ | +--------+ | | +-----+ | | | |WSDB1| +-----+ | +------+ +------+ | | +-----+ |WSDB2| | |WSDB 4| |WSDB 3| | | +-----+ | +------+ +------+ | | +---------+ | | | |WSDB DS#A| | | | +---------+ | +-------------+ | | | |master device| | | | +--_----+-----+ | +------------------------'----,'-----+-----------+ ,' \ ,' | +---------+ +-+-+ |RB_Server| |DNS| +---------+ +---+ Figure 2: Solution 2: Framework of WSDB discovery The basic WSDB discovery procedure is shown in Figure 3. Wei & Zhu Expires July 5, 2014 [Page 8] Internet-Draft Abbreviated Title Jan 2014 +--------------------------+ |Step1. master device gets | |DNS domain name of the | |regulator from RB_Server. | +------------|-------------+ | +-------------------V--------------------+ |Step2. master device starts DNS | |procedure using DNS domain name | |retrieved in Step1, and gets DNS domain | |name/IP address of WSDB DS or WSDB. | +-------------------|--------------------+ | | +------------V---------+ +---------------------+ |DNS procedure returns | No |Step3b. master device| |a WSDB DS? |---> |connects to WSDB. | +------------|---------+ +---------------------+ | | Yes +-----------V----------+ |Step3a. master device | |gets WSDB from WSDB | |DS. | +----------------------+ Figure 3: Solution2: Basic WSDB discovery procedure In this solution, NAPTR DNS Resource Record (RR) RFC3403 [RFC3403] is used . Each regulator maintains NAPTR RRs by itself, and every WSDB or WSDB DS has a related NAPTR RR. The service field of NAPTR RR is used to indicate whether the RR is for WSDB or WSDB DS. An example of NAPTR RRs is shown as follows. [NOTE2: If NAPTR RR for WSDB DS exists, then there might be no NAPTR RRs for WSDBs.] A simple NAPTR example: paws.fcc.gov IN NAPTR 100 100 A paws-db '' exam1.company1.com ; DB returned IN NAPTR 100 100 A paws-ds '' exam2.company2.com ; WSDB DS returned IN NAPTR 100 100 A paws-db '' exam3.company3.com ; DB returned There is a bit of difference between RB_Servers in solution 2 and Wei & Zhu Expires July 5, 2014 [Page 9] Internet-Draft Abbreviated Title Jan 2014 solution 1, in solution 2 RB_Server returns DNS domain name for the regulatory domain, which will be used in the following DNS procedure. 3.3. Solution 3 In this solution, WSDB DS is deployed independently from regulatory domain (but we don't except regulatory body from deploying their own WSDB DS). WSDB DS maintains WSDBs for regulatory domains or only maintains WSDB DS in case regulator deploys WSDB DS by itself and needs master device get WSDB from its own WSDB DS. The DNS domain name or IP address of such an independent WSDB DS should be pre- configured in master device. An example of deployment is shown in Figure 4. +------------------------------------------------+ | +--------+ | +--------+ | | |Domain A| | |Domain B| | | +--------+ | +--------+ | | +-----+ | | | |WSDB1| +-----+ | +------+ +------+ | | +-----+ |WSDB2| | |WSDB 4| |WSDB 3| | | +-----+ | +------+ +------+ | | +---------+ | | | |WSDB DS#A| | | | +---------+ | +-------------+ | | | |master device| | | | +--_----+-----+ | +------------------------'----,'-----+-----------+ ,' ,' +-------+ |WSDB DS| +-------+ Figure 4: Solution 3: Framework of WSDB discovery There are two considerations on how to deploy independent WSDB DS. (a) WSDB DS could be setup according to international agreement among various spectrum regulators. In this case a query protocol between master device and WSDB DS is needed, and LoST protocol would be an appropriate candidate. Both independent WSDB DS and WSDB DS deployed by regulatory body act as LoST server and master device acts as LoST client. (b) Absent such an international agreement, each radio vendor would be responsible (under its certification agreement with each regulator) to ensure that its devices operate properly when they are Wei & Zhu Expires July 5, 2014 [Page 10] Internet-Draft Abbreviated Title Jan 2014 in the geographic territory for which they have been certified, WSDB DS could be setup by the vendor of master device, and each vendor's WSDB DS provides service to its own master device. 3.4. Solution 4 Like solution1, in this solution each regulatory body deploys its own WSDB DS. A LoST service wsdb is defined, which is used to get URL of WSDB, and WSDB DS acts as a server that can provide wsdb service. Master device acts as LoST client. One DHCP extension has been defined in RFC5223 for discovering LoST server, so when master device attaches to operator's network, master device could be provisioned with IP address of an LoST server through DHCP procedure. The LoST server provisioned here might not be the address of WSDB DS, but according to LoST architecture, master device can finally connect to WSDB DS after iterative or recursive procedures. 4. Security Considerations TBD. 5. IANA Consideration TBD. 6. Acknowledgements 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. Wei & Zhu Expires July 5, 2014 [Page 11] Internet-Draft Abbreviated Title Jan 2014 7.2. Informative References [PAWS PROTOCOL] Chen, V., Das, S., Zhu, L., McCann, P., and J. Malyar, "Protocol to Access Spectrum Database", draft-ietf-paws-protocol-07 (work in progress), Dec 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 July 5, 2014 [Page 12]