Internet DRAFT - draft-djamaa-core-proactive-rd-discovery


CoRE                                                         B. Djamaa
                                                             A. Yachir
Internet Draft                                          EMP University
Intended status: Experimental                           March 31, 2019
Expires: September 2019

              Proactive Discovery of CoRE Resource Directories


   The CoRE working group has proposed a Resource Directory (RD)
   solution to facilitate the discovery of the resources provided by
   constrained sensor and actuator networks. For such a mechanism to be
   effectively deployable, endpoints must first discover the existence
   of an RD in the network before being able to exploit its
   functionalities. This document presents Proactive RD Discovery
   (PRD); a scalable and effective mechanism to discover RDs. To 
   achieve such qualities, PRD follows an announce-based model that 
   builds upon CoAP Group Communication. PRD aims to provide important 
   performance in terms of energy consumption, generated traffic, 
   expressivity, and RD discovery time.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed

   The list of Internet-Draft Shadow Directories can be accessed

Djamaa & Yachir      Expires September 31, 2019               [Page 1]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   This Internet-Draft will expire on September 31, 2019.

Copyright Notice

   Copyright (c) 2019 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
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction ................................................ 3
      1.1. Context ................................................ 3
      1.2. Terminology ............................................ 4
      1.3. Motivations ............................................ 4
   2. Background on Group Communication............................ 6
   3. PRD Overview ................................................ 6
   4. PRD Operations .............................................. 8
      4.1. Directory advertisement messages ....................... 8
         4.1.1. DA generation and forwarding ...................... 8
         4.1.2. DA Processing ..................................... 10
         4.1.3. Registration Maintenance and Update ............... 11
      4.2. Directory Solicitation messages ........................ 12
         4.2.1. DS Generation and Forwarding ...................... 12
         4.2.2. DS Processing ..................................... 13
      4.3. Directory Registration Removal ......................... 13
         4.3.1. DR Generation and Forwarding ...................... 13
         4.3.2. DR Processing ..................................... 14
   5. Multiple RD Discovery ....................................... 14
   6. Security Considerations ..................................... 15
   7. IANA Considerations ......................................... 15
   8. References .................................................. 15
      8.1. Normative References ................................... 15
      8.2. Informative References ................................. 15
   9. Acknowledgments ............................................. 16

Djamaa & Yachir      Expires September 31, 2019               [Page 2]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

1. Introduction

 1.1. Context

   The Constrained Application Protocol (CoAP) [RFC7252] provides a
   unified mechanism to exchange application data in LLNs. Thus,
   extending today's Web towards a Web of things. CoAP builds upon the
   Representational State Transfer (REST) design paradigm to achieve
   its objectives. Indeed, in CoAP-enabled IoT applications, each
   sensor/actuator node is basically seen as an endpoint, exposing
   sensor readings, actuating capabilities and internal information as
   REST resources that can be queried by clients acting on behalf of
   user applications.

   In order to discover the REST resources provided in LLNs, seamless
   and automatic discovery of available resources is an imperative.
   Such resource discovery solutions can be achieved using a multitude
   of techniques depending on a number of parameters including network
   size, application requirements and available infrastructure. For
   instance, fully distributed solutions [RFC6690],[RFC6762], and
   [RFC6763] can be well suited for an infrastructure-less, small-size,
   zero-configurable IoT network, while a centralized solution [CORE-
   RD] might be deployed for large-scale IoT networks, having dedicated
   resource-rich discovery servers.

   In this context, CoRE has proposed a resource directory
   solution[CORE-RD] responding to SD requirements in large-scale,
   infrastructure-based RESTful IoT applications. [CORE-RD] defines a
   Resource Directory (RD) where resource providers register their
   available resources for clients to query. The RD follows the generic
   architecture of centralized discovery mechanisms. In such
   architecture, providers register the description of their public
   resources at the directory by issuing POST requests. The directory
   confirms the registration for the specified period and returns its
   location to the provider. Clients then query the RD by issuing GET
   requests looking for descriptions matching their requests. The
   default description format adopted by the RD is the CoRE link format
   [RFC6690], which is carried as a payload in a CoAP message. Such
   description has many resource attributes including resource type
   (rt), interface description (if) and path. To achieve RD operations,
   new attributes have been defined in [CORE-RD] such as the endpoint
   attribute (ep) specifying the endpoint hosting the resource
   registered in the RD, and the lifetime attribute (lt) indicating a
   valid registration period. A base URI attribute (base) is also
   introduced in order to allow an endpoint to specify the scheme, ip-
   address and the port on which it will be accessible. Such base
   attribute is of great importance to this document since it is reused

Djamaa & Yachir      Expires September 31, 2019               [Page 3]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   by the RD to advertise itself. The RD makes registered resources
    attribute) issues a GET request to the RD in the following format
   /.well-known/core{?search*}, with the filter {?search*} containing
   known attributes about the required resources.

   As a key aspect of such architecture, both clients and providers
   must first discover an RD before being able to exploit its services.
   While the resource directory draft envisages many reactive
   mechanisms to achieve RD discovery, the default mechanism adopted by
   [CORE-RD] is the CoAP's resource discovery mechanism [RFC6690].
   [CORE-RD] proposes other techniques for RD discovery, which are
   informed guesses, and lets it open, however, to develop other
   mechanisms in order to achieve RD discovery. This draft presents a
   first proactive mechanism for discovering RDs based on CoAP Group

1.2. Terminology

   This document uses the following terms and abbreviations:

   RD: Resource Directory as defined in [CORE-RD]

   PRD: Proactive RD Discovery

   Endpoint (EP): as defined in [RFC7252], describes a CoAP server or

   CoAP Group: A set of CoAP endpoints subscribed to the group's
   associated multicast address. An endpoint May join different CoAP
   Groups. Group Membership is dynamic. As by Section 12.8 of
   [RFC7252], all CoAP Endpoints SHOULD join "All CoAP Endpoints" for
   both the IPv6 link-local address ff02::fd and the site-local address

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.3. Motivations

   Section 4 of the current resource directory draft [CORE-RD]
   envisages and describes 7 approaches for a device to achieve RD
   discovery depending on three mains cases:

   1. The device is configured with a way to find RD:

Djamaa & Yachir      Expires September 31, 2019               [Page 4]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   o Approach 1 - Configure the device with a specific IP address for
      the RD.

   o Approach 2 - Configure the device with a DNS name for the RD and
      use DNS to return the IP address of the RD.

   o Approach 3 - Configure the device with a service discovery
      mechanism like DNS-DS.

   2. The network provide a specific configuration:

   o Approach 4 - Piggyback RD IP address during neighbor discovery
      phase using a new RDAO defined in Section 4.1.

   o Approach 5 - Piggyback RD IP address during DHCP phase.

   3. Neither the device nor the network offer any specific

   o Approach 6 - 6LBR in a 6LoWPAN acts as a RD and the device can
      send a unicast query to 6LBR to confirm its RD function.

   o Approach 7 - Use CoAP multicast query to find a RD in a network
      which supports multicast.

   Approaches 1-3 can be applied to both local and wide area networks,
   while approaches 4-7 are more applicable to networks such as
   6LoWPANs [RFC4944]. Besides, Approaches 1-2 necessitate hard
   configurations in the device making it hard to deal with network
   dynamics (e.g., change of RD addresses, RD port, Number of RDs,
   etc.). Approach 3 necessitates also hard configurations if used with
   unicast DNS or needs to rely on IP Multicast when used with mDNS
   [RFC6762], which does not work beyond link-local scope.
   For the second category of solutions, Approach 4 allow an RD to
   announce its address using ND with no option to specify the port
   and/or the scheme employed by an RD. Approach 5 uses DHCP instead of
   ND to announce RD address, but no option is currently defined for
   such task.
   The last category of solutions do not rely on any device
   reconfiguration nor any assumption on available network primitives.
   Thus, approach 6 assumes that 6LBR plays the role of RD. Besides the
   inconvenient of imposing that the RD be physically integrated with
   the border router, approach 6 may create many issues including
   single point of failure and significant load incurred by endpoints

Djamaa & Yachir      Expires September 31, 2019               [Page 5]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   near the border router. Finally, approach 7 relying on CoAP service
   discovery [RFC6690] has the advantage to respond to all RD discovery
   requirements without any device hard configurations or assumed
   network infrastructure. It is the default right now. All examples in
   [CORE-RD] are given using this approach. However, such mechanism may
   result in excessive network resource consumption [PRD].
   Moreover, RD discovery can be performed in two ways: query-based on-
   demand); or announce-based (proactive). Only ND and DHCP-based
   approaches that are announce-based. Five out of the above 7
   approaches proposed in [CORE-RD] are query-based. This discovery way
   can generate excessive network overhead along with RD bottlenecks
   when there is a great number of devices in the same network looking
   for RDs either for publication of their resources or discovery of
   available resources [PRD]. In addition, in all approaches, there is
   no available clues for endpoints to choose which RD to use (e.g.
   supported content-format...etc.). This implies that endpoints should
   check for all available RDs. Finally, there is a price in terms of
   RD discovery time to pay in all these approaches.
   To deal with aforementioned issues, we propose Proactive RD
   Discovery (PRD), an announce-based RD discovery mechanism using CoAP
   Group Communication. PRD aim to address all issues above.
2. Background on Group Communication


3. PRD Overview

   PRD allows a resource directory to proactively advertise its
   presence and provided capabilities for endpoints to cache locally
   and use for the sake of RD finding. The proposal makes use of CoAP
   messages and methods to achieve proactive discovery of an RD. It
   particularly adopts POST requests to proactively announce (push) RD
   information to the network in a CoAP message called Directory
   Advertisement (DA) as depicted in Figure 1. The pushed RD
   information MUST support CoRE Link Format [RFC6690] and can be also
   pushed in other formats.PRD implementations using this specification
   MUST support the application/link-format content format (ct=40).

   Such message is POSTed to the "All CoAP Endpoints" site-local scoped
   IP address using CoAP Group Communication [RFC7390]. At the
   reception of the first DA, an endpoint creates a registration
   containing advertised RD information, which is kept for a specified
   lifetime, updated using either PUT or POST methods, and propagated
   in a wavelike pattern from endpoints near the RD to those at the

Djamaa & Yachir      Expires September 31, 2019               [Page 6]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   edge of the network as shown in Figure 1. Using CoAP Group
   Communication over IP Multicast ensures that, with time, all
   endpoints will receive the RD's DA message. However, an endpoint
   requiring to use RD services before receiving the DA can issue a
   link local multicast Directory Solicitation (DS) GET request looking
   for resources having the attribute rt = core.rd* (Section 4.2). Upon
   reception of a DS request, an endpoint having matching RD
   information may issue a response. Finally, PRD envisages a state
   maintenance mechanism (Section 4.3) providing seamless reactions to
   network dynamics. Indeed, in PRD, all POSTed RD information is only
   kept for the specified lifetime and must be periodically refreshed
   by the RD. Besides, the RD can explicitly remove such information by
   issuing Directory registration removal (DR) message.

   This PRD functioning allows an RD to announce itself directly to
   endpoints within a link-local, realm-local and/or site-local domain.
   If the RD happens to be separated from the endpoints via an LLN
   Border Router (LBR), for example, The Resource Directory Address
   Option (RDAO) using IPv6 Neighbor Discovery (ND) introduced in
   section 4.1.1 of [CORE-RD] can be used. Indeed, RDAO carries
   information about the RD address up to the LBR, which can then
   advertises it to the endpoints using PRD.

                               /      |      \
                             /        |         \
                          EP         EP          EP
                         /   \        |          /  \
                        /     \       |         /     \
                       /       \      |        /        \
                     EP -------- EP   EP ---- EP ------- EP
                   /  \              / \               /    \
                  /    \            /   \             /      \
                 /      \          /     \           /        \
                EP       EP ------EP     EP       EP ---------- EP
                * *              * *     *       * *           * *
               *   *            *   *   *       *   *         *   *
              *     *          *     * *       *     *       *     *
             EP     EP        EP     EP      EP       EP    EP      EP

                    ------- DA message : RD-->EP ; EP-->EP
                    ******* DS message : EP-->EP ; EP-->RD

              Figure 1: An Overview of proactive RD discovery

Djamaa & Yachir      Expires September 31, 2019               [Page 7]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   PRD support endpoints able to use the registration interface and
   Simple registration interfaces of [CORE-RD]. Endpoint that cannot
   support both interfaces and are being registered in the RD via
   third-party commissioning tools (section 5.2 of [CORE-RD]) may
   simply ignore DA messages.

   Finally, PRD allows to find the RD along with its URIs at once,
   saving, thus, one RD discovery cycle.

4. PRD Operations

   This section presents the details of PRD operations. These are
   categorized into three basic functionalities:

   o Generation, forwarding, processing and maintenance of DA

   o Generation, forwarding and processing of DS messages,

   o Generation, forwarding and processing of DR messages,

  Each operation is detailed in the following subsections

4.1. Directory advertisement messages

   DA message uses the non-idempotent CoAP method POST. To be compliant
   with [RFC7390], this draft has designed the resource to be posted
   (resource containing RD information) to cope with the unreliable
   nature of LLNs. Indeed, being based on Multicast protocols dedicated
   for LLNs such as MPL increases the reliability of multicast
   discovery thanks to periodic repetitions. Moreover, missing the
   POSTed resource by some endpoints does not compromise the operations
   of PRD. For instance, the Directory Solicitation message discussed
   below (Section 4.2) allow such node to ask for the information when
   needed. In a worst case scenario, the endpoint may ask the RD
   directly for such information using approach7 (Section 4.3) in
   [CORE-RD]. In the other case, where the POST request is received
   multiple times, an endpoint SHOULD discard subsequent registrations.
   Knowing that a DA message from the same RD is redundant can be done
   via the Message-ID field or via the endpoint attribute contained in
   the request.

4.1.1. DA generation and forwarding

   The RD generates and maintains its DA messages using CoAP Group
   Communication. A new DA, with a new Message-ID, is generated by the
   RD when:

Djamaa & Yachir      Expires September 31, 2019               [Page 8]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   o The RD becomes enabled, reboots and/or when the lifetime of the
      previous DA is about to expire;

   o The IP address and/or port number on which the RD is accessible

   o Each time any advertised RD resource attribute and content
      changes (e.g., a change in the RD path).

   The DA message is then POSTed to the "All CoAP Endpoints" site-local
   scoped multicast address [RFC7390] to be registered on endpoint(one
   registration is done per RD).The registration request interface is
   specified as follows:

   Interaction: RD ->EPs
   Method: POST

   Content-Format: application/link-format or any other indicated media
   type representing web links
   URI Template: {+rd}{?ep,lt,base,extra-attrs*}

   URI Template Variables:

   rd := RD default registration URI (mandatory). This can bea default
   location inferred from "ep" and/or "base", for instance, /rd1.

   ep := RD name, which is indicated using the "ep" attribute
   introduced in [CORE-RD] and has the same specifications (mandatory).
   It MUST be unique and should be used to uniquely identify an RD.

   lt := Lifetime (optional). This attribute indicates the lifetime of
   an RD registration in the range of 60-4294967295 seconds, similarly
   to [CORE-RD]. If absent, a default value a default value of DEFAULT-
   RD-REGISTRATION is assumed.

   base := Base URI (optional). This parameter is defined similarly to
   [CORE-RD] and convoys the scheme, ip-address and port on which the
   RD is accessible. If absent, this information can be inferred from
   the scheme of the protocol, source ip-address and source port of the
   registration request. The Base URI can be then constructed in the
   same way as in [CORE-RD].

   extra-attrs*: = additional attributes that MAY be defined in future

Djamaa & Yachir      Expires September 31, 2019               [Page 9]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   The example below shows an RD with the name "rd1" POSTing its
   information to the network using the above interface.

   Req: POST coap://[All CoAP Endpoints:DPort]/rd?ep=rd1&
   Content-Format: 40

   </rd>; rt=core.rd,

   </rd/res>; rt=core.rd-lookup-res,

   </rd/ep>; rt=core.rd-lookup-ep

   Responses to this DA message are suppressed.

   DAs are POSTed periodically each DA-ANNOUNCE-PERIOD. This period can
   be tailored to the needs of the application, if not specified a
   default value of 25 hours can be assumed. Furthermore, this period
   can be adapted to network dynamics.

4.1.2. DA Processing

   Receiving a DA message from an RD causes an endpoint to update its
   registration of RD information. To do so, the following rules apply
   for a POST request targeting an rd.

   o When the ep value, uniquely identifying an rd, contained in the
      registration request is different from any existing registration
      value, a new registration is generated.

   o When the ep value, uniquely identifying an rd, contained in the
      registration request matches an existing registration, the
      content and parameters of the existing registration are updated
      with the content of the registration request.

   In the former, the endpoint creates a registration at an assumed
   default path that can be inferred from the "ep" and/or "base"
   attribute to ensure its uniqueness per RD. In the latter, the
   exiting registration SHOULD only be updated. Indeed, this interface
   MUST be implemented to be idempotent. In either case, the endpoint
   suppresses responses to DA messages following CoAP [RFC7252] and
   hence CoAP group communication [RFC7390] recommendations.
   Exceptionally, endpoints unable to use the assumed default location
   for RD registrations MAY respond with the location chosen.
   Processing of such responses by RD is TBD.

Djamaa & Yachir      Expires September 31, 2019              [Page 10]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   The endpoint then adds the created resource into its /.well-
   known/core resource for the sake of making it discoverable to other
   endpoints issuing DS messages.

4.1.3. Registration Maintenance and Update

   Each endpoint keep one registration per RD. A registration is
   represented by a set of links in the CoRE link format as specified
   in [RFC6690]. It has the following mandatory and optional

   o A mandatory RD name convoyed using the "ep" attribute introduced
      in [CORE-RD] and has the same specifications;

   o A mandatory registration Base URI,"base", in the format
      scheme://authority part. "base" MAY have multiple values
      depending on the supported RD addresses, ports and schemes. An
      endpoint may use different base URIs to contact the RD depending
      on the supported functionalities;

   o A mandatory lifetime, "lt", in seconds;

   o Optional web links describing the resource.

   An RD registration is kept active for the specified lifetime. It is
   the responsibility of an RD to refresh its registration and confirms
   its presence in the network by issuing DA messages periodically
   using the registration interface of section 4.1.1. This update,
   however, SHOULD only contain the content and parameters that have
   been changed. If nothing has been changed from the previous
   registration, the RD issues a DA only containing the "ep" parameter.
   Receiving such a DA causes the endpoint to refreshes the
   registration for the initial "lt" value.

   An endpoint SHOULD mark an expired non-updated RD registration as
   stale and SHOULD NOT respond to DS messages (Section 4.2) concerning
   this RD. The endpoint may turn a stale registration into the active
   state every time it has a successful interaction with the RD.
   Because of this, the RD MAY adapt the value of DA-ANNOUNCE-PERIOD
   depending on the interactions it has with endpoints. Specifying such
   a behavior is TBD.

   To deal with the unreliability of group communications, an endpoint
   not receiving DA to refresh an about to expire RD registration, can
   issue a DS message (Section 4.2.1) to ask for such information from
   its neighboring endpoints. If a successful response is received, it
   will update its registration with the lifetime indicated in the "lt"

Djamaa & Yachir      Expires September 31, 2019              [Page 11]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   parameter. Otherwise, it MAY contact the RD directly by unicast
   using the information from the expired registration or via multicast
   using approach 6 of [CORE-RD] to GET such information. The response
   to such a GET request will cause the node to refresh its
   registration. An endpoint, MAY, however, decide to delete an RD
   registration if it fails to reach the RD.

4.2. Directory Solicitation messages

4.2.1. DS Generation and Forwarding

   In case of missing a DA, on-demand directory solicitations can be
   issued using the DS message. In addition to speeding up RD
   discovery, this functionality is particularly important for new
   endpoints joining a network. For instance, a new node joining the
   network can discover the RD by issuing a DS message as shown in
   Figure 1. DS messages are sent a MAX-DS-TRANSMISSIONS times
   separated by a DS-TRANSMISSION-INTERVAL. If no application values
   default values of 3 time and 10 seconds, respectively, can be used.
   If still there are no responses, the originator switches to a slower
   transmission rate. The transmission of a DS is cancelled by
   receiving a response or a DA containing the requested information.
   The DS template is follows the rule of [RFC6690] and is given below:

   Interaction: EPs->EPs and RDs
   Method: GET
   URI Template: /.well-known/core{?rt&base&ep}
   URI Template Variables:

   rt := Resource Type (mandatory). SHOULD contain one of the values
   "core.rd", "core.rd-lookup*", "core.rd-lookup-res", "core.rd-lookup-
   ep", or"core.rd*"

   base := Base URI (optional). SHOULD contain a value from "base"
   values of existing RD registrations of the issuing endpoint.

   ep := RD name (optional). SHOULD contain a value from "ep" values of
   existing RD registrations of the issuing endpoint.

   Accept: absent, application/link-format or any other supported media

   DS messages are sent to the "All CoAP Endpoints" link-local scoped
   address, no forwarding is required. The example below shows an
   endpoint issuing a DS message looking for "rt=core.rd".

Djamaa & Yachir      Expires September 31, 2019              [Page 12]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   DS: GET coap://[ff02::fd]/.well-known/core?rt=core.rd

   DS Res: 2.05 Content
   </rd>; rt="core.rd"; base="coap://rd-address:rd-port"

   DS messages looking for specific RD name and base URIs may be issued
   by endpoints having such parameters searching for a specific RD to
   refresh its registrations for instance.

4.2.2. DS Processing

   On receiving a DS message, an endpoint having matching resource
   registrations generates a unicast response to be sent back to the DS
   originator following the specification of [RFC6690].

   Since multiple endpoints might respond to a multicast DS, the
   congestion control mechanism suggested by CoAP [RFC7252] should be
   used. Thus, endpoints should insert a random delay, called leisure
   time, before issuing their responses. The lower bound of the leisure
   time can be approximated based on an estimate of the group size G,
   the data transfer rate T and the response size S as follows:
   LBLeisure = S*GT. If endpoints are not able to estimate such
   parameters, a default value of 5s might be used.

4.3. Directory Registration Removal

   Being a proactive approach, PRD might suffer from network
   inconsistencies by keeping information about an RD which is no
   longer available. The mechanisms discussed in section 4.1.3
   concerning registration maintenance and updates can achieve soft
   deregistration of stale information. Additionally, this section,
   introduces an explicit Directory Registrations Removal (DR)
   mechanism. Indeed, an RD going to be unavailable SHOULD explicitly
   announce its unavailability to the network. To do so, the RD SHOULD
   issue DR messages to the "All CoAP Endpoints" site-local scoped IP
   address using CoAP Group Communication with the DELETE method.

4.3.1. DR Generation and Forwarding

   DR enables a directory to advertise its graceful disappearance. This
   is done by issuing a DR message with the DELETE method to the path
   inferred from the "ep" and/or "base" attribute of this RD, which is
   unique per RD. This functionality is ensured using the removal
   interface specified as follows:

   Interaction: RD -> EPs
   Method: DELETE

Djamaa & Yachir      Expires September 31, 2019              [Page 13]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   URI Template: {+location}
   URI Template Variables:

   location := is the assumed default location, which MAY be inferred
   from the "ep" and/or "base" attribute.

   Similarly to DA messages, responses to DR messages are suppressed.

   The following example shows the removal of an RD registration
   located at the "/rd1" path.

   The forwarding of this message is done using CoAP group
   communication similarly to DA (Section 4.1.1).

4.3.2. DR Processing

   The reception of a DR message with the DELETE method causes the
   endpoint to delete corresponding RD information and hence,
   suppresses it for its /.well-known/core resource.

5. Multiple RD Discovery

   Having multiple RDs might be preferable not only for redundancy
   reasons but also to support and provide different services. Indeed,
   a provider might be willing to register with an RD that supports a
   specific content-format/protocol. Similarly, a client might prefer
   to query an RD supporting its required parameters. PRD provides
   support of the discovery of multiple RDs in a network. To do so,
   each RD announce its available interfaces and supported
   functionalities using CoAP Group communication separately. This
   requires endpoints to keep and maintain a resource per RD. This
   might increase the burden on sensor/actuator endpoints. However,
   taking into account the number of expected RDs in a network, this
   solution may present a fair trade-off. Optimized versions for
   supporting proactive announcements of multiple RDs may be devised
   and are out of the scope of this draft.

   Finally, it should be noted that by supporting discovery of multiple
   RDs, PRD can play a pivotal role into distributing hints allowing
   both providers and clients to be aware of available resources and
   functionalities of each RD and giving them all necessary information
   to access such resources. For instance, PRD can distribute
   information about the content formats supported by an RD using the
   content type (ct) attribute. Clients and providers might use this
   information to select preferred content formats for interacting with

Djamaa & Yachir      Expires September 31, 2019              [Page 14]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

6. Security Considerations


7. IANA Considerations

   This document has no actions for IANA.

8. References

8.1. Normative References

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

   [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
             Application Protocol (CoAP)", RFC 7252,
             DOI 10.17487/RFC7252, June 2014,

   [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
             the Constrained Application Protocol (CoAP)", RFC 7390,
             DOI 10.17487/RFC7390, October 2014,

   [CORE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
             Amsuess, "CoRE Resource Directory", draft-ietf-core-
             resource-directory-20 (work in progress), March 2019.

   [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
             Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,

8.2. Informative References

   [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
             DOI 10.17487/RFC6762, February 2013,

   [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
             Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
             "Transmission of IPv6 Packets over IEEE 802.15.4

Djamaa & Yachir      Expires September 31, 2019              [Page 15]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

             Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,

   [PRD]    Djamaa, B. and Yachir, A.: A Proactive Trickle-based
             Mechanism for Discovering CoRE Resource Directories.
             Procedia Comput. Sci. 83, 115-122 (2016).

9. Acknowledgments

   The authors would like to thank Chonggang Wang and Akbar Rahman for
   fruitful inputs and discussions.

Djamaa & Yachir      Expires September 31, 2019              [Page 16]
Internet-Draft     Proactive Discovery of CoRE RDs          March 2019

   Authors' Addresses

   Badis Djamaa
   EMP University
   Bordj-el-Bahri, Algiers


   Ali Yachir
   EMP University
   Bordj-el-Bahri, Algiers


Djamaa & Yachir      Expires September 31, 2019              [Page 17]