CoRE                                                           A. Brandt
Internet-Draft                                             Sigma Designs
Intended status: Experimental                              March 7, 2011
Expires: September 8, 2011


                Discovery of CoAP servers across subnets
                 draft-brandt-coap-subnet-discovery-00

Abstract

   The document describes the process of discovering CoAP servers
   distributed in multiple subnets in a non-specified topology.  CoAP
   Discovery Gateways are used to discover one subnet from another.
   CoAP Discovery Gateways may provide caching to enable discovery of
   sleeping nodes in LLN environments.  The solution scales to large
   installations since discovery is handled by the client in an
   incremental fashion.

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 September 8, 2011.

Copyright Notice

   Copyright (c) 2011 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



Brandt                  Expires September 8, 2011               [Page 1]


Internet-Draft            CoAP Subnet Discovery               March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Requirements for Discovery services for very constrained
       nodes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Home Control network evolution - scenarios . . . . . . . .  4
       2.1.1.  Scenario A: Retail home control starter kit  . . . . .  4
       2.1.2.  Scenario B: Service provider home control offering . .  5
     2.2.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Zero-Configuration . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Multiple unique routable subnets . . . . . . . . . . . . .  7
   3.  Building blocks of a CoAP Discovery infrastructure . . . . . .  7
     3.1.  Stand-alone CoAP Server  . . . . . . . . . . . . . . . . .  8
     3.2.  CoAP Discovery Gateway . . . . . . . . . . . . . . . . . .  8
     3.3.  Caching CoAP Discovery Gateway . . . . . . . . . . . . . .  8
     3.4.  CoAP Discovery Client  . . . . . . . . . . . . . . . . . .  9
   4.  CoAP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Topology Discovery . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Topology Path String definitions . . . . . . . . . . . 11
       4.1.2.  ?n=DiscoveryGateway  . . . . . . . . . . . . . . . . . 13
       4.1.3.  Discovering Gateway interfaces - an example  . . . . . 13
     4.2.  Initial Topology Discovery . . . . . . . . . . . . . . . . 13
     4.3.  Incremental Topology Discovery . . . . . . . . . . . . . . 14
       4.3.1.  Multicast domain behind routers  . . . . . . . . . . . 14
     4.4.  CoAP Server Discovery  . . . . . . . . . . . . . . . . . . 15
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Discovery across CoAP Discovery Gateways . . . . . . . . . 15
     5.2.  /topology path formats . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Open Issues . . . . . . . . . . . . . . . . . . . . . 20
     A.1.  Large reports  . . . . . . . . . . . . . . . . . . . . . . 20
     A.2.  M2M Filtering  . . . . . . . . . . . . . . . . . . . . . . 20
     A.3.  Routable subnets . . . . . . . . . . . . . . . . . . . . . 21
     A.4.  Compressing responses from caching CoAP Discovery
           Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 21
     A.5.  Integrated Battery support . . . . . . . . . . . . . . . . 21
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22




Brandt                  Expires September 8, 2011               [Page 2]


Internet-Draft            CoAP Subnet Discovery               March 2011


1.  Introduction

   This document describes the process of discovering CoAP servers
   distributed in multiple subnets in a non-specified topology.  CoAP
   (Constrained object Application Protocol) Discovery Gateways are used
   to discover one subnet from another.  CoAP Discovery Gateways may
   provide caching to enable discovery of sleeping nodes in Low-power
   and Lossy Network (LLN) environments.  Caching CoAP Discovery
   Gateways may also have the purpose of preserving bandwidth in an LLN
   environment.  No synchronization of databases is required.  The
   solution scales to large installations since discovery is handled by
   the client in an incremental fashion.

   CoAP servers may be running on a variety of physical layers; each
   implementing a subnet.  A lamp module may be running over IEEE
   802.15.4.  A movement sensor may be running over Z-Wave.

   The document presents requirements to a home control discovery
   solution and proposes a solution based on the CoAP link format
   [I-D.ietf-core-link-format].

   CoAP Subnet Discovery Must support IPv6.  An implementation MAY
   implement support for both IPv4 and IPv6 .

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Requirements for Discovery services for very constrained nodes

   The term constrained node covers a range of nodes that are
   constrained with regards to memory size, power consumption, packet
   size or CPU capabilities.  This document covers nodes for
   applications within home control and building control.  A Low-power
   Lossy Network (LLN) is used for communication.

   The basic functionality of devices for home control and building
   control is the same: measure temperature, detect movement, dim light,
   operate locks, etc.  The discovery, management and operation of
   networks is however somewhat different.  This document addresses
   discovery requirements specific to the most constrained devices and
   outlines how proper solutions may address home control and building
   control technologies in the same way.





Brandt                  Expires September 8, 2011               [Page 3]


Internet-Draft            CoAP Subnet Discovery               March 2011


2.1.  Home Control network evolution - scenarios

   Home control systems may be constructed from consumer products
   acquired in a retail store.  The products may come from multiple
   vendors.  The user may have no knowledge of network management.  The
   user may have no existing local network.  If there is a local
   network, it may have no DHCP or DNS infrastructure.  Devices must
   always work; the consumer price level does not leave much margin for
   support hotlines.

   The following scenarios assume one common application protocol.
   Multi-protocol support may be achieved via application gateways;
   potentially with CoAP as the common language.  This is out of scope
   of this document.

2.1.1.  Scenario A: Retail home control starter kit

   This scenario outlines how LLN nodes may be used in the most simple
   network configurations and how such simple networks may grow from
   there.  In such simple networks the 6LoWPAN border router is reduced
   to a conceptual function.  The remote control acts as a coordinating
   master node on the link layer as well as a 6LoWPAN border router.
   The remote control enters a sleep state when it is not in use.

   1.  Starter kit bring-up

       A user starts with an RF remote control and three RF plug-in
       modules.  The remote control assigns unique link-layer addresses
       and ULA IP addresses [RFC4193] to modules during network
       bootstrapping so that the remote control and the plug-in modules
       are in the same IP network.  ULA IP addresses are needed as
       multi-hop routing may be used inside the LLN network.
       Prefixes and header compression CIDs have infinite lifetime as
       there is no listening border router.

       Remote control buttons are mapped to (groups of) IP addresses of
       the plug-in modules.  The setup mode may be activated via a
       special key sequence in the remote control.

   2.  Adding sensors

       The user adds another plug-in module and a movement sensor to the
       network.  The remote control is still used as a coordinating
       master node.  The IP address of the target module is stored in
       the movement sensor.  When the sensor detects a movement, it
       sends an "ON" command to the plug-in module.





Brandt                  Expires September 8, 2011               [Page 4]


Internet-Draft            CoAP Subnet Discovery               March 2011


   3.  Adding home control to the smart phone

       The user adds a border router to interface the LLN network to the
       LAN (and WiFi) of the house.
       The user connects a smartphone to the WiFi network.  A home
       control smartphone app performs home control resource discovery.
       A list of LLN nodes allows the user to configure smartphone
       widgets for scene control of lamps; e.g.  "Watch TV" or "Doing
       the dishes".

2.1.2.  Scenario B: Service provider home control offering

   In this scenario, a consumer receives a pre-bundled kit from a
   service provider:

   o  A combined internet access router and LLN border router with WiFi
      support

   o  Three plug-in modules for installation in the home

   o  A personal web profile on the service provider web portal

   o  A smartphone app for control via WiFi

      Remote access credentials, LLN prefix and other parameters are
      preconfigured by the service provider.

   1.  Setting up the kit

       The LLN border router manages link-layer node properties as well
       as prefix assignment, etc.  A web page is used to add the three
       plug-in modules to the LLN.  The smartphone app controls the
       plug-in modules via WiFi.  Routable addresses allow the app to
       reach the modules from the WiFi subnet.

   2.  Adding other technologies

       The original starter kit was a wireless LLN.  The user connects a
       power-line LLN border router to the LAN, thus forming a backbone
       network for the two LLN border routers.  The user includes power-
       line based plug-in modules with the new power-line LLN border
       router.
       Each individual border router manages local ULA prefixes and
       header compression CIDs.

   3.  Re-discovering the network

       The smartphone app rediscovers home control resources in both



Brandt                  Expires September 8, 2011               [Page 5]


Internet-Draft            CoAP Subnet Discovery               March 2011


       LLNs and the backbone network.  The lists of home control
       resources allow the user to configure smartphone widgets for
       scene control of lamps in both subnets.
       The border routers runs a routing protocol on the backbone to
       allow IP packets to traverse from one subnet into the other
       without any manual configuration of routers.

2.2.  Discovery

   Discovery serves multiple purposes in a home control network:

   1.  When the home control network has grown from the original starter
       kit to a substantial number of nodes, the owner may get a desire
       for centralized management of the network.  The management tool
       needs a way to request information from each node in the network.
       Typically, nodes will carry no visible identification at this
       time.  If possible, non-functioning nodes should also be
       identified.  Once nodes are identified, the user may locate the
       nodes physically and assign naming and location information, e.g.
       "bedroom, ceiling light" or "living room, drapes".

   2.  When setting up a remote control, the user may want to browse all
       drape controllers in the entire network - both in the wireless
       LLN and in the powerline LLN.  The wireless drape controllers may
       be battery powered and sleeping most of the time.  The powerline
       drape controllers may be in a dedicated powerline LLN subnet
       behind several border routers.  It is a challenge to discover
       nodes in other subnets.  A multicast-based discovery protocol
       like mDNS cannot have its messages forwarded by routers since it
       uses link-local addressing.  Even if mDNS messages could be
       forwarded, some LLNs featuring multi-hop routing do only support
       multicast in a very slow and inefficient fashion.  Assuming
       multicast messages could be distributed over a LLN, sleeping
       nodes would not be able to detect discovery requests.

   A solution is required which

   o  Does not flood the LLN with unnecessary discovery traffic

   o  Does not require multicasting in LLNs

   o  Does allow the discovery of sleeping nodes

2.3.  Zero-Configuration

   One major property of home control networks is the absence of a
   professional installer.  When making consumer products, one cannot
   make any assumptions about the qualifications of the user.  Simple



Brandt                  Expires September 8, 2011               [Page 6]


Internet-Draft            CoAP Subnet Discovery               March 2011


   operation is a requirement.  As an example, a user may associate a
   light module by activating a setup sequence on a wall switch and then
   pushing a button on the light module.  The user never sees any data.
   Most users actually do not care about the IP address of the light
   module.

   No border router, DHCP server or DNS server is present in a starter
   kit network.  Modules that were initially purchased and configured
   with a remote control may one day be used in a far more advanced
   installation with global routable prefixes and hierarchical DNS
   naming.

2.4.  Multiple unique routable subnets

   Home control domains may be composed of devices communicating via one
   or more border routers, e.g power-line to wireless, optionally via a
   backbone network.  A wireless home control LLN may in itself contain
   routers to do multihop forwarding within the home control LLN.  The
   two subnets may host different MAC/PHYs as well as different routing
   protocols.  The user can extend the home control starter kit with
   another subnet without having to re-install the original subnet.  The
   construction of unique local subnet prefixes is described
   in[RFC4193].


3.  Building blocks of a CoAP Discovery infrastructure

   CoAP defines a protocol for exchange of requests and commands between
   constrained nodes.  Already described in [I-D.ietf-core-coap], the
   CoAP Server is a host capable of responding to CoAP messages.  CoAP
   Servers may be classified into the following sub-types:

   o  Stand-alone CoAP Server

   o  CoAP Discovery Gateway

   o  Caching CoAP Discovery Gateway

   These are described in the following sections.  Finally, the CoAP
   Discovery Client is described.

   CoAP Discovery Gateways MAY advertise legacy devices along with
   native CoAP servers.  CoAP Discovery Gateways MAY provide access to
   legacy services via CoAP request and control messages.  Discovery of
   diverse resource types enables a migration path from legacy
   technologies towards an all-CoAP infrastructure.





Brandt                  Expires September 8, 2011               [Page 7]


Internet-Draft            CoAP Subnet Discovery               March 2011


3.1.  Stand-alone CoAP Server

   A stand-alone CoAP Server does not provide access to other CoAP
   Servers; physical or logical.  Typically a stand-alone CoAP Server is
   able to perform some action, e.g. measuring a temperature or turning
   on light.
   A CoAP Server reports periodically to the Discovery Gateway via the
   6LoWPAN ND address registration process, e.g. once every hour.
   Battery operated CoAP servers may run out of battery.  Light modules
   may become defect.  The reporting allows the Discovery gateway to
   monitor the availability of CoAP Servers.

3.2.  CoAP Discovery Gateway

   A CoAP Discovery Gateway is a CoAP enabled router interconnecting
   different subnets, e.g. a LLN Border Router.  The subnets may host
   stand-alone CoAP Servers as well as other CoAP Discovery Gateways.
   Each CoAP Discovery Gateway interface MUST respond to the CoAP
   Discovery request "GET /.well-known/core?n=DiscoveryGateway".  When
   queried, the gateway MUST report all other interfaces maintained by
   the discovery gateway.

   The Discovery Gateway MAY maintain a list of CoAP Servers that
   recently stopped sending address registrations.  How a CoAP Discovery
   Gateway is to advertize such CoAP Servers is TBD.

3.3.  Caching CoAP Discovery Gateway

   A Caching CoAP Discovery Gateway performs caching of discovery
   information on behalf of other nodes in a given subnet.  A discovery
   gateway interface MUST respond to the CoAP Discovery request "GET
   /.well-known/core?n=DiscoveryGateway".  When queried, the discovery
   gateway MUST report all other interfaces maintained by the discovery
   gateway.  The gateway MUST indicate if respective interfaces are of
   the type "CoAP Discovery Gateway" or "Caching CoAP Discovery
   Gateway".  This information MAY be be ignored by a discovery client.

   CoAP Servers reporting to a Caching CoAP Discovery Gateway MAY
   respond to CoAP Discovery requests.  A Caching CoAP Discovery Gateway
   MUST intercept discovery requests and respond on behalf of CoAP
   Servers.  This allows sleeping nodes to be discovered, saves LLN
   bandwidth and allows the Caching CoAP Discovery Gateway to maintain
   connectivity state information like "online/offline/unstable" per
   CoAP server.

   The Caching CoAP Discovery Gateway MAY maintain a list of CoAP
   Servers that recently stopped sending address registrations.  How a
   CoAP Discovery Gateway is to advertize such CoAP Servers is TBD.



Brandt                  Expires September 8, 2011               [Page 8]


Internet-Draft            CoAP Subnet Discovery               March 2011


              +--------------------------------+
              | Caching CoAP Discovery Gateway |
              |                                |
       +---------------------+      +---------------------+
       |Caching Interface    |      |non-caching Interface|- - +
       |2001:1001::1         |      |2001:1002::1         |
       +---------------------+      +---------------------+    |
              |                                |
              +--------------------------------+               |
                                                             other
                                                          CoAP Servers
                                                        in this subnet

                 Figure 1: Caching CoAP Discovery Gateway

   A Caching CoAP Discovery Gateway MAY report that it is a (non-
   caching) CoAP Discovery Gateway on some interfaces; refer to
   Section 3.2 .

   The device type "Caching CoAP Discovery Gateway" only indicates that
   discovery information is cached.  Caching of real-time data from CoAP
   servers is out of scope of this document.

   A Caching CoAP Discovery Gateway SHOULD NOT interfere with any other
   traffic than Discovery Requests for Discovery Gateways or the
   capabilities of CoAP Servers which report to the CoAP Discovery
   Gateway, e.g.  "Device type = Thermostat".  A Caching CoAP Discovery
   Gateway MUST NOT cache any changing parameters.

3.4.  CoAP Discovery Client

   A CoAP Discovery Client uses the CoAP Discovery request "GET /.well-
   known/core?n=DiscoveryGateway" to initiate a discovery session.  The
   target for the discovery request depends on the properties of the
   actual network.  Two cases apply:


   1.  Client is in a LLN domain with no multicast support

       The initial request is sent to the Authoritative Border Router of
       that LLN.


   2.  Client is in a link-local subnet domain with multicast support
       (like Ethernet)

       The initial request is transmitted to the link-local "all-
       routers" multicast address.



Brandt                  Expires September 8, 2011               [Page 9]


Internet-Draft            CoAP Subnet Discovery               March 2011


   If discovery requests cause CoAP Discovery Gateways to announce other
   CoAP Discovery Gateways in other subnets, additional discovery
   requests are directed to those CoAP Discovery Gateways.

   A Discovery Client may run in remote controls, smart phone apps or
   central management systems for home automation or building control.

   The discovery process depends on the presence of a CoAP discovery
   gateway in the subnet of the discovery client.  Since CoAP subnet
   discovery uses normal CoAP messages, link-local discovery works "out
   of the box" in link-local enabled environments.  Refer to
   [I-D.ietf-core-link-format].


4.  CoAP Discovery

   CoAP Discovery is a hierarchical process and involves two phases:
   CoAP Topology Discovery and CoAP Server Discovery.

   The purpose of the Topology Discovery phase is to establish a
   snapshot of the available CoAP Discovery Gateways.

   CoAP messages are used to discover CoAP Discovery Gateways in a
   hierarchical fashion.  Having completed the topology discovery phase,
   a CoAP client may initiate discovery of particular CoAP server
   resources, e.g. light dimmers, or a more general wildcard discovery
   may be done by the client; building a complete database.  The same
   request MUST be sent to each discovered CoAP Discovery Gateway
   interface in a sequential fashion.

   The information may be presented, e.g. in lists of different device
   types.  CoAP subnet discovery enables access to end nodes in multiple
   subnets without any manual configuration of routers.  The topology
   discovery process may return information on Caching CoAP Discovery
   Gateways.  Caching CoAP Discovery Gateways allow the discovery of
   sleeping and defective nodes but require that CoAP clients implement
   6lowPAN-ND address registration [I-D.ietf-6lowpan-nd]with the
   Authoritative Border Router.  Management and naming related issues of
   CoAP servers in building control are discussed in
   [I-D.vanderstok-core-bc].

   CoAP Discovery depends on the ability to traverse subnets.  Thus, all
   CoAP Servers MUST have routable IPv6 addresses; either in global
   prefixes or according to ULA principles.  The border router is
   typically the physical device implementing the CoAP Discovery Gateway
   function in a LLN.  This specification collapses the address of the
   default gateway (border router) and the discovery gateway in order to
   limit the number of IP addresses that LLN nodes have to manage - and



Brandt                  Expires September 8, 2011              [Page 10]


Internet-Draft            CoAP Subnet Discovery               March 2011


   to avoid having to distribute the address of the CoAP Discovery
   Gateway in LLNs.  RAs already convey the IP address of the default
   gateway.

4.1.  Topology Discovery

   A client may be anywhere in the topology when initiating the Topology
   Discovery.  Any topology may be traversed (if allowed by firewall
   policies in border routers).

   The discovery process allows a client to discover CoAP servers
   according to the classification described in Section 3.

4.1.1.  Topology Path String definitions

   A CoAP Discovery Gateway or caching CoAP Discovery Gateway MUST
   support the following CoAP messages:

   o  GET /.well-known/core?n=DiscoveryGateway

   o  GET /.well-known/core/topology

   o  GET /.well-known/core/topology/device

   o  GET /.well-known/core/topology/interfaces

   o  GET /.well-known/core/topology/servers

4.1.1.1.  /topology/device

   A CoAP Discovery Gateway MUST report one of the device types listed
   in Figure 2.
   +----------+---------------------+----------------------------------+
   | Device   | Label               | Interpretation                   |
   | type     |                     |                                  |
   +----------+---------------------+----------------------------------+
   | 1        | Discovery Gateway   | This is a CoAP Discovery Gateway |
   |          |                     | interface                        |
   | 2        | Discovery Gateway,  | This CoAP Discovery Gateway      |
   |          | caching             | interface is caching             |
   +----------+---------------------+----------------------------------+

                   Figure 2: CoAP Discovery Device Types

   The report formats are described in the following sections.






Brandt                  Expires September 8, 2011              [Page 11]


Internet-Draft            CoAP Subnet Discovery               March 2011


4.1.1.2.  /topology/interfaces

   A CoAP Discovery Gateway MUST return the structure

   [interface address_1]
   ...
   [interface address_n]

   in response to a query for /topology/interfaces.

   The processing of a discovery request depends on the receiving
   interface:

   If the request is targeting the gateway interface that physically
   received the request, the response contains all subnet interfaces of
   the discovery gateway.

   If the request is targeting another gateway interface than the
   gateway interface that physically received the request, the response
   contains all discovery gateways known to the subnet of the targeted
   interface.

4.1.1.3.  /topology/servers

   A Caching CoAP Discovery Gateway MUST return the structure

   [server address_1]
   ...
   [server address_n]

   in response to a query for /topology/servers.

   If the request is targeting the gateway interface that physically
   received the request, the response contains the identity of known
   CoAP Servers that report to this Caching CoAP Discovery Gateway
   interface.

   If the request is targeting another gateway interface than the
   gateway interface that physically received the request, a (non-
   caching) CoAP Discovery Gateway interface in a subnet supporting
   multicast MUST issue a multicast request for all CoAP Servers in
   response to a query for /topology/servers.  The individual CoAP
   Server responses are returned directly to the requesting discovery
   Client.







Brandt                  Expires September 8, 2011              [Page 12]


Internet-Draft            CoAP Subnet Discovery               March 2011


4.1.2.  ?n=DiscoveryGateway

   A CoAP Discovery Gateway MUST report the path /topology in response
   to ?n=DiscoveryGateway.  A CoAP Discovery Gateway MAY report other
   paths as well.

4.1.3.  Discovering Gateway interfaces - an example

   The query string ?n=DiscoveryGateway is used for discovering topology
   information in a CoAP enabled infrastructure.
 [Client sends multicast request to WiFi subnet]
 | CoAP GET /.well-known/core?n=DiscoveryGateway

 [LLN Border Router responds]
 | 200 OK
 |
 | core://2001:.../topology/device;ct=0;n="DiscoveryGateway"

 [Client sends unicast request to the responding CoAP Discovery Gateway]
 [(LLN border router)]
 | CoAP GET /.well-known/core/topology/interfaces

 [LLN Border Router responds]
 | 200 OK
 |
 | 2001:0db8:85a3:beef:0000:8a2e:0370:7334
 | 2001:0db8:85a3:babe:0000:8a2e:0370:4321

   It is seen that the initial Discovery Gateway request only returns a
   single string: "/topology/device/...".  Since the path "/topology/
   interfaces" is mandatory for CoAP Discovery Gateways, the client may
   request this structure as soon as it has detected the CoAP Discovery
   Gateway.

4.2.  Initial Topology Discovery

   A Topology Discovery operation is initiated by a CoAP client with the
   CoAP message GET /.well-known/core?n=DiscoveryGateway in one of the
   following ways.

   1.  If a client resides in a multicast enabled environment (like
       Ethernet or WiFi) the client issues a multicast message (as
       described in [I-D.ietf-core-link-format] ) to the "all nodes"
       address.  All on-link CoAP Discovery Gateways MUST respond to the
       GET message by returning a list of other interfaces of the
       respective CoAP Discovery Gateways.  In order to avoid
       collisions, the responding CoAP Discovery Gateways MUST insert a
       0..MAX_RA_DELAY_TIME [I-D.ietf-6lowpan-nd] random delay before



Brandt                  Expires September 8, 2011              [Page 13]


Internet-Draft            CoAP Subnet Discovery               March 2011


       responding.

   2.  If a discovery client resides in a LLN environment (like IEEE
       802.15.4 or Z-Wave) the client issues a unicast message to the
       border router of the LLN.  The default border router of the LLN
       MUST respond to a CoAP Discovery request by returning a list of
       other interfaces of that particular CoAP Discovery Gateway.

   The discovery client builds a list of reported subnets that it has to
   discover.  Duplicates MUST be omitted.

4.3.  Incremental Topology Discovery

   The client holds a list of reported discovery gateway subnets that it
   has to discover; either from the Initial Topology Discovery or from a
   previous Topology Discovery.

   For each subnet interface, the client sends a unicast GET /.well-
   known/core?n=DiscoveryGateway message to the interface.  In its
   default configuration, a CoAP Discovery Gateway MUST return the
   address of each remote interface.  A CoAP Discovery Gateway MAY be
   configured to return URIs for identification.  CoAP Discovery MUST
   support zero-configuration environments like home control where no
   DNS server can be assumed.

4.3.1.  Multicast domain behind routers

   If a discovery client initiates discovery from a LLN environment, it
   may reach a backbone router interface residing in a multicast enabled
   network domain such as Ethernet.  When a CoAP Discovery Gateway
   receives a unicast discovery request for a multicast enabled network
   interface via another discovery gateway interface, that CoAP
   Discovery Gateway interface MUST forward the discovery request in a
   multicast message for the "all nodes" multicast address.

   The discovery client MUST ignore a reported Discovery Gateway
   interface if that interface is already in the list of known Discovery
   Gateway interfaces.  This is to prevent loops.

   A discovery client MAY perform hierarchical discovery by using the
   general /.well-known/core path.  This combines the topology and
   server discovery phases.  The downside is that a client may receive
   large amounts of data for each individual discovery message.  This
   may be a problem for memory constrained nodes.  By discovering the
   gateway topology first and using filtered server discovery, a client
   may achieve significant reductions in received data.





Brandt                  Expires September 8, 2011              [Page 14]


Internet-Draft            CoAP Subnet Discovery               March 2011


4.4.  CoAP Server Discovery

   CoAP Server Discovery builds on network information revealed during
   topology discovery.  Each discovered subnet must be discovered
   individually.  As an example, if a client connected to a backbone has
   discovered two LLNs behind two border routers, the client must
   perform CoAP Server discovery in the backbone (on-link subnet) as
   well as each of the two LLN interfaces.


5.  Examples

5.1.  Discovery across CoAP Discovery Gateways

   Consider the following network environment: The client is located in
   LAN2.  The discovery process has to traverse CoAP Discovery Gateway
   GW4 and LAN1 to locate CoAP Discovery Gateways GW1, GW2 and GW3.
   CoAP Discovery Gateways 1, 2 and 3 also have to be traversed.  When
   no more new CoAP Discovery Gateways are discovered, discovery for
   CoAP Servers can be initiated.

                 +-------+
   A, B  --- PAN1|  GW1  |LAN1 -+
   PAN1          +-------+      |
                                |
                 +-------+      |      +-------+
   C, D  --- PAN2|  GW2  |LAN1 -+- LAN1|  GW4  |LAN2 --- LAN2
   PAN2          +-------+      |      +-------+         client
                                |
                 +-------+      |
   E, F  --- PAN3|  GW3  |LAN1 -+
   PAN3          +-------+


            Figure 3: Discovery across CoAP Discovery Gateways
















Brandt                  Expires September 8, 2011              [Page 15]


Internet-Draft            CoAP Subnet Discovery               March 2011


    Client |     GW4     |     GW1     |     GW2     |     GW3
      LAN2 | LAN2   LAN1 | LAN1   PAN1 | LAN1   PAN2 | LAN1   PAN3
           |             |             |             |
   1)  ------X GET ?n=DiscoveryGateway (mcast)
           |             |             |             |
   2)  <------ "GW4LAN1"
           |             |             |             |
   3)  -------------->     GET ?n=DiscoveryGateway
           |             |             |             |
   4)                -------X-------------X-------------X GET (mcast)
           |             |             |             |
   5)  <-------------------- "GW1PAN1"                              ^
           |             |             |             |        0..2s |
       <---------------------------------- "GW2PAN2"                |
           |             |             |             |              |
       <------------------------------------------------ "GW3PAN3"  v
           |             |             |             |
   6)  ---------------------------->     GET ?n=DiscoveryGateway
           |             |             |             |
   7)  <----------------------------     ""
           |             |             |             |
   8)  ------------------------------------------>     GET ?n=Disco...
           |             |             |             |
   9)  <------------------------------------------     ""
           |             |             |             |
   10) ---------------------------------------------------------> GET
           |             |             |             |
   11) <--------------------------------------------------------- ""

                     Figure 4: CoAP Discovery Process

   1.   The client sends out a multicast "GET /.well-known/
        core?n=DiscoveryGateway"

   2.   GW4 reports its other interfaces (GW4LAN1).

   3.   The client sends "GET /.well-known/core?n=DiscoveryGateway" to
        GW4LAN1

   4.   GW4LAN1 is not caching and received request in unicast => "GET
        /.well-known/core?n=DiscoveryGateway" is forwarded as multicast

   5.   Reports received from GW1LAN1, GW2LAN1 and GW3LAN1 within 2
        seconds.

   6.   The client sends "GET /.well-known/core?n=DiscoveryGateway" to
        GW1PAN1




Brandt                  Expires September 8, 2011              [Page 16]


Internet-Draft            CoAP Subnet Discovery               March 2011


   7.   GW1PAN1 reports that no other gateways were found in PAN1

   8.   The client sends "GET /.well-known/core?n=DiscoveryGateway" to
        GW2PAN2

   9.   GW1PAN1 reports that no other gateways were found in PAN2

   10.  The client sends "GET /.well-known/core?n=DiscoveryGateway" to
        GW3PAN3

   11.  GW1PAN1 reports that no other gateways were found in PAN3

   The client now has the following list of CoAP Discovery Gateway
   interfaces in unique subnets:

   1.  (mcast in on-link subnet)

   2.  GW4LAN1

   3.  GW1PAN1

   4.  GW2PAN2

   5.  GW3PAN3

   The client may now issue searches for other CoAP Servers by sending
   the request "GET /.well-known/core" to each CoAP Discovery Gateway in
   the list.

5.2.  /topology path formats

   Figure 5 shows an example of a client sending a request for /.well-
   known/core/topology?n=DiscoveryGateway.  The discovery gateway sends
   back a response with the matching resources in the payload.
                                                            DISCOVERY
   CLIENT                                                    GATEWAY
     |                                                          |
     |--CON+GET /.well-known/core?n=DiscoveryGateway [TID=42]-->|
     |                                                          |
     |        <----- ACK + 200 OK [TID=42, CT=0] ------         |
   Payload:
   <core://.../topology/device>;sh="/??";ct=0;n="DiscoveryGateway"

               Figure 5: Looking for CoAP Discovery Gateways

   Figure 6 shows an example of a client sending a request for /.well-
   known/core/topology/interfaces.  The discovery gateway sends back a
   response with the actual interfaces provided by the CoAP Discovery



Brandt                  Expires September 8, 2011              [Page 17]


Internet-Draft            CoAP Subnet Discovery               March 2011


   Gateway.  A CoAP Discovery Gateway MUST implement the path /topology/
   interfaces.
                                                            DISCOVERY
   CLIENT                                                    GATEWAY
     |                                                          |
     |--CON+GET /.well-known/core/topology/interfaces[TID=44]-->|
     |                                                          |
     |        <----- ACK + 200 OK [TID=44, CT=0] ------         |
   Payload:
   2001:0db8:85a3:beef:0000:8a2e:0370:7334
   2001:0db8:85a3:babe:0000:8a2e:0370:4321


              Figure 6: Using the "/topology/interfaces" path

   Figure 7 shows an example of a client sending a request for /.well-
   known/core/topology/interfaces to a caching CoAP Discovery Gateway.
   The discovery gateway sends back a response with the actual
   interfaces provided by the CoAP Discovery Gateway.

   Subsequently, the client may sending a request for /.well-known/core/
   topology/servers to get a list CoAP servers known by the Caching CoAP
   Discovery Gateway.  This list includes sleeping and FLN nodes.
                                                            DISCOVERY
   CLIENT                                                    GATEWAY
     |                                                          |
     |--CON+GET /.well-known/core/topology/interfaces[TID=45]-->|
     |                                                          |
     |        <----- ACK + 200 OK [TID=45, CT=0] ------         |
   Payload:
   2001:0db8:85a3:beef:0000:8a2e:0370:7334

    Figure 7: Receiving addresses from a caching CoAP Discovery Gateway

   Figure 8 shows an example of a client sending a request for /.well-
   known/core/topology/servers to a caching CoAP Discovery Gateway.  The
   discovery gateway sends back a response with the CoAP Servers known
   by the Caching CoAP Discovery Gateway.

   In this case the Caching CoAP Discovery Gateway reports legacy
   devices which do not necessarily speak CoAP.  The client may need to
   implement multiprotocol support in order to communicate to the
   devices.








Brandt                  Expires September 8, 2011              [Page 18]


Internet-Draft            CoAP Subnet Discovery               March 2011


                                                            DISCOVERY
   CLIENT                                                    GATEWAY
     |                                                          |
     |--CON+GET /.well-known/core/topology/servers[TID=46]-->|
     |                                                          |
     |        <----- ACK + 200 OK [TID=46, CT=0] ------         |
   Payload:
   <zw://2001:0db8:85a3:dood:0000:8a2e:0370:6543>
   <zw://2001:0db8:85a3:dood:0000:8a2e:0370:6578>

          Figure 8: Advertising legacy devices via CoAP Discovery

   A more advanced CoAP application gateway may provide translation
   between legacy protocols and CoAP.  This is out of scope of this
   document.


6.  IANA Considerations

   This document has no actions for IANA.


7.  Security Considerations

   If a CoAP Discovery Gateway receives a generalized CoAP GET /.well-
   known/core message and that interface resides in a multicast enabled
   environment such as Ethernet, the CoAP Discovery Gateway forwards
   that CoAP request in an "all nodes" multicast message.  In response,
   the CoAP Discovery Gateway potentially receives messages from a
   number of CoAP Discovery Gateways connected to that link.  Forwarding
   all responses back to the requesting client in individual messages
   MAY be used for an amplification attack.

   Coap discovery is not intended for Internet-wide operation.  An
   internet access router SHOULD NOT forward CoAP messages to or from
   the Internet domain unless there is a specific application need for
   doing so.  CoAP Discovery depends on a secure perimeter.  So does
   many of the LLN nodes which this discovery mechanism is targeting.

   Triggering an amplification attack requires that an attacker has
   access to the LAN or has control over LLN nodes.  If the LLN
   implements link-layer security, an attacker cannot simply inject a
   wireless packet.  If, however, one is within radio range of a LLN, a
   modified microwave oven may be a more efficient jamming tool than an
   amplification attack.


8.  References



Brandt                  Expires September 8, 2011              [Page 19]


Internet-Draft            CoAP Subnet Discovery               March 2011


8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4193]  "Unique Local IPv6 Unicast Addresses", October 2005.

8.2.  Informative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-04 (work in progress), January 2011.

   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-02 (work in progress),
              December 2010.

   [I-D.vanderstok-core-bc]
              Stok, P. and K. Lynn, "CoAP Utilization for Building
              Control", draft-vanderstok-core-bc-02 (work in progress),
              October 2010.

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., "Neighbor Discovery Optimization for Low-power
              and Lossy Networks".

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.


Appendix A.  Open Issues

A.1.  Large reports

   The CoAP Block transfer mode MUST be implemented in order to support
   large reports, e.g. from a caching CoAP Discovery Gateway responding
   on behalf of 100's of CoAP Servers in an LLN.

A.2.  M2M Filtering

   The document describes the use of ?n=DiscoveryGateway for detecting
   CoAP Discovery Gateways.

   It should be considered if dedicated codes or keywords should be
   assigned.  M2M applications will benefit from shorter codes and avoid
   the ambiguity of the free text allowed for '?n='.



Brandt                  Expires September 8, 2011              [Page 20]


Internet-Draft            CoAP Subnet Discovery               March 2011


A.3.  Routable subnets

   CoAP Discovery requires that all CoAP subnets are all reachable from
   a given subnet.  Some application spaces, e.g.  DIY home control, may
   be set up as off-the-shelf boxes with auto-assigned IPv6 subnets
   [RFC4193] with no route entries to other subnets.

   RIPng [RFC2080] is considered sufficient for a home control
   application space.  Larger installations for building control and the
   like are expected to be managed networks.

   The following requirements could ensure successful plug-and-play
   behavior when combining Border Routers with CoAP Discovery Gateways
   from different vendors:

   o  A CoAP Discovery Gateway MUST support RIPng

   o  RIPng SHOULD be enabled in all CoAP Discovery Gateways

   o  A CoAP Discovery Gateway MAY implement other routing protocols

A.4.  Compressing responses from caching CoAP Discovery Gateways

   A caching CoAP Discovery Gateway SHOULD omit leading bytes of each
   reported address if the addresses are all in the same subnet served
   by the CoAP Discovery Gateway.  If omitting leading bytes, a
   responding CoAP Discovery Gateway MUST provide the prefix information
   that was omitted from the reported addresses.

   If no prefix is specified the interface identifiers MUST be full IP
   addresses or URIs.

   A Caching CoAP Discovery Gateway MAY return more than one response
   message.  If compression is used all addresses in a response message
   MUST belong to the same subnet prefix.

A.5.  Integrated Battery support

   A caching CoAP Discovery Gateway MAY be integrated into a LLN border
   router.  This allows for tight integration of support services for
   sleeping nodes.

   The Caching CoAP Discovery Server allows sleeping nodes to be
   discovered.  The border router may implement mailbox delivery
   services for sleeping nodes.  The border router may return
   "Destination Responding Slowly" ICMP messages to IP hosts sending to
   a sleeping node.  The purpose of the ICMP message is to prevent IP
   applications from resending messages because they are not receiving



Brandt                  Expires September 8, 2011              [Page 21]


Internet-Draft            CoAP Subnet Discovery               March 2011


   application acks.

   A distributed routing protocol MAY distribute the mailbox services.
   This is out of scope of this specification.


Appendix B.  Acknowledgements

   Special thanks to Klaus Hartke, Peter Bigot, Peter van der Stok,
   Kerry Lynn and Zach Shelby for substantial contributions to the ideas
   and text in the document.


Author's Address

   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen O  DK-2100
   DENMARK

   Phone: +4529609501
   Email: abr@sdesigns.dk




























Brandt                  Expires September 8, 2011              [Page 22]