idnits 2.17.1 draft-brandt-coap-subnet-discovery-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4796 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-02 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE A. Brandt 3 Internet-Draft Sigma Designs 4 Intended status: Experimental March 7, 2011 5 Expires: September 8, 2011 7 Discovery of CoAP servers across subnets 8 draft-brandt-coap-subnet-discovery-00 10 Abstract 12 The document describes the process of discovering CoAP servers 13 distributed in multiple subnets in a non-specified topology. CoAP 14 Discovery Gateways are used to discover one subnet from another. 15 CoAP Discovery Gateways may provide caching to enable discovery of 16 sleeping nodes in LLN environments. The solution scales to large 17 installations since discovery is handled by the client in an 18 incremental fashion. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Requirements for Discovery services for very constrained 57 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Home Control network evolution - scenarios . . . . . . . . 4 59 2.1.1. Scenario A: Retail home control starter kit . . . . . 4 60 2.1.2. Scenario B: Service provider home control offering . . 5 61 2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Zero-Configuration . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Multiple unique routable subnets . . . . . . . . . . . . . 7 64 3. Building blocks of a CoAP Discovery infrastructure . . . . . . 7 65 3.1. Stand-alone CoAP Server . . . . . . . . . . . . . . . . . 8 66 3.2. CoAP Discovery Gateway . . . . . . . . . . . . . . . . . . 8 67 3.3. Caching CoAP Discovery Gateway . . . . . . . . . . . . . . 8 68 3.4. CoAP Discovery Client . . . . . . . . . . . . . . . . . . 9 69 4. CoAP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 11 71 4.1.1. Topology Path String definitions . . . . . . . . . . . 11 72 4.1.2. ?n=DiscoveryGateway . . . . . . . . . . . . . . . . . 13 73 4.1.3. Discovering Gateway interfaces - an example . . . . . 13 74 4.2. Initial Topology Discovery . . . . . . . . . . . . . . . . 13 75 4.3. Incremental Topology Discovery . . . . . . . . . . . . . . 14 76 4.3.1. Multicast domain behind routers . . . . . . . . . . . 14 77 4.4. CoAP Server Discovery . . . . . . . . . . . . . . . . . . 15 78 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.1. Discovery across CoAP Discovery Gateways . . . . . . . . . 15 80 5.2. /topology path formats . . . . . . . . . . . . . . . . . . 17 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 87 A.1. Large reports . . . . . . . . . . . . . . . . . . . . . . 20 88 A.2. M2M Filtering . . . . . . . . . . . . . . . . . . . . . . 20 89 A.3. Routable subnets . . . . . . . . . . . . . . . . . . . . . 21 90 A.4. Compressing responses from caching CoAP Discovery 91 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 A.5. Integrated Battery support . . . . . . . . . . . . . . . . 21 93 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 This document describes the process of discovering CoAP servers 99 distributed in multiple subnets in a non-specified topology. CoAP 100 (Constrained object Application Protocol) Discovery Gateways are used 101 to discover one subnet from another. CoAP Discovery Gateways may 102 provide caching to enable discovery of sleeping nodes in Low-power 103 and Lossy Network (LLN) environments. Caching CoAP Discovery 104 Gateways may also have the purpose of preserving bandwidth in an LLN 105 environment. No synchronization of databases is required. The 106 solution scales to large installations since discovery is handled by 107 the client in an incremental fashion. 109 CoAP servers may be running on a variety of physical layers; each 110 implementing a subnet. A lamp module may be running over IEEE 111 802.15.4. A movement sensor may be running over Z-Wave. 113 The document presents requirements to a home control discovery 114 solution and proposes a solution based on the CoAP link format 115 [I-D.ietf-core-link-format]. 117 CoAP Subnet Discovery Must support IPv6. An implementation MAY 118 implement support for both IPv4 and IPv6 . 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Requirements for Discovery services for very constrained nodes 128 The term constrained node covers a range of nodes that are 129 constrained with regards to memory size, power consumption, packet 130 size or CPU capabilities. This document covers nodes for 131 applications within home control and building control. A Low-power 132 Lossy Network (LLN) is used for communication. 134 The basic functionality of devices for home control and building 135 control is the same: measure temperature, detect movement, dim light, 136 operate locks, etc. The discovery, management and operation of 137 networks is however somewhat different. This document addresses 138 discovery requirements specific to the most constrained devices and 139 outlines how proper solutions may address home control and building 140 control technologies in the same way. 142 2.1. Home Control network evolution - scenarios 144 Home control systems may be constructed from consumer products 145 acquired in a retail store. The products may come from multiple 146 vendors. The user may have no knowledge of network management. The 147 user may have no existing local network. If there is a local 148 network, it may have no DHCP or DNS infrastructure. Devices must 149 always work; the consumer price level does not leave much margin for 150 support hotlines. 152 The following scenarios assume one common application protocol. 153 Multi-protocol support may be achieved via application gateways; 154 potentially with CoAP as the common language. This is out of scope 155 of this document. 157 2.1.1. Scenario A: Retail home control starter kit 159 This scenario outlines how LLN nodes may be used in the most simple 160 network configurations and how such simple networks may grow from 161 there. In such simple networks the 6LoWPAN border router is reduced 162 to a conceptual function. The remote control acts as a coordinating 163 master node on the link layer as well as a 6LoWPAN border router. 164 The remote control enters a sleep state when it is not in use. 166 1. Starter kit bring-up 168 A user starts with an RF remote control and three RF plug-in 169 modules. The remote control assigns unique link-layer addresses 170 and ULA IP addresses [RFC4193] to modules during network 171 bootstrapping so that the remote control and the plug-in modules 172 are in the same IP network. ULA IP addresses are needed as 173 multi-hop routing may be used inside the LLN network. 174 Prefixes and header compression CIDs have infinite lifetime as 175 there is no listening border router. 177 Remote control buttons are mapped to (groups of) IP addresses of 178 the plug-in modules. The setup mode may be activated via a 179 special key sequence in the remote control. 181 2. Adding sensors 183 The user adds another plug-in module and a movement sensor to the 184 network. The remote control is still used as a coordinating 185 master node. The IP address of the target module is stored in 186 the movement sensor. When the sensor detects a movement, it 187 sends an "ON" command to the plug-in module. 189 3. Adding home control to the smart phone 191 The user adds a border router to interface the LLN network to the 192 LAN (and WiFi) of the house. 193 The user connects a smartphone to the WiFi network. A home 194 control smartphone app performs home control resource discovery. 195 A list of LLN nodes allows the user to configure smartphone 196 widgets for scene control of lamps; e.g. "Watch TV" or "Doing 197 the dishes". 199 2.1.2. Scenario B: Service provider home control offering 201 In this scenario, a consumer receives a pre-bundled kit from a 202 service provider: 204 o A combined internet access router and LLN border router with WiFi 205 support 207 o Three plug-in modules for installation in the home 209 o A personal web profile on the service provider web portal 211 o A smartphone app for control via WiFi 213 Remote access credentials, LLN prefix and other parameters are 214 preconfigured by the service provider. 216 1. Setting up the kit 218 The LLN border router manages link-layer node properties as well 219 as prefix assignment, etc. A web page is used to add the three 220 plug-in modules to the LLN. The smartphone app controls the 221 plug-in modules via WiFi. Routable addresses allow the app to 222 reach the modules from the WiFi subnet. 224 2. Adding other technologies 226 The original starter kit was a wireless LLN. The user connects a 227 power-line LLN border router to the LAN, thus forming a backbone 228 network for the two LLN border routers. The user includes power- 229 line based plug-in modules with the new power-line LLN border 230 router. 231 Each individual border router manages local ULA prefixes and 232 header compression CIDs. 234 3. Re-discovering the network 236 The smartphone app rediscovers home control resources in both 237 LLNs and the backbone network. The lists of home control 238 resources allow the user to configure smartphone widgets for 239 scene control of lamps in both subnets. 240 The border routers runs a routing protocol on the backbone to 241 allow IP packets to traverse from one subnet into the other 242 without any manual configuration of routers. 244 2.2. Discovery 246 Discovery serves multiple purposes in a home control network: 248 1. When the home control network has grown from the original starter 249 kit to a substantial number of nodes, the owner may get a desire 250 for centralized management of the network. The management tool 251 needs a way to request information from each node in the network. 252 Typically, nodes will carry no visible identification at this 253 time. If possible, non-functioning nodes should also be 254 identified. Once nodes are identified, the user may locate the 255 nodes physically and assign naming and location information, e.g. 256 "bedroom, ceiling light" or "living room, drapes". 258 2. When setting up a remote control, the user may want to browse all 259 drape controllers in the entire network - both in the wireless 260 LLN and in the powerline LLN. The wireless drape controllers may 261 be battery powered and sleeping most of the time. The powerline 262 drape controllers may be in a dedicated powerline LLN subnet 263 behind several border routers. It is a challenge to discover 264 nodes in other subnets. A multicast-based discovery protocol 265 like mDNS cannot have its messages forwarded by routers since it 266 uses link-local addressing. Even if mDNS messages could be 267 forwarded, some LLNs featuring multi-hop routing do only support 268 multicast in a very slow and inefficient fashion. Assuming 269 multicast messages could be distributed over a LLN, sleeping 270 nodes would not be able to detect discovery requests. 272 A solution is required which 274 o Does not flood the LLN with unnecessary discovery traffic 276 o Does not require multicasting in LLNs 278 o Does allow the discovery of sleeping nodes 280 2.3. Zero-Configuration 282 One major property of home control networks is the absence of a 283 professional installer. When making consumer products, one cannot 284 make any assumptions about the qualifications of the user. Simple 285 operation is a requirement. As an example, a user may associate a 286 light module by activating a setup sequence on a wall switch and then 287 pushing a button on the light module. The user never sees any data. 288 Most users actually do not care about the IP address of the light 289 module. 291 No border router, DHCP server or DNS server is present in a starter 292 kit network. Modules that were initially purchased and configured 293 with a remote control may one day be used in a far more advanced 294 installation with global routable prefixes and hierarchical DNS 295 naming. 297 2.4. Multiple unique routable subnets 299 Home control domains may be composed of devices communicating via one 300 or more border routers, e.g power-line to wireless, optionally via a 301 backbone network. A wireless home control LLN may in itself contain 302 routers to do multihop forwarding within the home control LLN. The 303 two subnets may host different MAC/PHYs as well as different routing 304 protocols. The user can extend the home control starter kit with 305 another subnet without having to re-install the original subnet. The 306 construction of unique local subnet prefixes is described 307 in[RFC4193]. 309 3. Building blocks of a CoAP Discovery infrastructure 311 CoAP defines a protocol for exchange of requests and commands between 312 constrained nodes. Already described in [I-D.ietf-core-coap], the 313 CoAP Server is a host capable of responding to CoAP messages. CoAP 314 Servers may be classified into the following sub-types: 316 o Stand-alone CoAP Server 318 o CoAP Discovery Gateway 320 o Caching CoAP Discovery Gateway 322 These are described in the following sections. Finally, the CoAP 323 Discovery Client is described. 325 CoAP Discovery Gateways MAY advertise legacy devices along with 326 native CoAP servers. CoAP Discovery Gateways MAY provide access to 327 legacy services via CoAP request and control messages. Discovery of 328 diverse resource types enables a migration path from legacy 329 technologies towards an all-CoAP infrastructure. 331 3.1. Stand-alone CoAP Server 333 A stand-alone CoAP Server does not provide access to other CoAP 334 Servers; physical or logical. Typically a stand-alone CoAP Server is 335 able to perform some action, e.g. measuring a temperature or turning 336 on light. 337 A CoAP Server reports periodically to the Discovery Gateway via the 338 6LoWPAN ND address registration process, e.g. once every hour. 339 Battery operated CoAP servers may run out of battery. Light modules 340 may become defect. The reporting allows the Discovery gateway to 341 monitor the availability of CoAP Servers. 343 3.2. CoAP Discovery Gateway 345 A CoAP Discovery Gateway is a CoAP enabled router interconnecting 346 different subnets, e.g. a LLN Border Router. The subnets may host 347 stand-alone CoAP Servers as well as other CoAP Discovery Gateways. 348 Each CoAP Discovery Gateway interface MUST respond to the CoAP 349 Discovery request "GET /.well-known/core?n=DiscoveryGateway". When 350 queried, the gateway MUST report all other interfaces maintained by 351 the discovery gateway. 353 The Discovery Gateway MAY maintain a list of CoAP Servers that 354 recently stopped sending address registrations. How a CoAP Discovery 355 Gateway is to advertize such CoAP Servers is TBD. 357 3.3. Caching CoAP Discovery Gateway 359 A Caching CoAP Discovery Gateway performs caching of discovery 360 information on behalf of other nodes in a given subnet. A discovery 361 gateway interface MUST respond to the CoAP Discovery request "GET 362 /.well-known/core?n=DiscoveryGateway". When queried, the discovery 363 gateway MUST report all other interfaces maintained by the discovery 364 gateway. The gateway MUST indicate if respective interfaces are of 365 the type "CoAP Discovery Gateway" or "Caching CoAP Discovery 366 Gateway". This information MAY be be ignored by a discovery client. 368 CoAP Servers reporting to a Caching CoAP Discovery Gateway MAY 369 respond to CoAP Discovery requests. A Caching CoAP Discovery Gateway 370 MUST intercept discovery requests and respond on behalf of CoAP 371 Servers. This allows sleeping nodes to be discovered, saves LLN 372 bandwidth and allows the Caching CoAP Discovery Gateway to maintain 373 connectivity state information like "online/offline/unstable" per 374 CoAP server. 376 The Caching CoAP Discovery Gateway MAY maintain a list of CoAP 377 Servers that recently stopped sending address registrations. How a 378 CoAP Discovery Gateway is to advertize such CoAP Servers is TBD. 380 +--------------------------------+ 381 | Caching CoAP Discovery Gateway | 382 | | 383 +---------------------+ +---------------------+ 384 |Caching Interface | |non-caching Interface|- - + 385 |2001:1001::1 | |2001:1002::1 | 386 +---------------------+ +---------------------+ | 387 | | 388 +--------------------------------+ | 389 other 390 CoAP Servers 391 in this subnet 393 Figure 1: Caching CoAP Discovery Gateway 395 A Caching CoAP Discovery Gateway MAY report that it is a (non- 396 caching) CoAP Discovery Gateway on some interfaces; refer to 397 Section 3.2 . 399 The device type "Caching CoAP Discovery Gateway" only indicates that 400 discovery information is cached. Caching of real-time data from CoAP 401 servers is out of scope of this document. 403 A Caching CoAP Discovery Gateway SHOULD NOT interfere with any other 404 traffic than Discovery Requests for Discovery Gateways or the 405 capabilities of CoAP Servers which report to the CoAP Discovery 406 Gateway, e.g. "Device type = Thermostat". A Caching CoAP Discovery 407 Gateway MUST NOT cache any changing parameters. 409 3.4. CoAP Discovery Client 411 A CoAP Discovery Client uses the CoAP Discovery request "GET /.well- 412 known/core?n=DiscoveryGateway" to initiate a discovery session. The 413 target for the discovery request depends on the properties of the 414 actual network. Two cases apply: 416 1. Client is in a LLN domain with no multicast support 418 The initial request is sent to the Authoritative Border Router of 419 that LLN. 421 2. Client is in a link-local subnet domain with multicast support 422 (like Ethernet) 424 The initial request is transmitted to the link-local "all- 425 routers" multicast address. 427 If discovery requests cause CoAP Discovery Gateways to announce other 428 CoAP Discovery Gateways in other subnets, additional discovery 429 requests are directed to those CoAP Discovery Gateways. 431 A Discovery Client may run in remote controls, smart phone apps or 432 central management systems for home automation or building control. 434 The discovery process depends on the presence of a CoAP discovery 435 gateway in the subnet of the discovery client. Since CoAP subnet 436 discovery uses normal CoAP messages, link-local discovery works "out 437 of the box" in link-local enabled environments. Refer to 438 [I-D.ietf-core-link-format]. 440 4. CoAP Discovery 442 CoAP Discovery is a hierarchical process and involves two phases: 443 CoAP Topology Discovery and CoAP Server Discovery. 445 The purpose of the Topology Discovery phase is to establish a 446 snapshot of the available CoAP Discovery Gateways. 448 CoAP messages are used to discover CoAP Discovery Gateways in a 449 hierarchical fashion. Having completed the topology discovery phase, 450 a CoAP client may initiate discovery of particular CoAP server 451 resources, e.g. light dimmers, or a more general wildcard discovery 452 may be done by the client; building a complete database. The same 453 request MUST be sent to each discovered CoAP Discovery Gateway 454 interface in a sequential fashion. 456 The information may be presented, e.g. in lists of different device 457 types. CoAP subnet discovery enables access to end nodes in multiple 458 subnets without any manual configuration of routers. The topology 459 discovery process may return information on Caching CoAP Discovery 460 Gateways. Caching CoAP Discovery Gateways allow the discovery of 461 sleeping and defective nodes but require that CoAP clients implement 462 6lowPAN-ND address registration [I-D.ietf-6lowpan-nd]with the 463 Authoritative Border Router. Management and naming related issues of 464 CoAP servers in building control are discussed in 465 [I-D.vanderstok-core-bc]. 467 CoAP Discovery depends on the ability to traverse subnets. Thus, all 468 CoAP Servers MUST have routable IPv6 addresses; either in global 469 prefixes or according to ULA principles. The border router is 470 typically the physical device implementing the CoAP Discovery Gateway 471 function in a LLN. This specification collapses the address of the 472 default gateway (border router) and the discovery gateway in order to 473 limit the number of IP addresses that LLN nodes have to manage - and 474 to avoid having to distribute the address of the CoAP Discovery 475 Gateway in LLNs. RAs already convey the IP address of the default 476 gateway. 478 4.1. Topology Discovery 480 A client may be anywhere in the topology when initiating the Topology 481 Discovery. Any topology may be traversed (if allowed by firewall 482 policies in border routers). 484 The discovery process allows a client to discover CoAP servers 485 according to the classification described in Section 3. 487 4.1.1. Topology Path String definitions 489 A CoAP Discovery Gateway or caching CoAP Discovery Gateway MUST 490 support the following CoAP messages: 492 o GET /.well-known/core?n=DiscoveryGateway 494 o GET /.well-known/core/topology 496 o GET /.well-known/core/topology/device 498 o GET /.well-known/core/topology/interfaces 500 o GET /.well-known/core/topology/servers 502 4.1.1.1. /topology/device 504 A CoAP Discovery Gateway MUST report one of the device types listed 505 in Figure 2. 506 +----------+---------------------+----------------------------------+ 507 | Device | Label | Interpretation | 508 | type | | | 509 +----------+---------------------+----------------------------------+ 510 | 1 | Discovery Gateway | This is a CoAP Discovery Gateway | 511 | | | interface | 512 | 2 | Discovery Gateway, | This CoAP Discovery Gateway | 513 | | caching | interface is caching | 514 +----------+---------------------+----------------------------------+ 516 Figure 2: CoAP Discovery Device Types 518 The report formats are described in the following sections. 520 4.1.1.2. /topology/interfaces 522 A CoAP Discovery Gateway MUST return the structure 524 [interface address_1] 525 ... 526 [interface address_n] 528 in response to a query for /topology/interfaces. 530 The processing of a discovery request depends on the receiving 531 interface: 533 If the request is targeting the gateway interface that physically 534 received the request, the response contains all subnet interfaces of 535 the discovery gateway. 537 If the request is targeting another gateway interface than the 538 gateway interface that physically received the request, the response 539 contains all discovery gateways known to the subnet of the targeted 540 interface. 542 4.1.1.3. /topology/servers 544 A Caching CoAP Discovery Gateway MUST return the structure 546 [server address_1] 547 ... 548 [server address_n] 550 in response to a query for /topology/servers. 552 If the request is targeting the gateway interface that physically 553 received the request, the response contains the identity of known 554 CoAP Servers that report to this Caching CoAP Discovery Gateway 555 interface. 557 If the request is targeting another gateway interface than the 558 gateway interface that physically received the request, a (non- 559 caching) CoAP Discovery Gateway interface in a subnet supporting 560 multicast MUST issue a multicast request for all CoAP Servers in 561 response to a query for /topology/servers. The individual CoAP 562 Server responses are returned directly to the requesting discovery 563 Client. 565 4.1.2. ?n=DiscoveryGateway 567 A CoAP Discovery Gateway MUST report the path /topology in response 568 to ?n=DiscoveryGateway. A CoAP Discovery Gateway MAY report other 569 paths as well. 571 4.1.3. Discovering Gateway interfaces - an example 573 The query string ?n=DiscoveryGateway is used for discovering topology 574 information in a CoAP enabled infrastructure. 575 [Client sends multicast request to WiFi subnet] 576 | CoAP GET /.well-known/core?n=DiscoveryGateway 578 [LLN Border Router responds] 579 | 200 OK 580 | 581 | core://2001:.../topology/device;ct=0;n="DiscoveryGateway" 583 [Client sends unicast request to the responding CoAP Discovery Gateway] 584 [(LLN border router)] 585 | CoAP GET /.well-known/core/topology/interfaces 587 [LLN Border Router responds] 588 | 200 OK 589 | 590 | 2001:0db8:85a3:beef:0000:8a2e:0370:7334 591 | 2001:0db8:85a3:babe:0000:8a2e:0370:4321 593 It is seen that the initial Discovery Gateway request only returns a 594 single string: "/topology/device/...". Since the path "/topology/ 595 interfaces" is mandatory for CoAP Discovery Gateways, the client may 596 request this structure as soon as it has detected the CoAP Discovery 597 Gateway. 599 4.2. Initial Topology Discovery 601 A Topology Discovery operation is initiated by a CoAP client with the 602 CoAP message GET /.well-known/core?n=DiscoveryGateway in one of the 603 following ways. 605 1. If a client resides in a multicast enabled environment (like 606 Ethernet or WiFi) the client issues a multicast message (as 607 described in [I-D.ietf-core-link-format] ) to the "all nodes" 608 address. All on-link CoAP Discovery Gateways MUST respond to the 609 GET message by returning a list of other interfaces of the 610 respective CoAP Discovery Gateways. In order to avoid 611 collisions, the responding CoAP Discovery Gateways MUST insert a 612 0..MAX_RA_DELAY_TIME [I-D.ietf-6lowpan-nd] random delay before 613 responding. 615 2. If a discovery client resides in a LLN environment (like IEEE 616 802.15.4 or Z-Wave) the client issues a unicast message to the 617 border router of the LLN. The default border router of the LLN 618 MUST respond to a CoAP Discovery request by returning a list of 619 other interfaces of that particular CoAP Discovery Gateway. 621 The discovery client builds a list of reported subnets that it has to 622 discover. Duplicates MUST be omitted. 624 4.3. Incremental Topology Discovery 626 The client holds a list of reported discovery gateway subnets that it 627 has to discover; either from the Initial Topology Discovery or from a 628 previous Topology Discovery. 630 For each subnet interface, the client sends a unicast GET /.well- 631 known/core?n=DiscoveryGateway message to the interface. In its 632 default configuration, a CoAP Discovery Gateway MUST return the 633 address of each remote interface. A CoAP Discovery Gateway MAY be 634 configured to return URIs for identification. CoAP Discovery MUST 635 support zero-configuration environments like home control where no 636 DNS server can be assumed. 638 4.3.1. Multicast domain behind routers 640 If a discovery client initiates discovery from a LLN environment, it 641 may reach a backbone router interface residing in a multicast enabled 642 network domain such as Ethernet. When a CoAP Discovery Gateway 643 receives a unicast discovery request for a multicast enabled network 644 interface via another discovery gateway interface, that CoAP 645 Discovery Gateway interface MUST forward the discovery request in a 646 multicast message for the "all nodes" multicast address. 648 The discovery client MUST ignore a reported Discovery Gateway 649 interface if that interface is already in the list of known Discovery 650 Gateway interfaces. This is to prevent loops. 652 A discovery client MAY perform hierarchical discovery by using the 653 general /.well-known/core path. This combines the topology and 654 server discovery phases. The downside is that a client may receive 655 large amounts of data for each individual discovery message. This 656 may be a problem for memory constrained nodes. By discovering the 657 gateway topology first and using filtered server discovery, a client 658 may achieve significant reductions in received data. 660 4.4. CoAP Server Discovery 662 CoAP Server Discovery builds on network information revealed during 663 topology discovery. Each discovered subnet must be discovered 664 individually. As an example, if a client connected to a backbone has 665 discovered two LLNs behind two border routers, the client must 666 perform CoAP Server discovery in the backbone (on-link subnet) as 667 well as each of the two LLN interfaces. 669 5. Examples 671 5.1. Discovery across CoAP Discovery Gateways 673 Consider the following network environment: The client is located in 674 LAN2. The discovery process has to traverse CoAP Discovery Gateway 675 GW4 and LAN1 to locate CoAP Discovery Gateways GW1, GW2 and GW3. 676 CoAP Discovery Gateways 1, 2 and 3 also have to be traversed. When 677 no more new CoAP Discovery Gateways are discovered, discovery for 678 CoAP Servers can be initiated. 680 +-------+ 681 A, B --- PAN1| GW1 |LAN1 -+ 682 PAN1 +-------+ | 683 | 684 +-------+ | +-------+ 685 C, D --- PAN2| GW2 |LAN1 -+- LAN1| GW4 |LAN2 --- LAN2 686 PAN2 +-------+ | +-------+ client 687 | 688 +-------+ | 689 E, F --- PAN3| GW3 |LAN1 -+ 690 PAN3 +-------+ 692 Figure 3: Discovery across CoAP Discovery Gateways 694 Client | GW4 | GW1 | GW2 | GW3 695 LAN2 | LAN2 LAN1 | LAN1 PAN1 | LAN1 PAN2 | LAN1 PAN3 696 | | | | 697 1) ------X GET ?n=DiscoveryGateway (mcast) 698 | | | | 699 2) <------ "GW4LAN1" 700 | | | | 701 3) --------------> GET ?n=DiscoveryGateway 702 | | | | 703 4) -------X-------------X-------------X GET (mcast) 704 | | | | 705 5) <-------------------- "GW1PAN1" ^ 706 | | | | 0..2s | 707 <---------------------------------- "GW2PAN2" | 708 | | | | | 709 <------------------------------------------------ "GW3PAN3" v 710 | | | | 711 6) ----------------------------> GET ?n=DiscoveryGateway 712 | | | | 713 7) <---------------------------- "" 714 | | | | 715 8) ------------------------------------------> GET ?n=Disco... 716 | | | | 717 9) <------------------------------------------ "" 718 | | | | 719 10) ---------------------------------------------------------> GET 720 | | | | 721 11) <--------------------------------------------------------- "" 723 Figure 4: CoAP Discovery Process 725 1. The client sends out a multicast "GET /.well-known/ 726 core?n=DiscoveryGateway" 728 2. GW4 reports its other interfaces (GW4LAN1). 730 3. The client sends "GET /.well-known/core?n=DiscoveryGateway" to 731 GW4LAN1 733 4. GW4LAN1 is not caching and received request in unicast => "GET 734 /.well-known/core?n=DiscoveryGateway" is forwarded as multicast 736 5. Reports received from GW1LAN1, GW2LAN1 and GW3LAN1 within 2 737 seconds. 739 6. The client sends "GET /.well-known/core?n=DiscoveryGateway" to 740 GW1PAN1 742 7. GW1PAN1 reports that no other gateways were found in PAN1 744 8. The client sends "GET /.well-known/core?n=DiscoveryGateway" to 745 GW2PAN2 747 9. GW1PAN1 reports that no other gateways were found in PAN2 749 10. The client sends "GET /.well-known/core?n=DiscoveryGateway" to 750 GW3PAN3 752 11. GW1PAN1 reports that no other gateways were found in PAN3 754 The client now has the following list of CoAP Discovery Gateway 755 interfaces in unique subnets: 757 1. (mcast in on-link subnet) 759 2. GW4LAN1 761 3. GW1PAN1 763 4. GW2PAN2 765 5. GW3PAN3 767 The client may now issue searches for other CoAP Servers by sending 768 the request "GET /.well-known/core" to each CoAP Discovery Gateway in 769 the list. 771 5.2. /topology path formats 773 Figure 5 shows an example of a client sending a request for /.well- 774 known/core/topology?n=DiscoveryGateway. The discovery gateway sends 775 back a response with the matching resources in the payload. 776 DISCOVERY 777 CLIENT GATEWAY 778 | | 779 |--CON+GET /.well-known/core?n=DiscoveryGateway [TID=42]-->| 780 | | 781 | <----- ACK + 200 OK [TID=42, CT=0] ------ | 782 Payload: 783 ;sh="/??";ct=0;n="DiscoveryGateway" 785 Figure 5: Looking for CoAP Discovery Gateways 787 Figure 6 shows an example of a client sending a request for /.well- 788 known/core/topology/interfaces. The discovery gateway sends back a 789 response with the actual interfaces provided by the CoAP Discovery 790 Gateway. A CoAP Discovery Gateway MUST implement the path /topology/ 791 interfaces. 792 DISCOVERY 793 CLIENT GATEWAY 794 | | 795 |--CON+GET /.well-known/core/topology/interfaces[TID=44]-->| 796 | | 797 | <----- ACK + 200 OK [TID=44, CT=0] ------ | 798 Payload: 799 2001:0db8:85a3:beef:0000:8a2e:0370:7334 800 2001:0db8:85a3:babe:0000:8a2e:0370:4321 802 Figure 6: Using the "/topology/interfaces" path 804 Figure 7 shows an example of a client sending a request for /.well- 805 known/core/topology/interfaces to a caching CoAP Discovery Gateway. 806 The discovery gateway sends back a response with the actual 807 interfaces provided by the CoAP Discovery Gateway. 809 Subsequently, the client may sending a request for /.well-known/core/ 810 topology/servers to get a list CoAP servers known by the Caching CoAP 811 Discovery Gateway. This list includes sleeping and FLN nodes. 812 DISCOVERY 813 CLIENT GATEWAY 814 | | 815 |--CON+GET /.well-known/core/topology/interfaces[TID=45]-->| 816 | | 817 | <----- ACK + 200 OK [TID=45, CT=0] ------ | 818 Payload: 819 2001:0db8:85a3:beef:0000:8a2e:0370:7334 821 Figure 7: Receiving addresses from a caching CoAP Discovery Gateway 823 Figure 8 shows an example of a client sending a request for /.well- 824 known/core/topology/servers to a caching CoAP Discovery Gateway. The 825 discovery gateway sends back a response with the CoAP Servers known 826 by the Caching CoAP Discovery Gateway. 828 In this case the Caching CoAP Discovery Gateway reports legacy 829 devices which do not necessarily speak CoAP. The client may need to 830 implement multiprotocol support in order to communicate to the 831 devices. 833 DISCOVERY 834 CLIENT GATEWAY 835 | | 836 |--CON+GET /.well-known/core/topology/servers[TID=46]-->| 837 | | 838 | <----- ACK + 200 OK [TID=46, CT=0] ------ | 839 Payload: 840 841 843 Figure 8: Advertising legacy devices via CoAP Discovery 845 A more advanced CoAP application gateway may provide translation 846 between legacy protocols and CoAP. This is out of scope of this 847 document. 849 6. IANA Considerations 851 This document has no actions for IANA. 853 7. Security Considerations 855 If a CoAP Discovery Gateway receives a generalized CoAP GET /.well- 856 known/core message and that interface resides in a multicast enabled 857 environment such as Ethernet, the CoAP Discovery Gateway forwards 858 that CoAP request in an "all nodes" multicast message. In response, 859 the CoAP Discovery Gateway potentially receives messages from a 860 number of CoAP Discovery Gateways connected to that link. Forwarding 861 all responses back to the requesting client in individual messages 862 MAY be used for an amplification attack. 864 Coap discovery is not intended for Internet-wide operation. An 865 internet access router SHOULD NOT forward CoAP messages to or from 866 the Internet domain unless there is a specific application need for 867 doing so. CoAP Discovery depends on a secure perimeter. So does 868 many of the LLN nodes which this discovery mechanism is targeting. 870 Triggering an amplification attack requires that an attacker has 871 access to the LAN or has control over LLN nodes. If the LLN 872 implements link-layer security, an attacker cannot simply inject a 873 wireless packet. If, however, one is within radio range of a LLN, a 874 modified microwave oven may be a more efficient jamming tool than an 875 amplification attack. 877 8. References 878 8.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, March 1997. 883 [RFC4193] "Unique Local IPv6 Unicast Addresses", October 2005. 885 8.2. Informative References 887 [I-D.ietf-core-coap] 888 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 889 "Constrained Application Protocol (CoAP)", 890 draft-ietf-core-coap-04 (work in progress), January 2011. 892 [I-D.ietf-core-link-format] 893 Shelby, Z., "CoRE Link Format", 894 draft-ietf-core-link-format-02 (work in progress), 895 December 2010. 897 [I-D.vanderstok-core-bc] 898 Stok, P. and K. Lynn, "CoAP Utilization for Building 899 Control", draft-vanderstok-core-bc-02 (work in progress), 900 October 2010. 902 [I-D.ietf-6lowpan-nd] 903 Shelby, Z., "Neighbor Discovery Optimization for Low-power 904 and Lossy Networks". 906 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 907 January 1997. 909 Appendix A. Open Issues 911 A.1. Large reports 913 The CoAP Block transfer mode MUST be implemented in order to support 914 large reports, e.g. from a caching CoAP Discovery Gateway responding 915 on behalf of 100's of CoAP Servers in an LLN. 917 A.2. M2M Filtering 919 The document describes the use of ?n=DiscoveryGateway for detecting 920 CoAP Discovery Gateways. 922 It should be considered if dedicated codes or keywords should be 923 assigned. M2M applications will benefit from shorter codes and avoid 924 the ambiguity of the free text allowed for '?n='. 926 A.3. Routable subnets 928 CoAP Discovery requires that all CoAP subnets are all reachable from 929 a given subnet. Some application spaces, e.g. DIY home control, may 930 be set up as off-the-shelf boxes with auto-assigned IPv6 subnets 931 [RFC4193] with no route entries to other subnets. 933 RIPng [RFC2080] is considered sufficient for a home control 934 application space. Larger installations for building control and the 935 like are expected to be managed networks. 937 The following requirements could ensure successful plug-and-play 938 behavior when combining Border Routers with CoAP Discovery Gateways 939 from different vendors: 941 o A CoAP Discovery Gateway MUST support RIPng 943 o RIPng SHOULD be enabled in all CoAP Discovery Gateways 945 o A CoAP Discovery Gateway MAY implement other routing protocols 947 A.4. Compressing responses from caching CoAP Discovery Gateways 949 A caching CoAP Discovery Gateway SHOULD omit leading bytes of each 950 reported address if the addresses are all in the same subnet served 951 by the CoAP Discovery Gateway. If omitting leading bytes, a 952 responding CoAP Discovery Gateway MUST provide the prefix information 953 that was omitted from the reported addresses. 955 If no prefix is specified the interface identifiers MUST be full IP 956 addresses or URIs. 958 A Caching CoAP Discovery Gateway MAY return more than one response 959 message. If compression is used all addresses in a response message 960 MUST belong to the same subnet prefix. 962 A.5. Integrated Battery support 964 A caching CoAP Discovery Gateway MAY be integrated into a LLN border 965 router. This allows for tight integration of support services for 966 sleeping nodes. 968 The Caching CoAP Discovery Server allows sleeping nodes to be 969 discovered. The border router may implement mailbox delivery 970 services for sleeping nodes. The border router may return 971 "Destination Responding Slowly" ICMP messages to IP hosts sending to 972 a sleeping node. The purpose of the ICMP message is to prevent IP 973 applications from resending messages because they are not receiving 974 application acks. 976 A distributed routing protocol MAY distribute the mailbox services. 977 This is out of scope of this specification. 979 Appendix B. Acknowledgements 981 Special thanks to Klaus Hartke, Peter Bigot, Peter van der Stok, 982 Kerry Lynn and Zach Shelby for substantial contributions to the ideas 983 and text in the document. 985 Author's Address 987 Anders Brandt 988 Sigma Designs 989 Emdrupvej 26A, 1. 990 Copenhagen O DK-2100 991 DENMARK 993 Phone: +4529609501 994 Email: abr@sdesigns.dk