idnits 2.17.1 draft-probasco-paws-discovery-01.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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group Draft S. Probasco, Ed. 3 Internet-Draft B. Patil 4 Intended status: Informational Nokia 5 Expires: January 17, 2013 July 16, 2012 7 Protocol to Access White Space database: Discovery 8 draft-probasco-paws-discovery-01 10 Abstract 12 A white space master device needs to query a white space database and 13 obtain information about available spectrum/channels prior to 14 operation. White space databases which contain information about 15 available spectrum/channels are associated with a regulatory domain 16 and hence specific to a country or region. A white space master 17 device needs to discover the relevant white space database(s) given 18 its current location and the regulatory domain that it is operating 19 in. The white space database discovery is the preliminary step that 20 a white space master device has to perform. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 17, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Protocol Description . . . . . . . . . . . . . . . . . . . 6 61 4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 White space database discovery is preliminary to creating a radio 75 network using white space. The radio network is created by a master 76 device that must contact a trusted database to learn if any radio 77 frequencies or channels are available for use before the master 78 device transmits in white space spectrum. Discovery is a necessary 79 service for PAWS protocol, see PAWS: problem statement, use cases and 80 requirements [PAWS RQMTS]. 82 +-----------------------+ 83 | collect addresses of | 84 | white space databases | 85 | | 86 +-----------------------+ 87 | 88 | 89 +-----------------------+ 90 | sort multiple | 91 | addresses in priority | 92 | order | 93 +-----------------------+ 94 | 95 repeat as needed | 96 ---------------->| 97 | | 98 | +-----------------------+ 99 | | contact top priority | 100 ---- | database to determine | 101 | suitability for | 102 | service | 103 +-----------------------+ 104 | 105 | 106 end 108 Figure 1: High level view of white space database discovery 110 Figure 1 shows at a high level how white space master devices 111 discover a suitable trusted white space database. In this document 112 we describe how the master device may collect the addresses of one or 113 more white space database. Steps and criteria to sort multiple 114 addresses into a priority order is left to implementation and not 115 specified. Procedures to contact a white space database are 116 specified in (ED NOTE: insert reference to PAWS standard, when 117 available). Steps and criteria to determine the suitability of a 118 particular white space database are left to implementation. 120 2. Terminology 122 The terminology from PAWS: problem statement, use cases and 123 requirements [PAWS RQMTS] is applicable to this document. 125 White Space Database (WSDB) 127 In the context of white space and cognitive radio technologies, 128 the database is an entity which contains, but is not limited to, 129 current information as required by by the regulatory policies 130 about available spectrum at any given location and time, and other 131 types of related (to the white space spectrum) or relevant 132 information. 134 White Space Database Discovery Server (WSDB DS) 136 A server function provided to a white space device, the client. 137 The white space device contacts a white space database discovery 138 server to receive the service of discovering or identifying one or 139 more white space databases. The white space database discovery 140 server is a known entity to the white space device, which knows at 141 least a useable internet address for the white space database 142 discovery server. The white space database discovery server takes 143 as input positioning information from the white space device and 144 returns both address information which allows the white space 145 device to contact a trusted, regulatory-authorized white space 146 database, suitable for service at the white space device's current 147 location and indication of the regulatory domain governing at the 148 white space device's current location. A single white space 149 database discovery server may have global scope, serving clients 150 located globally. 152 3. Overview 154 Before the WSD can query a trusted WSDB for a list of available 155 frequencies or channels for use in the white space spectrum, the WSD 156 must first discover the available databases and addresses serving the 157 regulatory domain in which the device is currently located. At 158 power-up the WSD does not reliably know the regulatory domain 159 corresponding to its current location, and therefore does not 160 reliably know with which white space database(s) it can communicate. 161 Furthermore it is essential that the WSD connect with a trusted WSDB 162 for proper operation and indeed regulatory compliance. By including 163 contact information of a trusted WSDB DS in the WSD's programmed 164 instructions or firmware, the WSD can reliably determine the address 165 of a trusted database or database listing server, as appropriate for 166 its current physical location. 168 While it possible that a WSD knows its location, or information which 169 may be used to derive its location, it is not reasonable for every 170 WSD to be capable to translate this information into the current 171 regulatory domain, i.e. the WSD needs assistance to know what is the 172 regulatory environment with jurisdiction at its current location. A 173 WSDB Discovery Server (DS) takes as input location information from 174 the WSD and returns to the WSD one or more addresses of WSDBs (or 175 WSDB listing servers as appropriate) to the WSD. If the address or 176 addresses of these WSDB DSs are included in the WSD firmware, a 177 secure starting point for a trusted relationship is established. 178 Because the WSDB DS is selected by the WSD manufacturer, a foundation 179 is set to ensure the WSD will be able to discover a trusted WSDB in 180 every regulatory domain where the manufacturer expects the WSD to be 181 used. 183 When the WSD does not have the address of a serviceable WSDB (e.g. at 184 power-up), the WSD sends a Discovery Request message to a WSDB DS. 185 The address of at least one WSDB DS is included in the WSD operating 186 instructions or firmware by the manufacturer for example or 187 provisioned using device configuration mechanisms. The WSD includes 188 in the Discovery Request information about its current location. The 189 WSDB DS uses this location information to determine the regulatory 190 domain where the WSD is located, and returns a Discovery Response 191 message which includes the address of one or more WSDBs (or WSDB 192 listing server as appropriate) to the WSD. See Figure 2. 194 +-----------+ +-----------+ +----------+ 195 | | | WSDB | | | 196 | WSD | | Discovery | | WSDB | 197 | | | Server | | | 198 +-----------+ +-----------+ +----------+ 199 | | | 200 | Discovery Request | | 201 |(location information, etc) | | 202 |--------------------------->| | 203 | | | 204 | Discovery Response | | 205 | (address information, etc) | | 206 |<---------------------------| | 207 | | | 208 | | | 209 | /--------------------------|-----------------------\ | 210 |/ channel request | \| 211 |\ channel response | (PAWS) /| 212 | \--------------------------|-----------------------/ | 213 | | | 214 | | | 216 Figure 2: Example illustration of registration of the discovery 217 process using PAWS: Discovery 219 The discovery procedure fulfills requirements P.1, P.2 and P.3 from 220 PAWS: problem statement, use cases and requirements [PAWS RQMTS]. 222 4. Specification 224 4.1. Protocol Description 226 PAWS: Discovery is an application protocol that uses HTTP/TLS as 227 transport. See Figure 3. 229 +-------------+ 230 | Discovery | 231 +-------------+ 232 | HTTP/TLS | 233 +-------------+ 234 | TCP | 235 +-------------+ 236 | IP | 237 +-------------+ 239 Figure 3: Protocol stack 241 4.2. Protocol Messages 243 The WSD sends Discovery-REQ to the WSDB DS and return receive 244 Discovery-RSP, see Figure 4. 246 Master WSD WSDB DS 247 | | 248 | Discovery-REQ | 249 |------------------------>| 250 | | 251 | Discovery-RSP | 252 |<------------------------| 253 | | 254 | | 256 Figure 4: Discovery message flow 258 1. The Discovery-REQ message contains information to allow the WSDB 259 DS to identify and determine the location of the Master WSD. 261 2. The Discovery-RSP message contains the regulatory domain and 262 either the address of a listing server or the address of one or 263 more WSDB authorized to provide service where the WSD is 264 physically located. If spectrum access is not authorized at the 265 WSD physical location, the response will contain an error code 266 and no address information. 268 4.3. Data Model 270 5. IANA Considerations 272 This document has no requests to IANA. 274 6. Security Considerations 276 The white space database provides a critical service to white space 277 master devices in the form of query responses about available 278 spectrum/channels for use at a specific location and time. The white 279 space database is specific to a regulatory domain. A white space 280 master device querying a database needs to ensure that it is 281 communicating with a valid and authorized entity. The master device 282 performs database discovery prior to establishing a session with a 283 white space database for querying spectrum/channel availability. The 284 database discovery process needs to be secured in order to ensure 285 that the master device is provided with the address of a valid and 286 authorized database for the specific regulatory domain. There is a 287 trust relationship that needs to be established between the master 288 device and the entity which aids it in database discovery. 290 7. Summary and Conclusion 292 White space database discovery is a preliminary step in the process 293 of creating a radio network using white space by devices. A simple 294 and secure means to discover valid and authorized database(s) within 295 the scope of a regulatory domain by a WSD is specified in this 296 document. A trust relationship between the WSD and the WSDB 297 discovery server ensures security w.r.t the list of databases 298 provided to the WSD. 300 8. Acknowledgements 302 The authors would like to acknowledge Brian Rosen, Peter Stanforth 303 and Andy Sago for their comments which have helped improve this 304 document. 306 9. References 308 9.1. Normative References 310 [PAWS RQMTS] 311 IETF, "Protocol to Access White Space database: PS, use 312 cases and rqmts;", December 2012. 314 9.2. Informative References 316 Authors' Addresses 318 Scott Probasco (editor) 319 Nokia 320 6021 Connection drive 321 Irving, TX 75039 322 USA 324 Email: scott.probasco@nokia.com 325 Basavaraj Patil 326 Nokia 327 6021 Connection drive 328 Irving, TX 75039 329 USA 331 Email: basavaraj.patil@nokia.com