idnits 2.17.00 (12 Aug 2021) /tmp/idnits14723/draft-wei-paws-database-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 2014) is 3048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-paws-protocol has been published as RFC 7545 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force X. Wei 3 Internet-Draft L. Zhu 4 Intended status: Informational Huawei 5 Expires: July 5, 2014 Jan 2014 7 PAWS Database Discovery 8 draft-wei-paws-database-discovery-03 10 Abstract 12 This document provides a Database Discovery mechanism for PAWS. By 13 this mechanism the master device gets the available WSDBs it can 14 communicate. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 5, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 53 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 57 3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 11 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 7.1. Normative references . . . . . . . . . . . . . . . . . . . 11 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 1.1. Motivations 70 In the PAWS protocol, the master device queries the database for 71 available spectrum, but it MUST determine the URL for the database 72 before it can send any PAWS messages. Brief discussions of database 73 discovery can be found in [RFC6953] and [PAWS PROTOCOL]. 75 Different regulatory domains might deploy their own WSDB and several 76 WSDBs might be deployed in the same regulatory domain, so before 77 querying the WSDB master device should find out which WSDB can 78 provide service for it. And there are some WSDB discovery scenarios. 80 S1: Master device locates in its own regulatory domain, master device 81 needs to know the available WSDBs that can provide service for it in 82 the regulatory domain. 84 S2: In the regulatory domain, when some WSDBs are not available any 85 more or some new WSDBs are setup, master device should accommodate to 86 the change of available WSDBs. 88 S3: A portable master device could move from its home regulatory 89 domain to a different regulatory domain, and it should find available 90 WSDB in target regulatory domain. For example, when a person, named 91 Bob, travels and takes a Wi-Fi AP (could be integrated with laptop 92 PC) with him, if there is a port of wired network, it is easy for him 93 to setup a wireless network for use. But if Bob takes an AP using 94 white space spectrum, it must find an available WSDB in that 95 regulatory domain before setup the wireless network. 97 Several different methods could be used for master device to 98 determine the appropriate URL(s) for connection. Here we list some 99 possible methods for this purpose (not all methods are included 100 here): 102 M1: The manufacture or the user of master device can manually pre- 103 configure statically the URL(s) of one or more WSDBs that is 104 available for master device to query white space spectrum (e.g. 105 master device and WSDB have agreements with each other.). For 106 example, if master device is to be used in U.S., it will be 107 configured with the WSDB of U.S., and then it directly connects to 108 the WSDB in U.S., or if master device is to be used in several 109 countries it can be configured with different WSDBs for each country. 111 M2: Master device might be configured by certain provisioning process 112 after attaching to operator's network. The provisioning process 113 might be DHCP process, OSS process etc. 115 M3: An entity of Listing server [PAWS PROTOCOL], providing the URLs 116 for one or more WSDBs, could be deployed in a regulatory domain, then 117 master device queries and checks available WSDBs from the Listing 118 server. 120 M4: When WSDB, which master device currently connects to, cannot 121 provide service any more, it can redirects the master device to 122 another WSDB that can provide service [PAWS PROTOCOL]. 124 But in some scenarios the methods above may not work very well: 126 (1) To pre-configure master device, the user has to know the 127 available WSDB (s) that can be used in the regulatory domain, it may 128 be inconvenient especially when master device is moved to a different 129 regulatory domain. 131 (2) It is possible that some WSDBs are not available any more or some 132 new WSDBs are setup, the pre-configuring and provisioning method may 133 not cope with it very well. 135 (3) In pre-configuring method, it is possible for master device to be 136 pre-configured with available WSDB of several regulatory domains. 137 But master device must decide which regulatory domain it locates in 138 before choosing the available WSDB. 140 (4) The network provision method might work well only in case of 141 WSDBs are maintained by network operators or there should be some 142 agreement relationship between network operator and WSDB maintainer. 144 (5) In the method that WSDB provides redirecting to the master 145 device, some security related issues have to be considered. It might 146 be feasible for a WSDB to provide master device with URL of another 147 WSDB in the same regulatory domain. But in case when master device 148 moves from regulatory domain A to regulatory domain B, it might seem 149 not right for WSDB of A to provide regulatory domain information and 150 available WSDBs or Listing server of B to the master device, because 151 WSDB and master devices are each certified to operate in certain 152 regulatory domains. 154 At power-up master device does not reliably know the regulatory 155 domain corresponding to its current location, and therefore does not 156 reliably know with which WSDB(s) it can communicate to. Furthermore 157 it is essential that master device connects with a trusted WSDB for 158 proper operation and indeed regulatory compliance. 160 So a dynamic WSDB discovery mechanism is provided here, the mechanism 161 can be used independently or cooperate with other methods, e.g. 162 master device could first connect to the configured or provisioned 163 WSDB, if that fails then the master device can use the dynamic 164 mechanism described in this document to find out available WSDB. 166 The dynamic WSDB discovery mechanism is used by master device to 167 discover available WSDBs for its current location and related 168 regulatory domain information. After master device gets the 169 information about available WSDB and regulatory domain information, 170 it then chooses the proper WSDB for querying white space spectrum 171 using PAWS procedures. 173 The discovery mechanism discussed here will provide master device 174 with two kinds of information: the regulatory domain where the device 175 currently locates and the available list of WSDBs or a Listing server 176 in current domain. 178 The mechanism discussed in this memo will be provided as an OPTIONAL 179 method as described in [PAWS PROTOCOL]. 181 2. Terminology and Conventions 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC2119 [RFC2119]. 187 The terminology from PAWS: problem statement, use cases and 188 requirements RFC6953 [RFC6953] is applicable to this document. 190 Master Device 192 A device that queries the database, on its own behalf and/or on 193 behalf of a slave device, to obtain available spectrum information. 195 White Space Database (WSDB) 197 In the context of white space and cognitive radio technologies, the 198 database is an entity which contains, but is not limited to, current 199 information as required by the regulatory policies about available 200 spectrum at any given location and time, and other types of related 201 (to the white space spectrum) or relevant information. 203 White Space Database Discovery Server (WSDB DS) 205 A server function provided to a white space device, the client. The 206 white space device contacts a WSDB DS to receive the service of 207 discovering or identifying one or more white space databases. 209 RB_server 210 Master device can query its current regulatory body domain 211 information from RB_server. RB_server setup by vendor or by third 212 party. Besides regulatory domain information, RB_server might 213 provide additional information (TBD). 215 LoST 217 LoST (Location-to-Service Translation Protocol)RFC5222 [RFC5222] is 218 an XML-based protocol for mapping service identifiers and geodetic or 219 civic location information to service contact URIs and associated 220 information. 222 3. Solutions 224 Considering of different business models, regulations in different 225 regulatory domain and some existing deployments, in this version of 226 draft, several possible solutions are discussed. 228 [NOTE1: Although several solutions are discussed here, but finally we 229 may only choose the best one.] 231 3.1. Solution 1 233 It's reasonable for the regulatory body to know all the WSDBs 234 deployed in its domain, because when a WSDB is deployed it must get 235 the permission of regulatory body. So it is suitable for each 236 regulatory body to deploy a WSDB DS. 238 In this solution, each regulatory body maintains its own WSDB DS, 239 which records all the WSDBs for the regulatory domain. When master 240 device operates in certain regulatory domain, it gets available WSDB 241 from regulatory domain's WSDB DS. 243 Besides WSDB DS deployed by each regulator body, an entity named 244 RB_Server is also deployed. RB_Server is a server which provides 245 WSDB DS information to master device according to geo-location 246 provided by master device. The DNS domain name or IP address of 247 RB_Server should pre-configured in master device. There are two 248 considerations on how to deploy RB_Server. 250 (a) RB_Server(s) could be setup according to international agreement 251 among various spectrum regulators. In this case a query protocol 252 between master device and RB_Server is needed, and LoST protocol 253 would be an appropriate candidate. RB_Server and WSDB DS act as LoST 254 server and master device acts as LoST client. 256 (b) Absent such an international agreement, each radio vendor would 257 be responsible (under its certification agreement with each 258 regulator) to ensure that its devices operate properly when they are 259 in the geographic territory for which they have been certified, 260 RB_Server could be setup by the vendor of master device, and each 261 vendor's RB_Server provides service to its own master device. 263 An example of deployment is shown in Figure 1. There are three 264 regulatory domains, named A, B and C; one or more WSDBs and one WSDB 265 DS are deployed in each domain. 267 +------------------------------------------------+ 268 | +--------+ | +--------+ | 269 | |Domain A| | |Domain B| | 270 | +--------+ | +--------+ | 271 | +-----+ | | 272 | |WSDB1| +-----+ | +------+ | 273 | +-----+ |WSDB2| | |WSDB 3| | 274 | +-----+ | +---------+ +------+ | 275 | +---------+ | |WSDB DS#B| | 276 | |WSDB DS#A| | +---------+ | 277 | +---------+ | +-------------+ | 278 | | |master device| | 279 | | +--_----------+ | 280 +------------------------'----,'-----------------+ 281 , ' 282 ,' 283 +---------+ 284 |RB_Server| 285 +---------+ 287 Figure 1: Solution 1: Framework of WSDB discovery 289 3.2. Solution 2 291 This solution provides a more flexible WSDB discovery method. In 292 this solution, RB_Server and DNS system are used. 294 It is possible that regulatory bodies get an agreement each one 295 deploys its own WSDB DS, and under such an agreement solution1 would 296 be a good choice for WSDB discovery. But if regulatory bodies cannot 297 reach such an agreement, i.e. not all regulatory bodies would deploy 298 WSDB DS, then solution2 would be a good choice. The framework of 299 WSDB discovery for solution 2 is shown in Figure 2. 301 +------------------------------------------------+ 302 | +--------+ | +--------+ | 303 | |Domain A| | |Domain B| | 304 | +--------+ | +--------+ | 305 | +-----+ | | 306 | |WSDB1| +-----+ | +------+ +------+ | 307 | +-----+ |WSDB2| | |WSDB 4| |WSDB 3| | 308 | +-----+ | +------+ +------+ | 309 | +---------+ | | 310 | |WSDB DS#A| | | 311 | +---------+ | +-------------+ | 312 | | |master device| | 313 | | +--_----+-----+ | 314 +------------------------'----,'-----+-----------+ 315 ,' \ 316 ,' | 317 +---------+ +-+-+ 318 |RB_Server| |DNS| 319 +---------+ +---+ 321 Figure 2: Solution 2: Framework of WSDB discovery 323 The basic WSDB discovery procedure is shown in Figure 3. 325 +--------------------------+ 326 |Step1. master device gets | 327 |DNS domain name of the 328 | 329 |regulator from RB_Server. | 330 +------------|-------------+ 331 | 332 +-------------------V--------------------+ 333 |Step2. master device starts DNS | 334 |procedure using DNS domain name | 335 |retrieved in Step1, and gets DNS domain | 336 |name/IP address of WSDB DS or WSDB. | 337 +-------------------|--------------------+ 338 | 339 | 340 +------------V---------+ +---------------------+ 341 |DNS procedure returns | No |Step3b. master device| 342 |a WSDB DS? |---> |connects to WSDB. | 343 +------------|---------+ +---------------------+ 344 | 345 | Yes 346 +-----------V----------+ 347 |Step3a. master device | 348 |gets WSDB from WSDB | 349 |DS. | 350 +----------------------+ 352 Figure 3: Solution2: Basic WSDB discovery procedure 354 In this solution, NAPTR DNS Resource Record (RR) RFC3403 [RFC3403] is 355 used . Each regulator maintains NAPTR RRs by itself, and every WSDB 356 or WSDB DS has a related NAPTR RR. The service field of NAPTR RR is 357 used to indicate whether the RR is for WSDB or WSDB DS. An example 358 of NAPTR RRs is shown as follows. [NOTE2: If NAPTR RR for WSDB DS 359 exists, then there might be no NAPTR RRs for WSDBs.] 361 A simple NAPTR example: 363 paws.fcc.gov 365 IN NAPTR 100 100 A paws-db '' exam1.company1.com ; DB returned 367 IN NAPTR 100 100 A paws-ds '' exam2.company2.com ; WSDB DS returned 369 IN NAPTR 100 100 A paws-db '' exam3.company3.com ; DB returned 371 There is a bit of difference between RB_Servers in solution 2 and 372 solution 1, in solution 2 RB_Server returns DNS domain name for the 373 regulatory domain, which will be used in the following DNS procedure. 375 3.3. Solution 3 377 In this solution, WSDB DS is deployed independently from regulatory 378 domain (but we don't except regulatory body from deploying their own 379 WSDB DS). WSDB DS maintains WSDBs for regulatory domains or only 380 maintains WSDB DS in case regulator deploys WSDB DS by itself and 381 needs master device get WSDB from its own WSDB DS. The DNS domain 382 name or IP address of such an independent WSDB DS should be pre- 383 configured in master device. An example of deployment is shown in 384 Figure 4. 386 +------------------------------------------------+ 387 | +--------+ | +--------+ | 388 | |Domain A| | |Domain B| | 389 | +--------+ | +--------+ | 390 | +-----+ | | 391 | |WSDB1| +-----+ | +------+ +------+ | 392 | +-----+ |WSDB2| | |WSDB 4| |WSDB 3| | 393 | +-----+ | +------+ +------+ | 394 | +---------+ | | 395 | |WSDB DS#A| | | 396 | +---------+ | +-------------+ | 397 | | |master device| | 398 | | +--_----+-----+ | 399 +------------------------'----,'-----+-----------+ 400 ,' 401 ,' 402 +-------+ 403 |WSDB DS| 404 +-------+ 406 Figure 4: Solution 3: Framework of WSDB discovery 408 There are two considerations on how to deploy independent WSDB DS. 410 (a) WSDB DS could be setup according to international agreement among 411 various spectrum regulators. In this case a query protocol between 412 master device and WSDB DS is needed, and LoST protocol would be an 413 appropriate candidate. Both independent WSDB DS and WSDB DS deployed 414 by regulatory body act as LoST server and master device acts as LoST 415 client. 417 (b) Absent such an international agreement, each radio vendor would 418 be responsible (under its certification agreement with each 419 regulator) to ensure that its devices operate properly when they are 420 in the geographic territory for which they have been certified, WSDB 421 DS could be setup by the vendor of master device, and each vendor's 422 WSDB DS provides service to its own master device. 424 3.4. Solution 4 426 Like solution1, in this solution each regulatory body deploys its own 427 WSDB DS. A LoST service wsdb is defined, which is used to get URL of 428 WSDB, and WSDB DS acts as a server that can provide wsdb service. 429 Master device acts as LoST client. 431 One DHCP extension has been defined in RFC5223 for discovering LoST 432 server, so when master device attaches to operator's network, master 433 device could be provisioned with IP address of an LoST server through 434 DHCP procedure. The LoST server provisioned here might not be the 435 address of WSDB DS, but according to LoST architecture, master device 436 can finally connect to WSDB DS after iterative or recursive 437 procedures. 439 4. Security Considerations 441 TBD. 443 5. IANA Consideration 445 TBD. 447 6. Acknowledgements 449 7. References 451 7.1. Normative references 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 457 Part Three: The Domain Name System (DNS) Database", 458 RFC 3403, October 2002. 460 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 461 Tschofenig, "LoST: A Location-to-Service Translation 462 Protocol", RFC 5222, August 2008. 464 7.2. Informative References 466 [PAWS PROTOCOL] 467 Chen, V., Das, S., Zhu, L., McCann, P., and J. Malyar, 468 "Protocol to Access Spectrum Database", 469 draft-ietf-paws-protocol-07 (work in progress), Dec 2013. 471 [RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to 472 Access White-Space (PAWS) Databases: Use Cases and 473 Requirements", RFC 6953, May 2013. 475 Authors' Addresses 477 Xinpeng Wei 478 Huawei 480 Phone: +86 134 3682 2355 481 Email: weixinpeng@huawei.com 483 Lei Zhu 484 Huawei 486 Phone: +86 139 1015 7020 487 Email: lei.zhu@huawei.com