ANIMA L. Zhu Internet-Draft S. Jiang Intended status: Standards Track BUPT Expires: 3 September 2025 C. Sheng Huawei Technologies 2 March 2025 Lightweight GeneRic Autonomic Signaling Protocol draft-zhu-anima-lightweight-grasp-02 Abstract This document proposes the UDP-based Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP), which is designed to be a lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. LW-GRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Given the established ecosystem of CoAP and aiming to promote LW- GRASP adoption in IoT, this document also focuses on the LW-GRASP transition from UDP to a CoAP-based framework, i.e., LW-GRASP over CoAP. Furthermore, this document also discusses the potential way to adapt the LW-GRASP to work on the network without IP connectivity. 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 https://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 3 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Zhu, et al. Expires 3 September 2025 [Page 1] Internet-Draft LW-GRASP March 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Built-in reliability mechanism . . . . . . . . . . . . . . . 4 3.1. Reliable transmission for confirmable LW-GRASP messages . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Retransmission and retransmission timeout . . . . . . . . 6 4. Lightweight GRASP definition . . . . . . . . . . . . . . . . 6 4.1. Lightweight GRASP message format . . . . . . . . . . . . 7 4.2. Lightweight GRASP option . . . . . . . . . . . . . . . . 7 4.2.1. LW-Objective option . . . . . . . . . . . . . . . . . 7 4.2.2. REQ-ACK option . . . . . . . . . . . . . . . . . . . 8 4.2.3. ACK option . . . . . . . . . . . . . . . . . . . . . 8 4.3. Lightweight GRASP message . . . . . . . . . . . . . . . . 9 4.4. Lightweight GRASP constants . . . . . . . . . . . . . . . 10 5. LW-GRASP over CoAP . . . . . . . . . . . . . . . . . . . . . 11 5.1. LW-GRASP over CoAP overview . . . . . . . . . . . . . . . 11 5.2. LW-GRASP interaction procedures over CoAP . . . . . . . . 12 6. IP-independent discussion . . . . . . . . . . . . . . . . . . 14 6.1. How LW-GRASP adapts to networks without IP . . . . . . . 14 6.2. An example: Exchange LW-GRASP over BLE . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. IANA considerations for LW-GRASP . . . . . . . . . . . . 16 7.2. IANA considerations for LW-GRASP over CoAP . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1. Security considerations for LW-GRASP . . . . . . . . . . 17 Zhu, et al. Expires 3 September 2025 [Page 2] Internet-Draft LW-GRASP March 2025 8.2. Security considerations for LW-GRASP over CoAP . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction In IoT that has developed rapidly in recent years, the traditional centralized and human-centered network management methods have gradually shown defects such as low efficiency and high operating costs due to the growth in the number, heterogeneity, diversity, and the increasingly uncertain distribution of devices. Autonomic Network[RFC8993] empowers networks and devices with self-management capabilities, enabling them to self-configure, self-optimize, self- recover, and self-protect without human intervention, effectively improving the stability and reliability of the network, which meets the development needs and trends of IoT and is essential for implementing IoT applications such as smart homes, smart cities, and industrial IoT. As a new network management solution for TCP/IP networks, the Autonomic Network does not intend to break the existing IP-based network architecture. So does the GRASP[RFC8990], the signaling protocol in the Autonomic Network. While located between the transport layer and the application layer, GRASP provides reliable and efficient services for nodes in the Autonomic Network, like parameter discovery, exchange, and negotiation, based on the TCP/IP protocols. Since it does not provide reliability mechanisms such as error detection, retransmission, and flow control[RFC8990], GRASP must depend on the reliability mechanisms provided by the transport layer, particularly its synchronization and negotiation procedures based on one or more round(s) of message interaction. It is specified in [RFC8990] that GRASP unicast messages MUST use the reliable transport layer protocol, e.g., TCP. However, the reliability provided by TCP is not free. GRASP must tolerate the inevitable additional latency, control overhead, and memory consumption caused by complex reliability mechanisms of TCP, e.g., the resource consumption and control overhead associated with establishing, maintaining, and closing TCP connections. In addition, the size of the TCP/IP stack on which GRASP relies and the memory resources required to run it are not negligible, e.g., running a standard full TCP/IP stack requires at least tens to hundreds of KBs of data and code memory, and even TCP/IP stacks specifically designed and implemented for resource-constrained devices require tens of KBs of memory. However, the resource-constrained device typically has only about 50KB of memory[RFC7228]. Obviously, in the IoT networks Zhu, et al. Expires 3 September 2025 [Page 3] Internet-Draft LW-GRASP March 2025 dominated by resource-constrained devices with limited CPU, memory, and power resources, the resource footprint of the TCP/IP stack and its execution, especially the TCP, is likely to be a limiting factor in the deployment of the Autonomic Network and GRASP. Therefore, making GRASP lightweight and removing its dependence on TCP or even IP is of great significance for the deployment and promotion of GRASP in the IoT. In addition, considering the generally short length of interaction messages between IoT nodes, it is also necessary to shorten the length of GRASP messages with the best efforts, especially the control fields, which can also reduce the overhead of nodes in processing, parsing, and sending GRASP messages. Considering the demand for self-management and the resource- constrained feature of IoT devices, this document proposes the UDP- based Lightweight GRASP (LW-GRASP). By reducing the length of fixed fields, and adding a built-in reliability mechanism with the acknowledgment and retransmission capability, LW-GRASP can provide reliable signaling services without relying on TCP. Since the wide adoption and mature ecosystem of CoAP[RFC7252] in low-power and low- bandwidth networks, migrating LW-GRASP from UDP to CoAP would significantly benefit its deployment in current IoT networks. Hence, the LW-GRASP over CoAP is also considered and proposed in this document. In addition, to better address the need for self- management of the IoT, the possible IP-independent extension is discussed, which can extend the use of LW-GRASP to networks without IP connectivity. 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Built-in reliability mechanism LW-GRASP is designed to be UDP-based to avoid the additional control overhead and memory consumption caused by TCP, thus matching the capabilities of IoT nodes. Meanwhile, to ensure reliability, the LW- GRASP introduces a message-oriented built-in reliability mechanism. LW-GRASP uses the 16-bit random number called Nonce to implement the acknowledgment and retransmission mechanism for messages to avoid interaction failures caused by message losses. However, as discussed in Section 4.3, not all LW-GRASP messages require acknowledgment, such as multicast messages. The LW-GRASP messages that require acknowledgment are referred to in this document as confirmable Zhu, et al. Expires 3 September 2025 [Page 4] Internet-Draft LW-GRASP March 2025 messages, and the others that do not require acknowledgment are referred to as non-confirmable messages. The transmission of confirmable messages MUST use the reliability mechanism defined in this section, while non-confirmable messages do not. 3.1. Reliable transmission for confirmable LW-GRASP messages When sending a confirmable message, the LW-GRASP sender MUST generate a 16-bit random Nonce and append the Nonce to the message. Upon receipt of a confirmable message, the receiver MUST acknowledge immediately using the same Nonce as that of the received, or wait for a post-order message in the same direction and piggyback acknowledge with this message within the LW_GRASP_ACK_DELAYED_TIME. The latter is the delayed acknowledgment, if there is no corresponding message to be sent within the LW_GRASP_ACK_DELAYED_TIME, an ACK message MUST be sent immediately. LW-GRASP defines two new options, i.e., the REQ-ACK option and the ACK option. The REQ-ACK option is used to carry the Nonce generated by LW-GRASP for a specific confirmable message and MUST be added to this message as an option. The ACK option also contains a Nonce for acknowledging a corresponding confirmable message, which MUST be added as an option to an ACK message (immediate acknowledgment) or a post-order message in the same direction (delayed acknowledgment). The REQ-ACK option, the ACK option, and the ACK message are defined in Section 4.2.2, Section 4.2.3, and Section 4.3, respectively. The Nonce can be regarded as the unique identifier of a confirmable message before it is acknowledged. Thus, the LW-GRASP nodes MUST avoid Nonce conflicts among unacknowledged confirmable messages. Specifically, the Nonce SHOULD be generated by a pseudo-random number generator (PRNG) based on the locally generated unique seed to avoid the conflict of Nonce generated by different nodes in the same network. Meanwhile, the LW-GRASP instance SHOULD create and maintain a Nonce cache to record the Nonce used by confirmable messages. After generating a Nonce for a message, the LW-GRASP MUST check whether it conflicts with an existing entry in the Nonce cache, and if it doesn't, it SHOULD record the Nonce in the cache. Otherwise, the Nonce for the confirmable message MUST be regenerated. After the GRASP node receives a message with an ACK option(or more than one ACK option), it SHOULD first extract the Nonce from it and check whether there is a corresponding entry with the same Nonce value in the Nonce cache; if not, the received message SHOULD be directly ignored. Otherwise, the GRASP node SHOULD mark the Nonce entry as acknowledged and delete it when the corresponding LW-GRASP session is completed. It is worth emphasizing that confirmable messages marked as acknowledged SHOULD also be considered by the aforementioned Nonce conflict detection. Zhu, et al. Expires 3 September 2025 [Page 5] Internet-Draft LW-GRASP March 2025 The LW-GRASP sender MUST set the retransmission timer when sending a confirmable message; see Section 3.2 for details on setting the timeout. If the LW-GRASP confirmable message does not get an acknowledgment within the retransmission timeout, then the message MUST be retransmitted. The retransmission message SHOULD keep the Nonce the same as the original message. However, when a confirmable message has been accepted and processed by the receiver but is retransmitted due to lost acknowledgment, the LW-GRASP can not identify the retransmission message and will repeatedly process it, which can be dangerous. Thus, the LW-GRASP receiver SHOULD record and cache the Nonces of confirmable messages that have been received and processed for each LW-GRASP session until it is completed and check whether the Nonce of each arriving message conflicts with the cached Nonces, if it doesn't, then accept and process it. Otherwise, which means the message is a retransmission message, LW-GRASP SHOULD discard it and send acknowledgment, to avoid duplicated processing of the retransmission and original messages due to the loss of the acknowledgment. The delayed acknowledgment mechanism can reduce the communication cost caused by the ACK message, but its waiting time may cause unnecessary delay, which reduces the efficiency of communication. In the actual LW-GRASP implementation, users SHOULD be allowed to enable or completely disable delayed acknowledgment according to their needs. 3.2. Retransmission and retransmission timeout The retransmission timeout for reliable transmission of LW-GRASP messages is LW_GRASP_RETRANS_TIMEOUT. If the LW-GRASP message is not acknowledged within the retransmission timeout and the number of retransmissions does not reach MAX_RETRANS, the message MUST be retransmitted and the retransmission timer SHOULD be reset, the retransmission timeout SHOULD be incremented to twice, and the number of retransmissions SHOULD be incremented by 1. If the LW-GRASP message is not acknowledged within the retransmission timeout and the number of retransmissions exceeds MAX_RETRANS, the retransmission MUST be discarded, and the transmission fails. 4. Lightweight GRASP definition LW-GRASP has made modifications to the standard GRASP by reducing the fixed fields and introducing a message-oriented built-in reliability mechanism with the acknowledgment and retransmission capability based on Nonce. To achieve this, LW-GRASP redefines the Objective option in standard GRASP as the LW-Objective option and defines a new message named ACK message, along with two new options named REQ-ACK option and ACK option. However, LW-GRASP does not modify the Zhu, et al. Expires 3 September 2025 [Page 6] Internet-Draft LW-GRASP March 2025 discovery, negotiation, synchronization, and flooding procedures, as well as the defined options (except for the Objective option) of the standard GRASP. In addition, LW-GRASP still adheres to the High- Level Deployment Model and High-Level Design defined for GRASP, so as not to affect the signaling service provided by the protocol. In order to differentiate from standard GRASP, LW-GRASP instances SHOULD listen for messages using a new well-known port, LW_GRASP_LISTEN_PORT (TBD1). 4.1. Lightweight GRASP message format Like standard GRASP, LW-GRASP messages continue to be transmitted in Concise Binary Object Representation (CBOR)[RFC8949] and be described using Concise Data Definition Language (CDDL)[RFC8610]. The session- id in the LW-GRASP message is shortened from 32 bits to 16 bits to minimize the length of the message, while the meanings of the other fields are still consistent with the standard GRASP message. In fragmentary CDDL, a LW-GRASP message follows the pattern: lw-grasp-message = (message .within message-structure) / noop-message message-structure = [LW_MESSAGE_TYPE, session-id, ?initiator, *lw-grasp-option] LW_MESSAGE_TYPE = 0..255 session-id = 0..65535 ; up to 16 bits lw-grasp-option = any 4.2. Lightweight GRASP option 4.2.1. LW-Objective option In fragmentary CDDL, a LW-GRASP Objective option follows the pattern: lw-objective = [objective-num, objective-flags, loop-count, ?objective-value] objective-num = 0..255 objective-value = any loop-count = 0..255 objective-flags = uint .bits objective-flag objective-flag = &( F_DISC: 0; valid for discovery F_NEG: 1; valid for negotiation F_SYNCH: 2; valid for synchronization F_NEG_DRY: 3; negotiation is a dry run ) Instead of using the text string with indefinite length (i.e., objective-name) as the unique identifier for the Objective option, the LW-Objective option is uniquely identified by an 8-bit number Zhu, et al. Expires 3 September 2025 [Page 7] Internet-Draft LW-GRASP March 2025 (i.e., objective-num), with the remaining fields keeping consistent with the Objective option in standard GRASP. The first two bits of objective-num indicate the LW-Objective type (00, 01, and 10 stand for generic LW-Objective; 11 stands for privately defined LW- Objective), and represent the number of LW-Objective together with the remaining six bits. Each generic LW-Objective MUST be assigned a unique objective number and be made public to all LW-GRASP nodes when it's registered. When a private LW-Objective is defined, it MUST also be assigned a uniquely distinguishable objective number and be made public within the specific private domain. In LW-GRASP, the identifier of the LW-Objective option is changed from the text string with indefinite length to the 8-bit number, which can minimize the length of the LW-Objective option, and also can avoid the additional communication cost caused by excessively long objective-name text strings, and the overhead of byte-by-byte comparison and identification of objective-name in the standard GRASP. 4.2.2. REQ-ACK option The REQ-ACK option is used to indicate that the message MUST be acknowledged by the receiver. When a message needs acknowledgment (i.e., the confirmable message), the sender MUST generate the REQ-ACK option and add it to the message to request the receiver to acknowledge. The REQ-ACK option MUST NOT be allowed to appear in the non-confirmable message (like the Discovery message and the Flood Synchronization message) to avoid a large number of ACK messages in a short time. In fragmentary CDDL, a REQ-ACK option follows the pattern: req-ack-option = [O_REQ_ACK, Nonce] Nonce = 0..65535 Nonce is a 16-bit random number and MUST avoid local conflicts. The Nonce generation and conflict prevention mechanisms are described in Section 3.1. 4.2.3. ACK option LW-GRASP also defines an ACK option for acknowledging messages carrying a REQ-ACK option. Upon receiving a message with the REQ-ACK option, as specified in Section 3.1, the LW-GRASP receiver MUST either promptly send an ACK message with a corresponding ACK option; or wait a while for a post-order message in the same direction to be sent and add the ACK option to that message to piggyback acknowledge. The ACK option MUST only be allowed to appear in confirmable Zhu, et al. Expires 3 September 2025 [Page 8] Internet-Draft LW-GRASP March 2025 messages, as discussed in Section 4.3. In fragmentary CDDL, an ACK option follows the pattern: ack-option = [O_ACK, Nonce] Nonce = 0..65535; same as the req-ack option Where, the Nonce MUST be the same as the Nonce in the corresponding REQ-ACK option. 4.3. Lightweight GRASP message LW-GRASP reserves all the message types and values of the standard GRASP, as well as the definitions of each related field. LW-GRASP extends its unicast messages to allow them to carry the REQ-ACK option or the ACK option, enabling LW-GRASP to implement a built-in reliability mechanism. All unicast messages used in the three procedures of discovery, negotiation, and synchronization of LW-GRASP MUST be acknowledged to ensure the reliability and operational efficiency of the interactions. At the same time, these unicast messages are allowed to carry zero or more ACK option(s) to acknowledge the confirmable message belonging to the same or different interaction session(s). In addition, Invalid messages are used to respond to invalid messages and contain related diagnostic information which if lost may affect the subsequent message interactions, thus its acknowledgment is necessary and MUST carry a REQ-ACK option. Similarly, the Invalid message can also carry zero or more ACK option(s) for acknowledgment. The Discovery message and Flood Synchronization message that is multicast, as well as the NOOP message that does not contain actual information, are not allowed to carry the REQ-ACK option or the ACK option, i.e., non-confirmable message, whose definition is the same as the standard GRASP and will not be repeated here. The CDDL definitions for messages with extension( i.e. the confirmable message) for reliability are defined as follows: Zhu, et al. Expires 3 September 2025 [Page 9] Internet-Draft LW-GRASP March 2025 response-message = [M_RESPONSE, session-id, initiator, ttl, req-ack-option, *ack-option, (+locator-option // divert-option), ?objective] ttl = 0..4294967295 ; in milliseconds request-negotiation-message = [M_REQ_NEG, session-id, req-ack-option, *ack-option, objective] request-synchronization-message = [M_REQ_SYN, session-id, req-ack-option, *ack-option, objective] negotiation-message = [M_NEGOTIATE, session-id, req-ack-option, *ack-option,objective] end-message = [M_END, session-id, req-ack-option, *ack-option, accept-option / decline-option] wait-message = [M_WAIT, session-id, req-ack-option, *ack-option, waiting-time] waiting-time = 0..4294967295 ; in milliseconds synch-message = [M_SYNCH, session-id, req-ack-option, *ack-option, objective] invalid-message = [M_INVALID, session-id, req-ack-option, *ack-option, ?any] In addition, LW-GRASP defines an ACK message for immediate acknowledgment. In fragmentary CDDL, an ACK message follows the pattern: ack-message = [M_ACK, ack-option] The Nonce in the ACK option must be the same as the corresponding REQ-ACK option. 4.4. Lightweight GRASP constants * LW_GRASP_LISTEN_PORT(TBD1) A well-known UDP user port that every LW-GRASP-enabled network device MUST listen to for UDP-based messages. * LW_GRASP_ACK_DELAYED_TIME(200 milliseconds) The default maximum waiting time for delayed acknowledgment. Zhu, et al. Expires 3 September 2025 [Page 10] Internet-Draft LW-GRASP March 2025 * LW_GRASP_RETRANS_TIMEOUT(2000 milliseconds) The default timeout is used to determine that a LW-GRASP confirmable message needs to be resent. * MAX_RETRANS(3) The default maximum times of retransmission for confirmable messages. In addition, the constants for LW-GRASP also contain the ALL_LW_GRASP_NEIGHBORS, LW_GRASP_DEF_TIMEOUT, LW_GRASP_DEF_LOOPCT, LW_GRASP_DEF_MAX_SIZE, whose definitions and values are respectively same as the ALL_GRASP_NEIGHBORS, GRASP_DEF_TIMEOUT, GRASP_DEF_LOOPCT, GRASP_DEF_MAX_SIZE in GRASP[RFC8990]. 5. LW-GRASP over CoAP CoAP[RFC7252] is a lightweight, RESTful protocol designed for resource-constrained IoT devices. It enables efficient communication in low-power and low-bandwidth networks, driving its wide adoption in IoT. Considering the growing demand for LW-GRASP and the mature ecosystem of CoAP, the transition from UDP to CoAP would significantly benefit the deployment of LW-GRASP in current IoT networks. Additionally, some works on extending CoAP messaging to work over non-IP network scenarios have been proposed, such as its adaptation to Bluetooth Low Energy (BLE) via CoAP over GATT[CoAPoverGATT], which are of great help for the future LW-GRASP IP-independent extension. This section focuses on the exchange of LW-GRASP over CoAP. 5.1. LW-GRASP over CoAP overview To access the LW-GRASP service over CoAP, this document defines the well-known URI "grasp-coap" (to be assigned by IANA). The /.well- known/grasp-coap URI is used with "coap", "coaps", "coap+tcp", "coaps+tcp", "coaps+ws", or "coap+ws". CoAP maintains two logical sublayers: the request/response sublayer and the message sublayer. However, the request/response mechanism of CoAP conflicts with the interaction procedures of LW-GRASP. In particular, it's challenging to map the multiple rounds of negotiation-related LW-GRASP messages directly to the CoAP request- response. For this reason, and considering the built-in LW-GRASP reliability mechanism, this document utilizes Non-confirmable CoAP messages as carriers for LW-GRASP message distribution. To minimize modifications to CoAP, LW-GRASP over CoAP reuses CoAP messages but does not invoke their associated methods. In LW-GRASP over CoAP, the Zhu, et al. Expires 3 September 2025 [Page 11] Internet-Draft LW-GRASP March 2025 LW-GRASP messages MUST be encapsulated as CoAP payloads with the content-format identifier application/cbor[RFC8949]. Upon receipt of the request with the /.well-known/grasp-coap URI, the CoAP instance MUST parse out the payload and forward it to the LW-GRASP instance, bypassing associated resource processing. The LW-GRASP instance SHOULD handle messages from CoAP according to its specification and SHOULD transmit subsequent messages via CoAP responses or new requests. 5.2. LW-GRASP interaction procedures over CoAP A LW-GRASP discovery process will start with a multicast discovery message(M_DISCOVERY) on the local link, and nodes supporting the discovery objective will respond with discovery response(M_RESPONSE) messages. The LW-GRASP discovery message over CoAP SHOULD use the non-confirmable CoAP multicast Fetch request with the No-Response option[RFC7967] to suppress unnecessary responses and SHOULD use standard CoAP multicast addresses (e.g., 224.0.1.187 for IPv4, FF0X::FD for IPv6[RFC7252]). The discovery response over CoAP SHOULD use the CoAP unicast POST request. The following examples illustrate the LW-GRASP discovery and discovery response messages over CoAP, and the LW-GRASP M_RESPONSE and M_ACK over CoAP SHOULD use the CoAP token and message ID associated with each other for transaction matching: LW-GRASP discovery initiator: (NON-confirmable) FETCH coap://FF02::13/.well-known/grasp-coap Content-format: application/cbor Accept: application/cbor No-Response Payload: LW-GRASP M_DISCOVERY (Non-confirmable) FETCH coap://224.0.1.187/.well-known/grasp-coap Content-format: application/cbor Accept: application/cbor No-Response Payload: LW-GRASP M_DISCOVERY LW-GRASP discovery responder: (Non-confirmable) POST coap://2001:db8::1/.well-known/grasp-coap Content-format: application/cbor Accept: application/cbor Payload: LW-GRASP M_RESPONSE LW-GRASP discovery initiator: (Non-confirmable) 2.04(Changed) Content-format: application/cbor Payload: LW-GRASP M_ACK Zhu, et al. Expires 3 September 2025 [Page 12] Internet-Draft LW-GRASP March 2025 Since the LW-GRASP flooding procedure performs network-wide synchronization by propagating a single flooding message, the LW- GRASP flooding over CoAP SHOULD use the non-confirmable CoAP multicast POST request with the No-Response option. Both the LW- GRASP discovery and flooding over CoAP SHOULD also maintain the relaying instance defined in [RFC8990] to expand the multicast scope. The following example illustrates the LW-GRASP flood message over CoAP: LW-GRASP flooding initiator: (Non-confirmable) POST coap://FF02::13/.well-known/grasp-coap Content-format: application/cbor No-Response Payload: LW-GRASP M_FLOOD The LW-GRASP negotiation is a bidirectional multi-round procedure. The negotiation-related messages over CoAP SHOULD use the non- confirmable CoAP POST request or the their corresponding response. The following examples illustrate a LW-GRASP negotiation procedure over CoAP: Zhu, et al. Expires 3 September 2025 [Page 13] Internet-Draft LW-GRASP March 2025 LW-GRASP negotiation initiator: (Non-confirmable) POST coap://2001:db8::1/.well-known/grasp Content-format: application/cbor Accept: application/cbor Payload: LW-GRASP M_REQ_NEG with lw-objective[objective-num=0,expected-value="A"] LW-GRASP negotiation responder: (Non-confirmable) 2.04(Changed) Content-format: application/cbor Payload: LW-GRASP M_WAIT with O_ACK LW-GRASP negotiation responder: (Non-confirmable) POST coap://2001:db8::2/.well-known/grasp Content-format: application/cbor Accept: application/cbor Payload: LW-GRASP M_NEGOTIATE with O_ACK and lw-objective[objective-num=0,expected-value="B"] LW-GRASP negotiation initiator: (Non-confirmable) 2.04(Changed) Content-format: application/cbor Payload: LW_GRASP M_END with O_ACCEPT and O_ACK LW-GRASP negotiation responder: (Non-confirmable) POST coap://2001:db8::2/.well-known/grasp Content-format: application/cbor No-Response Payload: LW-GRASP M_ACK 6. IP-independent discussion In some IoT scenarios where the need for self-management is urgent, resource-constrained devices in it may not or choose not to support IP connectivity. Therefore, to improve the generality of LW-GRASP and better support the self-management requirements of the IoT, it is necessary to further discuss how LW-GRASP adapts to networks without the IP connection. 6.1. How LW-GRASP adapts to networks without IP The GRASP and its lightweight version LW-GRASP can only work in IP networks, due to the Locator options used by them. The Locator option is used to locate resources, services, devices, and interfaces on the network and is the basis for GRASP and LW-GRASP discovery, negotiation, and synchronization procedures. All the four Locator options defined in [RFC8990] have unique identification capabilities only within an IP network: O_IPv6_LOCATOR, O_IPv4_LOCATOR, Zhu, et al. Expires 3 September 2025 [Page 14] Internet-Draft LW-GRASP March 2025 O_FQDN_LOCATOR, O_URI_LOCATOR, which respectively depend on the IPv6 address, IPv4 address, Fully Qualified Domain Name (FQDN), and Uniform Resource identifier (URI) for identification and location. Therefore, to enable the LW-GRASP to work without the IP connection and provide services to LW-GRASP-enabled nodes, it's necessary to select an identifier(such as the MAC address in the Ethernet) based on the environment and define a new Locator option in the LW-GRASP to identify and locate a device, interface, resource, or service that can remove dependence of the LW-GRASP on IP. Using LW-GRASP without the IP connection requires not only the definition of new Locator options but also the identification of LW- GRASP so that network nodes and devices can recognize LW-GRASP messages encapsulated in specific bearer protocol messages. For example, [RFC8990] designs GRASP as a user program, using a well- known port to identify GRASP messages. In practice, the protocol identification of LW-GRASP should be chosen and extended by the bearer protocol on which it depends, which is out of the scope of this document. 6.2. An example: Exchange LW-GRASP over BLE In the IoT, where the need for self-management is more urgent, the memory, energy, and computation overheads associated with IP connectivity and transmission may be unacceptable for its resource- constrained devices. In addition, considering the episodic feature of information interactions between IoT devices, some resource- constrained devices may prefer to use low-power and low-bandwidth network connections based on technologies such as Bluetooth Low Energy and Zigbee rather than IP connections. This section discusses how to adapt LW-GRASP to BLE environments without IP connectivity. The core protocol used to establish and manage communication between devices in BLE is the Generic Attribute Profile (GATT, Volume 3 PART G in [BTCorev5.4]), which defines how data is transferred between two BLE devices based on the concepts of Services and Characteristics. In BLE, data is transferred and stored in the form of Characteristics, and the Service is a collection of Characteristics, both identified by a unique numeric ID called UUID. GATT is at the top layer of the BLE stack and can provide API interfaces directly to the upper-layer applications, so it is possible to discuss the LW- GRASP-over-GATT to exchange LW-GRASP over BLE. LW-GRASP-over-GATT can define and use one or more GATT Characteristic(s) to transport LW-GRASP messages. With the unique identification UUID of the GATT Characteristic, the device can easily recognize whether the transmitted data is a LW-GRASP message or not. Zhu, et al. Expires 3 September 2025 [Page 15] Internet-Draft LW-GRASP March 2025 Regarding address identification, BLE devices use a 48-bit device address as a device identifier[BTCorev5.4]. As described in Section 6.1, the LW-GRASP-over-GATT should define and register a new Locator option based on this identifier. However, since the read/write semantics of the GATT characteristic do not fully match the semantics of the actions associated with the LW- GRASP interaction procedures, how to bridge this gap is an important step in realizing LW-GRASP-over-GATT. In addition, BLE provides both reliable ("write without response", "notify") and unreliable ("write with response", "indicate") data transmission, and how to choose between the two modes of data transmission for LW-GRASP-over-GATT needs to be carefully considered. 7. IANA Considerations 7.1. IANA considerations for LW-GRASP This document defines the Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP). As specified in Section 4.4, the IANA is requested to assign a USER PORT(LW_GRASP_LISTEN_PORT, TBD1) for use by LW-GRASP over UDP. Like the standard GRASP, LW-GRASP also requires IANA to create the "Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP) Parameters" registry. The "Lightweight GeneRic Autonomic Signaling Protocol (LW-GRASP) Parameters" should also include two subregistries: "LW-GRASP Messages and Options" and "LW-GRASP Objective Numbers". The "LW-GRASP Messages and Options" MUST retain all the entries in the "GRASP Messages and Options" subregistry assigned for the standard GRASP, and MUST also add three entries for the new message named "M_ACK", and the two new options named "O_REQ_ACK" and "O_ACK", whose initial values assigned by this document are like the following: M_ACK = 10 O_REQ_ACK = 107 O_ACK = 108 The initial numbers for the "LW-GRASP Objective Numbers" subregistry assigned by this document are like the following: Zhu, et al. Expires 3 September 2025 [Page 16] Internet-Draft LW-GRASP March 2025 0-9 for Experimental 10-255 Unassigned 7.2. IANA considerations for LW-GRASP over CoAP Considerations for IANA regarding LW-GRASP over CoAP in this document are: * Assignment of the URI /.well-known/grasp-coap * Assignment of the media type "application/grasp-coap" * Assignment of the content format "application/grasp-coap" * Assignment of the resource type (rt=) "core.grasp-coap" 8. Security Considerations 8.1. Security considerations for LW-GRASP As a lightweight version of GRASP, LW-GRASP must attach importance to the security considerations of GRASP discussed in [RFC8990]. In addition, given the limited capabilities and weak tamper resistance of constrained nodes, as well as their possible exposure to insecure environments, security issues associated with constrained nodes must not be ignored by the external secure infrastructure (e.g., the ACP) on which the LW-GRASP is based, e.g., the constrained code space and CPU for implementing cryptographic primitives. 8.2. Security considerations for LW-GRASP over CoAP LW-GRASP over CoAP should also concern all GRASP and LW-GRASP related security consideratiosns. TODO more security considerations. 9. References 9.1. Normative References [BTCorev5.4] Bluetooth Special Interest Group, "BLUETOOTH CORE SPECIFICATION Version 5.4", 31 January 2023, . Zhu, et al. Expires 3 September 2025 [Page 17] Internet-Draft LW-GRASP March 2025 [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, . 9.2. Informative References [CoAPoverGATT] "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, . Zhu, et al. Expires 3 September 2025 [Page 18] Internet-Draft LW-GRASP March 2025 [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, . Authors' Addresses Longwei Zhu Beijing University of Posts and Telecommunications No. 10 Xitucheng Road Haidian District, Beijing China Email: lwzhu@bupt.edu.cn Sheng Jiang Beijing University of Posts and Telecommunications No. 10 Xitucheng Road Haidian District, Beijing China Email: shengjiang@bupt.edu.cn Cheng Sheng Huawei Technologies Q14 Huawei Campus, No.156 Beiqing Road. Beijing China Email: shengcheng@huawei.com Zhu, et al. Expires 3 September 2025 [Page 19]