CoRE B. Djamaa A. Yachir Internet Draft EMP University Intended status: Experimental March 31, 2019 Expires: September 2019 Proactive Discovery of CoRE Resource Directories draft-djamaa-core-proactive-rd-discovery-00.txt Abstract 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- Drafts. 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 at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 (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 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 Communication. 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 client. 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 ff05::fd. 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]. 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 configuration: 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 TBD. 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. RD /----+----\ / | \ / | \ 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 messages, 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 change; 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 specifications. 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& base=coap://rd1-address:rd1-port Content-Format: 40 Payload: ; rt=core.rd, ; rt=core.rd-lookup-res, ; 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 attributes: 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 are devised for MAX-DS-TRANSMISSIONS and DS-TRANSMISSION-INTERVAL, 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 type. 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 ; 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. DR: DELETE coap://ALL COAP ENDPOINTS/rd1 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 RDs. Djamaa & Yachir Expires September 31, 2019 [Page 14] Internet-Draft Proactive Discovery of CoRE RDs March 2019 6. Security Considerations TBD 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 Algeria Email: badis.djamaa@gmail.com Ali Yachir EMP University Bordj-el-Bahri, Algiers Algeria Email: a_yachir@yahoo.fr Djamaa & Yachir Expires September 31, 2019 [Page 17]