Beijing University of Posts and Telecommunications

No. 10 Xitucheng Road Haidian District, Beijing China lwzhu@bupt.edu.cn

Beijing University of Posts and Telecommunications

No. 10 Xitucheng Road Haidian District, Beijing China shengjiang@bupt.edu.cn

Huawei Technologies

Q14 Huawei Campus, No.156 Beiqing Road. Beijing China shengcheng@huawei.com

Operations and Management ANIMA This document proposes the Constrained GeneRic Autonomic Signaling Protocol (cGRASP), a constrained and lightweight variant of the GeneRic Autonomic Signaling Protocol (GRASP, or the standard GRASP). cGRASP reduces message overhead and replaces TCP with CoAP as the transport protocol. By leveraging CoAP's reliability features and deployment maturity, cGRASP can provide reliable signaling services without relying on TCP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential approaches to adapting the cGRASP to work on the network without IP connectivity.

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 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, 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, 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 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. Obviously, in the IoT networks 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. CoAP is a lightweight, RESTful protocol designed for resource-constrained IoT devices, featuring reliability mechanisms such as acknowledgements, retransmissions, and basic congestion control. It enables efficient communication in low-power and low-bandwidth networks, driving its wide adoption in IoT. Considering the demand for self-management and the resource-constrained nature of IoT devices, as well as the wide adoption and mature ecosystem of CoAP in low-power and low-bandwidth networks, this document proposes a constrained and lightweight variant of GRASP (cGRASP), a constrained and lightweight variant of GRASP that replaces TCP with CoAP. 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, which are of great help for the future cGRASP IP-independent extension. The cGRASP simplifies the objective option and retains GRASP multicast relay mechanism. By reducing message encoding size and processing overhead, and by leveraging the reliability mechanism provided CoAP, cGRASP enables reliable signaling services without relying on TCP. cGRASP is specifically targeted at constrained nodes as defined in , particularly class C1 and C2 devices that are capable of supporting CoAP but not TCP. A representative targeted scenario is Industrial IoT edge coordination: distributed edge controllers and smart equipment(C2 devices) collaboratively manage configuration and status data within a local CoAP/UDP domain, where devices use cGRASP discovery and synchronization messages to autonomically advertise capabilities, propagate firmware-state updates, and align configuration parameters without a central server. This enables lightweight, scalable device management and state synchronization without dependence on TCP-based protocols or centralized configuration services. While Class C0 devices typically lack IP connectivity, the possible IP-independent extension is also discussed, which can extend the use of cGRASP to non-IP networks. By extending Autonomic Network Infrastructure (ANI) signaling capabilities to constrained devices, cGRASP helps realize lightweight, scalable, and self-managing IoT systems.

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 when, and only when, they appear in all capitals, as shown here.

cGRASP redefines the standard GRASP Objective option as the cGRASP Objective option, by using a numeric objective identifier to minimize encoding overhead. This is particularly beneficial for constrained nodes with limited processing or transmission capabilities. cGRASP retains the GRASP message set and procedures, except that the base cGRASP profile does not support M_WAIT and redefines the Objective option. Mapping M_WAIT to CoAP would require a node to retain negotiation state across disconnected CoAP exchanges and to initiate a new request when the negotiation is resumed. This introduces additional state management and client/server role-reversal complexity, which is inconsistent with the goal of keeping the base cGRASP profile simple for constrained nodes. Applications requiring additional processing time may use an appropriate negotiation timeout or terminate the current negotiation and initiate a new cGRASP session when they are ready to continue. Support for suspended and subsequently resumed negotiations, including an M_WAIT mapping, may be defined by a future extension. In addition, cGRASP still adheres to the High-Level Deployment Model and High-Level Design defined for GRASP, ensuring compatibility with the overall signaling architecture and objectives of the protocol. This section focuses on the cGRASP-specific enhancements to the GRASP.

Like standard GRASP, cGRASP messages continue to be transmitted in Concise Binary Object Representation (CBOR) and be described using Concise Data Definition Language (CDDL). In fragmentary CDDL, a cGRASP Objective option follows the pattern:

Instead of using a text string (i.e., objective-name) as the unique identifier for the Objective option, the cGRASP Objective option uses an unsigned integer in the range 0 - 255 (i.e., objective-num) as its identifier. The remaining fields of the cGRASP Objective option remain consistent with those defined in the standard GRASP. Objective numbers in the range 0 - 191 are reserved for generic cGRASP Objectives, while numbers in the range 192 - 255 are reserved for privately defined cGRASP Objectives. Each generic cGRASP Objective MUST be assigned a unique objective number and be publicly registered for use by all cGRASP nodes. When a private cGRASP Objective is defined, it MUST also be assigned a uniquely distinguishable objective number and be made public within the specific private domain. In cGRASP, the identifier of the cGRASP Objective option is changed from a text string to an unsigned integer in the range 0 - 255. This can minimize the size of the encoded cGRASP Objective option, avoid the additional communication cost caused by excessively long objective-name text strings, and eliminate the processing cost of byte-by-byte comparison required in standard GRASP.

ALL_CGRASP_NEIGHBORS identifies the applicable cGRASP multicast group. For IPv6 link-local operation, its value is FF02::FD. For IPv4 operation, its value is 224.0.1.187. In addition, the constants for cGRASP also contain the CGRASP_DEF_TIMEOUT, CGRASP_DEF_LOOPCT, CGRASP_DEF_MAX_SIZE, whose definitions and values are respectively same as the GRASP_DEF_TIMEOUT, GRASP_DEF_LOOPCT, GRASP_DEF_MAX_SIZE in GRASP.

Considering the growing demand for cGRASP and the mature ecosystem of CoAP, utilizing CoAP would significantly benefit the deployment of cGRASP in current IoT networks. This section focuses on the exchange of CoAP-based cGRASP.

To access the cGRASP 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 cGRASP. In particular, it's challenging to map the multiple rounds of negotiation-related cGRASP messages directly to the CoAP request-response. For this reason, this document utilizes confirmable CoAP messages as carriers for reliable cGRASP message distribution. To minimize modifications to CoAP, cGRASP over CoAP reuses CoAP messages and defines specific semantics for applying the POST and FETCH methods to the cGRASP resource. In CoAP-based cGRASP, the cGRASP messages MUST be encapsulated as CoAP payloads with the content-format identifier application/cbor. 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 cGRASP instance, bypassing associated resource processing. The cGRASP instance SHOULD handle messages from CoAP according to its specification and SHOULD transmit subsequent messages via separate CoAP responses or new requests. The cGRASP session-id carried in the cGRASP payload identifies the cGRASP protocol session. A CoAP Token MUST NOT be used as a persistent identifier for a cGRASP session. For a unicast cGRASP interaction, an implementation SHOULD associate session state with the combination of the peer transport endpoint and the cGRASP session-id. For relayed discovery, the session-id and initiator Locator are used to correlate the discovery request and corresponding M_RESPONSE messages. Each CoAP request and its corresponding response form an independent CoAP exchange. The response, whether piggybacked or separate, MUST carry the same Token as the corresponding request. A subsequent CoAP request belonging to the same cGRASP session MUST use a Token that is not in use by another outstanding request, and SHOULD use a newly generated Token. It MUST also use a fresh Message ID. If message retransmission is required, the original confirmable message MUST be retransmitted with the same message ID and token, ensuring the recipient can identify and suppress duplicates appropriately. Since cGRASP does not define any internal idempotency mechanism, recipients of duplicate confirmable messages SHOULD NOT reprocess the cGRASP message logic. Instead, they SHOULD retransmit the original ACK or RST, along with any associated response, if applicable. Relaxed duplicate handling strategies permitted by CoAP for idempotent requests (e.g., GET or PUT) MUST NOT be applied to cGRASP messages unless explicitly specified in future extensions that define cGRASP-level idempotency.

The cGRASP negotiation is a bidirectional multi-round procedure, whereas synchronization can be considered a single-round negotiation. The negotiation-related and synchronization-related messages over CoAP SHOULD use the confirmable CoAP POST request or their corresponding response(separate or piggybacked). The following examples illustrate a cGRASP negotiation procedure over CoAP:

The following examples illustrate a cGRASP synchronization procedure over CoAP:

A cGRASP 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 cGRASP discovery message over CoAP SHOULD use the non-confirmable CoAP multicast Fetch request and SHOULD use standard CoAP multicast addresses (e.g., 224.0.1.187 for IPv4, FF0X::FD for IPv6). The request MUST permit successful Discovery Responses and therefore MUST NOT use a No-Response value that suppresses such responses. It MAY suppress only error responses. The discovery response over CoAP SHOULD be carried as a unicast 2.05 (Content) response to the corresponding Discovery request. A Confirmable response SHOULD be used when reliable hop-by-hop delivery is required. The following examples illustrate the cGRASP discovery and discovery response messages over CoAP:

Since the cGRASP flooding procedure performs network-wide synchronization by propagating a single flooding message, the cGRASP flooding over CoAP SHOULD use the non-confirmable CoAP multicast POST request with the No-Response option. The following example illustrates the cGRASP flood message over CoAP:

This section specifies the requirements and procedures for implementing cGRASP relay functionality over CoAP. Since CoAP multicast communication is typically limited to a single link, relaying is required to extend the scope of cGRASP Discovery and Flood Synchronization across multiple links. A node implementing this function is referred to as a cGRASP relaying instance. Such an instance MUST comply with the GRASP relaying behavior defined in and the CoAP-specific requirements described in this section. A cGRASP relaying instance terminates an incoming CoAP exchange and originates a new CoAP exchange on each outgoing interface. During this process, the cGRASP session-id and initiator fields MUST remain unchanged, while the CoAP Message ID and Token have hop-by-hop significance only. The relaying instance MUST maintain relay state for each forwarded Discovery or Flood Synchronization message. Discovery relay state and Flood duplicate-suppression state MAY be stored in a common cache, but they MUST be logically distinguished. Each relay entry MUST be uniquely identified by the cGRASP message type together with the following fields: (session-id, initiator-Locator) . The message type distinguishes between Discovery and Flood Synchronization transactions. An M_RESPONSE MUST be matched to the corresponding M_DISCOVERY relay entry using its session-id and initiator-Locator, and MUST NOT be treated as an independent relay type. Each relay entry MUST record the incoming cGRASP-enabled interface and an expiration time. For M_DISCOVERY, the relay entry MUST additionally record the upstream transport endpoint (including source IP address and UDP port) and the CoAP Token from the upstream request. This Token MUST be used only for constructing the upstream response and MUST NOT be reused in downstream requests. For M_FLOOD, no upstream Token or endpoint information is required. Before forwarding a received message, the relaying instance MUST perform the following eligibility checks: The relaying instance MUST have more than one cGRASP-enabled interface. Only multicast M_DISCOVERY and M_FLOOD messages received via CoAP group communication are eligible for relaying. Other cGRASP message types MUST NOT be relayed using the procedures defined in this section. For M_DISCOVERY, if the relaying instance locally supports the requested Objective, it SHOULD respond locally and MUST NOT relay the message solely to extend its scope. If a valid cached response is available, the relaying instance SHOULD return an M_RESPONSE containing that information instead of relaying the Discovery request. After passing the eligibility checks, the relaying instance MUST examine the loop-count field in the cGRASP Objective. If the value is zero, the message MUST be discarded. Otherwise, the value MUST be decremented by one. If the resulting value is zero, the message MUST NOT be forwarded further. Before forwarding, the relaying instance MUST check for an existing, non-expired relay entry with the same message type, session-id, and initiator-Locator. If such an entry exists, the message MUST be treated as a duplicate and MUST NOT be relayed again. Duplicate messages MUST NOT overwrite existing relay state. If the message is eligible for forwarding, the relaying instance MUST create the relay entry before transmitting downstream requests. It MUST then originate a new CoAP request on each eligible cGRASP-enabled interface except the incoming interface. The relayed CoAP request MUST: use the same CoAP method as the received request; carry the relayed cGRASP message encoded in CBOR; preserve the original session-id and initiator; include the decremented loop-count; use a newly generated CoAP Message ID; use a newly generated CoAP Token; be transmitted as a Non-confirmable multicast request. For M_FLOOD, the relayed request SHOULD include a No-Response option, since no response is expected. A relayed M_DISCOVERY request MUST permit successful Discovery Responses. It therefore MUST NOT use a No-Response option that suppresses 2.xx responses. It MAY omit the No-Response option or use a value that suppresses only error responses. When a relaying instance receives a CoAP response carrying an M_RESPONSE, it MUST first associate the response with the corresponding downstream Discovery request using the CoAP Token. It MUST then verify that the session-id and initiator-Locator match an existing relay entry. If no matching, non-expired Discovery relay entry exists, the response MUST be discarded. If a matching relay entry is found, the relaying instance MUST return the response to the recorded upstream endpoint as a new unicast CoAP response. This upstream response MUST: use response code 2.05 (Content); use the Token recorded from the upstream request; use a newly generated CoAP Message ID; carry the M_RESPONSE payload unchanged. When reliable hop-by-hop delivery is required, the upstream response SHOULD be sent as a Confirmable message. The response MUST NOT be returned as a new CoAP POST request. A Discovery relay entry MUST NOT be removed upon receipt of the first M_RESPONSE, as multiple responders may exist. The entry SHOULD remain valid until the response window expires or the configured timeout is reached. The expiration time for a relayed M_DISCOVERY SHOULD be determined based on the remaining loop-count and expected per-hop delay. A default value of 100 milliseconds multiplied by the remaining loop-count, as suggested in , MAY be used. Deployments in constrained or high-latency environments SHOULD use a larger value. The expiration time for a relayed M_FLOOD MUST be no less than: 2 * CGRASP_DEF_TIMEOUT. Finally, a relaying instance MUST implement appropriate rate and resource controls for relayed multicast requests and returned Discovery responses. These controls SHOULD limit the number of active relay entries, the multicast forwarding rate, and the number of responses forwarded per Discovery transaction. Implementations MAY use fixed rate limiting or a Trickle-based mechanism .

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 cGRASP and better support the self-management requirements of the IoT, it is necessary to further discuss how cGRASP adapts to networks without the IP connection.

The GRASP and its constrained version cGRASP 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 cGRASP discovery, negotiation, and synchronization procedures. All the four Locator options defined in have unique identification capabilities only within an IP network: O_IPv6_LOCATOR, O_IPv4_LOCATOR, 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 cGRASP to work without the IP connection and provide services to cGRASP-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 cGRASP to identify and locate a device, interface, resource, or service that can remove dependence of the cGRASP on IP. Using cGRASP without the IP connection requires not only the definition of new Locator options but also the identification of cGRASP so that network nodes and devices can recognize cGRASP messages encapsulated in specific bearer protocol messages. For example, designs GRASP as a user program, using a well-known port to identify GRASP messages. In practice, the protocol identification of cGRASP should be chosen and extended by the bearer protocol on which it depends, which is out of the scope of this document.

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 cGRASP 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 ), 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 cGRASP-over-GATT to exchange cGRASP over BLE. cGRASP-over-GATT can define and use one or more GATT Characteristic(s) to transport cGRASP messages. With the unique identification UUID of the GATT Characteristic, the device can easily recognize whether the transmitted data is a cGRASP message or not. Regarding address identification, BLE devices use a 48-bit device address as a device identifier. As described in , the cGRASP-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 cGRASP interaction procedures, how to bridge this gap is an important step in realizing cGRASP-over-GATT. In addition, BLE provides both reliable ("write with response", "indicate") and unreliable ("write without response", "notify") data transmission, and how to choose between the two modes of data transmission for cGRASP-over-GATT needs to be carefully considered.

This document defines the Constrained GeneRic Autonomic Signaling Protocol (cGRASP). Like the standard GRASP, cGRASP also requires IANA to create the "Constrained GeneRic Autonomic Signaling Protocol (cGRASP) Parameters" registry. The "Constrained GeneRic Autonomic Signaling Protocol (cGRASP) Parameters" should also include two subregistries: "cGRASP Messages and Options" and "cGRASP Objective Numbers". The "cGRASP Messages and Options" MUST retain all the entries in the "GRASP Messages and Options" subregistry assigned for the standard GRASP. M_WAIT retains its GRASP code point for compatibility and future extension, but it is not supported by the base cGRASP profile. The initial numbers for the "cGRASP Objective Numbers" subregistry assigned by this document are like the following:

Considerations for IANA regarding CoAP-based transmission for cGRASP 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-cbor" * Assignment of the resource type (rt=) "core.grasp-coap"

As a constrained version of GRASP, cGRASP must attach importance to the security considerations of GRASP discussed in . 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, e.g., the constrained code space and CPU for implementing cryptographic primitives. TODO more security considerations.

Bluetooth Special Interest Group

This appendix describles an informative description UDP-based cGRASP(proposed in previous versions), which is designed to be a constrained and lightweight version of the GeneRic Autonomic Signaling Protocol(GRASP, or the standard GRASP), with shortened messages and a built-in reliability mechanism. UDP-based cGRASP can work reliably over UDP, making it suitable for IoT, where lightweight and resource- constrained devices dominate. In this appendix, cGRASP stands for UDP-based cGRASP rather than CoAP-based cGRASP.

UDP-based cGRASP is designed to avoid the additional control overhead and memory consumption caused by TCP, thus matching the capabilities of IoT nodes. Meanwhile, to ensure reliability, the UDP-based cGRASP introduces a message-oriented built-in reliability mechanism. UDP-based cGRASP 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 , not all cGRASP messages require acknowledgment, such as multicast messages. The UDP-based cGRASP messages that require acknowledgment are referred to in this document as confirmable 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.

When sending a confirmable message, the UDP-based cGRASP 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 CGRASP_ACK_DELAYED_TIME. The latter is the delayed acknowledgment, if there is no corresponding message to be sent within the CGRASP_ACK_DELAYED_TIME, an ACK message MUST be sent immediately. UDP-based cGRASP 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 cGRASP 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 , , and , respectively. The Nonce can be regarded as the unique identifier of a confirmable message before it is acknowledged. Thus, the cGRASP 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 cGRASP instance SHOULD create and maintain a Nonce cache to record the Nonce used by confirmable messages. After generating a Nonce for a message, the cGRASP 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 cGRASP 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 cGRASP node SHOULD mark the Nonce entry as acknowledged and delete it when the corresponding cGRASP session is completed. It is worth emphasizing that confirmable messages marked as acknowledged SHOULD also be considered by the aforementioned Nonce conflict detection. The cGRASP sender MUST set the retransmission timer when sending a confirmable message; see for details on setting the timeout. If the cGRASP confirmable message does not get an acknowledgment within the retransmission timeout, then the message MUST be retransmitted. The retransmitted message SHOULD retain the same Nonce 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 cGRASP can not identify the retransmission message and will repeatedly process it, which can be dangerous. Thus, the cGRASP receiver SHOULD record and cache the Nonces of confirmable messages that have been received and processed for each cGRASP 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, cGRASP 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 cGRASP implementation, users SHOULD be allowed to enable or completely disable delayed acknowledgment according to their needs.

The retransmission timeout for reliable transmission of cGRASP messages is CGRASP_RETRANS_TIMEOUT. If the cGRASP 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 cGRASP 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.

cGRASP 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, cGRASP redefines the Objective option in standard GRASP as the cGRASP Objective option and defines a new message named ACK message, along with two new options named REQ-ACK option and ACK option. However, cGRASP does not modify the discovery, negotiation, synchronization, and flooding procedures, as well as the defined options (except for the Objective option) of the standard GRASP. In addition, cGRASP 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, cGRASP instances SHOULD listen for messages using a new well-known port, CGRASP_LISTEN_PORT (TBD1).

Like standard GRASP, cGRASP messages continue to be transmitted in Concise Binary Object Representation (CBOR) and be described using Concise Data Definition Language (CDDL). The session-id in the cGRASP 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 cGRASP message follows the pattern:

Same as the .

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:

Nonce is a 16-bit random number and MUST avoid local conflicts. The Nonce generation and conflict prevention mechanisms are described in .

cGRASP 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 , the cGRASP 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 messages, as discussed in . In fragmentary CDDL, an ACK option follows the pattern:

Where, the Nonce MUST be the same as the Nonce in the corresponding REQ-ACK option.

cGRASP reserves all the message types and values of the standard GRASP, as well as the definitions of each related field. cGRASP extends its unicast messages to allow them to carry the REQ-ACK option or the ACK option, enabling cGRASP to implement a built-in reliability mechanism. All unicast messages used in the three procedures of discovery, negotiation, and synchronization of cGRASP 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:

In addition, cGRASP defines an ACK message for immediate acknowledgment. In fragmentary CDDL, an ACK message follows the pattern:

The Nonce in the ACK option must be the same as the corresponding REQ-ACK option.

CGRASP_LISTEN_PORT(TBD1)A well-known UDP user port that every cGRASP-enabled network device MUST listen to for UDP-based messages. CGRASP_ACK_DELAYED_TIME(200 milliseconds)The default maximum waiting time for delayed acknowledgment. CGRASP_RETRANS_TIMEOUT(2000 milliseconds)The default timeout is used to determine that a cGRASP confirmable message needs to be resent. MAX_RETRANS(3)The default maximum times of retransmission for confirmable messages. In addition, the constants for cGRASP also contain the ALL_CGRASP_NEIGHBORS, CGRASP_DEF_TIMEOUT, CGRASP_DEF_LOOPCT, CGRASP_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.

This document defines the Constrained GeneRic Autonomic Signaling Protocol (cGRASP). As specified in , the IANA is requested to assign a USER PORT(CGRASP_LISTEN_PORT, TBD1) for use by cGRASP over UDP. Like the standard GRASP, cGRASP also requires IANA to create the "Constrained GeneRic Autonomic Signaling Protocol (cGRASP) Parameters" registry. The "Constrained GeneRic Autonomic Signaling Protocol (cGRASP) Parameters" should also include two subregistries: "cGRASP Messages and Options" and "cGRASP Objective Numbers". The "cGRASP 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:

The initial numbers for the "cGRASP Objective Numbers" subregistry assigned by this document are like the following:

As a constrained version of GRASP, cGRASP must attach importance to the security considerations of GRASP discussed in . 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 cGRASP is based, e.g., the constrained code space and CPU for implementing cryptographic primitives.