



ANIMA                                                             L. Zhu
Internet-Draft                                                  S. Jiang
Intended status: Standards Track                                    BUPT
Expires: 21 January 2026                                        C. Sheng
                                                     Huawei Technologies
                                                            20 July 2025


            Constrained GeneRic Autonomic Signaling Protocol
                 draft-ietf-anima-constrained-grasp-01

Abstract

   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.

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 21 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Zhu, et al.              Expires 21 January 2026                [Page 1]

Internet-Draft                   cGRASP                        July 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  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  cGRASP enhancements to the GRASP  . . . . . . . . . . . . . .   5
     3.1.  cGRASP Objective option . . . . . . . . . . . . . . . . .   5
     3.2.  cGRASP constants  . . . . . . . . . . . . . . . . . . . .   6
   4.  CoAP-based transmission for cGRASP  . . . . . . . . . . . . .   6
     4.1.  CoAP-based cGRASP overview  . . . . . . . . . . . . . . .   6
     4.2.  cGRASP interaction procedures over CoAP . . . . . . . . .   7
       4.2.1.  cGRASP negotiation and synchronization over CoAP  . .   7
       4.2.2.  cGRASP discovery and flooding over CoAP . . . . . . .   9
       4.2.3.  cGRASP relay over CoAP  . . . . . . . . . . . . . . .  10
   5.  IP-independent discussion . . . . . . . . . . . . . . . . . .  11
     5.1.  How cGRASP adapts to networks without IP  . . . . . . . .  12
     5.2.  An example: Exchange cGRASP over BLE  . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  UDP-based GRASP  . . . . . . . . . . . . . . . . . .  16
     A.1.  Built-in reliability mechanism  . . . . . . . . . . . . .  16
       A.1.1.  Reliable transmission for confirmable cGRASP
               messages  . . . . . . . . . . . . . . . . . . . . . .  16
       A.1.2.  Retransmission and retransmission timeout . . . . . .  18
     A.2.  UDP-based cGRASP definition . . . . . . . . . . . . . . .  18



Zhu, et al.              Expires 21 January 2026                [Page 2]

Internet-Draft                   cGRASP                        July 2025


       A.2.1.  cGRASP message format . . . . . . . . . . . . . . . .  18
       A.2.2.  cGRASP option . . . . . . . . . . . . . . . . . . . .  19
       A.2.3.  cGRASP message  . . . . . . . . . . . . . . . . . . .  20
       A.2.4.  cGRASP constants  . . . . . . . . . . . . . . . . . .  21
     A.3.  IANA Considerations . . . . . . . . . . . . . . . . . . .  22
     A.4.  Security Considerations . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

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



Zhu, et al.              Expires 21 January 2026                [Page 3]

Internet-Draft                   cGRASP                        July 2025


   of memory.  However, the resource-constrained device typically has
   only about 50KB of memory[RFC7228].  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[RFC7252] 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[RFC7252] 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[CoAPoverGATT], 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 [RFC7228], particularly class C1 and C2 devices that
   are capable of supporting CoAP but not TCP.  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.









Zhu, et al.              Expires 21 January 2026                [Page 4]

Internet-Draft                   cGRASP                        July 2025


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.  cGRASP enhancements to the GRASP

   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 discovery, negotiation, synchronization, and flooding
   procedures, as well as the defined messages and 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, ensuring compatibility with the overall
   signaling architecture and objectives of the protocol.  To
   distinguish cGRASP from standard GRASP instances, cGRASP instances
   SHOULD listen for incoming messages on a new well-known port,
   CGRASP_LISTEN_PORT (TBD1).  This section focuses on the cGRASP-
   specific enhancements to the GRASP.

3.1.  cGRASP Objective option

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

    cGRASP 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 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



Zhu, et al.              Expires 21 January 2026                [Page 5]

Internet-Draft                   cGRASP                        July 2025


   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.

3.2.  cGRASP constants

   *  CGRASP_LISTEN_PORT(TBD1)

      A well-known user port that every cGRASP-enabled network device
      MUST listen to for cGRASP 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[RFC8990].

4.  CoAP-based transmission for cGRASP

   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.

4.1.  CoAP-based cGRASP overview

   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



Zhu, et al.              Expires 21 January 2026                [Page 6]

Internet-Draft                   cGRASP                        July 2025


   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
   but does not invoke their associated methods.  In CoAP-based cGRASP,
   the cGRASP 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 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.

   To ensure correct correlation between CoAP requests and responses
   within a cGRASP session, each cGRASP session over CoAP MUST use a
   unique CoAP Token generated by the initiating node.  This Token MUST
   be used consistently across all CoAP messages related to the same
   cGRASP session and MUST NOT be reused across different sessions.
   Once a session concludes, either successfully (e.g., upon receiving a
   valid M_END message) or due to failure or timeout, the associated
   Token SHOULD be considered expired and discarded.

   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.

4.2.  cGRASP interaction procedures over CoAP

4.2.1.  cGRASP negotiation and synchronization over CoAP

   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:





Zhu, et al.              Expires 21 January 2026                [Page 7]

Internet-Draft                   cGRASP                        July 2025


   cGRASP negotiation initiator:
    Header: POST (T=Con, Code=0.02, MID=0x7d38)
    Token: 0x53
    Uri: coap://2001:db8::1/.well-known/grasp
    Content-format: application/cbor
    Accept: application/cbor
    Payload: cGRASP M_REQ_NEG
    with cGRASP objective[objective-num=0,expected-value="A"]

   cGRASP negotiation responder:
    Header: (T=ACK, Code=0.00, MID=0x7d38)

    Header: 2.04(Changed) (T=Con, Code=2.04, MID=0xad7b)
    Token: 0x53
    Content-format: application/cbor
    Payload: cGRASP M_WAIT

   cGRASP negotiation initiator:
    Header: (T=ACK, Code=0.00, MID=0xad7b)

    Header: POST (T=Con, Code=0.02, MID=0x7d39)
    Token: 0x53
    Uri: coap://2001:db8::2/.well-known/grasp
    Content-format: application/cbor
    Accept: application/cbor
    Payload: cGRASP M_NEGOTIATE
    and cGRASP objective[objective-num=0,expected-value="B"]

   cGRASP negotiation responder:
    Header: (T=ACK, Code=0.00, MID=0x7d39)

    Header: 2.04(Changed) (T=Con, Code=2.04, MID=0xad7c)
    Token: 0x53
    Content-format: application/cbor
    Payload: cGRASP M_END with O_ACCEPT

   cGRASP negotiation initiator:
    Header: (T=ACK, Code=0.00, MID=0xad7c)

   The following examples illustrate a cGRASP synchronization procedure
   over CoAP:










Zhu, et al.              Expires 21 January 2026                [Page 8]

Internet-Draft                   cGRASP                        July 2025


   cGRASP synchronization initiator:
    Header: POST (T=Con, Code=0.02, MID=0x7d28)
    Token: 0x54
    Uri: coap://2001:db8::1/.well-known/grasp
    Content-format: application/cbor
    Accept: application/cbor
    Payload: cGRASP M_REQ_SYN
    with cGRASP objective[objective-num=0,value = ""]

   cGRASP synchronization responder:
    Header: (T=ACK, Code=0.00, MID=0x7d28)

    Header: 2.04(Changed) (T=Con, Code=2.04, MID=0xad8c)
    Token: 0x54
    Content-format: application/cbor
    Payload: cGRASP M_SYNCH
    with cGRASP objective[objective-num=0,value = "A"]

   cGRASP synchronization initiator:
    Header: (T=ACK, Code=0.00, MID=0xad8c)

4.2.2.  cGRASP discovery and flooding 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 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 cGRASP discovery and discovery response messages over CoAP:


















Zhu, et al.              Expires 21 January 2026                [Page 9]

Internet-Draft                   cGRASP                        July 2025


   cGRASP discovery initiator:
    Header: FETCH (T=Non, Code=0.05, MID=0x7d28)
    Token: 0x55
    Uri: coap://FF02::13/.well-known/grasp-coap
    Content-format: application/cbor
    Accept: application/cbor
    No-Response
    Payload: cGRASP M_DISCOVERY

    Header: FETCH (T=Non, Code=0.05, MID=0x7d59)
    Token: 0x56
    Uri: coap://224.0.1.187/.well-known/grasp-coap
    Content-format: application/cbor
    Accept: application/cbor
    No-Response
    Payload: cGRASP M_DISCOVERY

   cGRASP discovery responder:
    Header: POST (T=Con, Code=0.02, MID=0xad58)
    Token: 0x57
    Uri: coap://2001:db8::1/.well-known/grasp-coap
    Content-format: application/cbor
    Accept: application/cbor
    Payload: cGRASP M_RESPONSE

   cGRASP discovery initiator:
    Header: (T=ACK, Code=0.00, MID=0xad58)

   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:

   cGRASP flooding initiator:
    Header: POST (T=Non, Code=0.02, MID=0x7d28)
    Token: 0x58
    Uri: coap://FF02::13/.well-known/grasp-coap
    Content-format: application/cbor
    No-Response
    Payload: cGRASP M_FLOOD

4.2.3.  cGRASP relay over CoAP

   Given that CoAP lacks the hop-by-hop multicast, both the cGRASP
   discovery and flooding over CoAP SHOULD also maintain the relaying
   instance defined in [RFC8990] to expand the multicast scope.



Zhu, et al.              Expires 21 January 2026               [Page 10]

Internet-Draft                   cGRASP                        July 2025


   Once receiving a multicast cGRASP flood synchronization or a
   discovery message from CoAP instance, the cGRASP relaying instance
   MUST perform the following steps:

   1.  Loop count check: If the 'loop-count' field is zero, the message
       MUST be discarded.  Otherwise, the loop count MUST be decremented
       by one when relaying.

   2.  Duplicate suppression: The relaying instance MUST maintain a
       cache of '(session ID, initiator locator)' pairs for received
       flood messages.  If a message with the same session ID and
       initiator has already been relayed within a configured period
       (not less than twice CGRASP_DEF_TIMEOUT), it MUST be discarded to
       avoid re-flooding and a loop.

   3.  Relay behavior: If eligible for relaying, the cGRASP message MUST
       be encapsulated into a newly constructed CoAP request message
       with the same method as the incoming message and fresh transport-
       level metadata (e.g., CoAP Message ID and Token) to ensure
       correct processing by downstream nodes and to prevent ambiguity
       or duplication.  The new CoAP request MUST then be transmited via
       link-local multicast on all cGRASP-enabled interfaces, excluding
       the interface on which the original message was received.The
       session ID and initiator locator in the relayed message MUST
       remain unchanged.

   In addition, the cGRASP relaying instance MUST enforce a reasonable
   rate limit on flood relays, either through a fixed threshold or a
   dynamic mechanism such as the Trickle algorithm[RFC6206], to mitigate
   the risk of denial-of-service attacks or excessive network
   utilization.

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











Zhu, et al.              Expires 21 January 2026               [Page 11]

Internet-Draft                   cGRASP                        July 2025


5.1.  How cGRASP adapts to networks without IP

   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 [RFC8990] 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, [RFC8990] 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.

5.2.  An example: Exchange cGRASP 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 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 [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,



Zhu, et al.              Expires 21 January 2026               [Page 12]

Internet-Draft                   cGRASP                        July 2025


   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[BTCorev5.4].  As described in
   Section 5.1, 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.

6.  IANA Considerations

   This document defines the Constrained GeneRic Autonomic Signaling
   Protocol (cGRASP).

   As specified in Section 3.2, 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.

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


    0-9 for Experimental
    10-255 Unassigned




Zhu, et al.              Expires 21 January 2026               [Page 13]

Internet-Draft                   cGRASP                        July 2025


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

   * Assignment of the resource type (rt=) "core.grasp-coap"

7.  Security Considerations

   As a constrained version of GRASP, cGRASP 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, e.g., the constrained code space and CPU for
   implementing cryptographic primitives.

   TODO more security considerations.

8.  References

8.1.  Normative References

   [BTCorev5.4]
              Bluetooth Special Interest Group, "BLUETOOTH CORE
              SPECIFICATION Version 5.4", 31 January 2023,
              <https://www.bluetooth.com/specifications/specs/core-
              specification-5-4/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <https://www.rfc-editor.org/info/rfc6206>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.





Zhu, et al.              Expires 21 January 2026               [Page 14]

Internet-Draft                   cGRASP                        July 2025


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

8.2.  Informative References

   [CoAPoverGATT]
              "CoAP over GATT (Bluetooth Low Energy Generic
              Attributes)", <https://datatracker.ietf.org/doc/draft-
              amsuess-core-coap-over-gatt/>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [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, <https://www.rfc-editor.org/info/rfc7967>.

   [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,
              <https://www.rfc-editor.org/info/rfc8993>.










Zhu, et al.              Expires 21 January 2026               [Page 15]

Internet-Draft                   cGRASP                        July 2025


Appendix A.  UDP-based GRASP

   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.

A.1.  Built-in reliability mechanism

   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 Appendix A.2.3, 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.

A.1.1.  Reliable transmission for confirmable cGRASP messages

   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



Zhu, et al.              Expires 21 January 2026               [Page 16]

Internet-Draft                   cGRASP                        July 2025


   option, and the ACK message are defined in Appendix A.2.2.2,
   Appendix A.2.2.3, and Appendix A.2.3, 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 Appendix A.1.2 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.








Zhu, et al.              Expires 21 January 2026               [Page 17]

Internet-Draft                   cGRASP                        July 2025


   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.

A.1.2.  Retransmission and retransmission timeout

   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.

A.2.  UDP-based cGRASP definition

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

A.2.1.  cGRASP message format

   Like standard GRASP, cGRASP 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 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:





Zhu, et al.              Expires 21 January 2026               [Page 18]

Internet-Draft                   cGRASP                        July 2025


    cgrasp-message = (message .within message-structure) / noop-message
    message-structure = [C_MESSAGE_TYPE, session-id, ?initiator,
                         *cgrasp-option]
    C_MESSAGE_TYPE = 0..255
    session-id = 0..65535 ; up to 16 bits
    cgrasp-option = any

A.2.2.  cGRASP option

A.2.2.1.  cGRASP Objective option

   Same as the Section 3.1.

A.2.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
   Appendix A.1.1.

A.2.2.3.  ACK option

   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 Appendix A.1.1, 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 Appendix A.2.3.  In fragmentary CDDL, an ACK option
   follows the pattern:

    ack-option = [O_ACK, Nonce]
    Nonce = 0..65535; same as the req-ack option




Zhu, et al.              Expires 21 January 2026               [Page 19]

Internet-Draft                   cGRASP                        July 2025


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

A.2.3.  cGRASP message

   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:





















Zhu, et al.              Expires 21 January 2026               [Page 20]

Internet-Draft                   cGRASP                        July 2025


  response-message = [M_RESPONSE, session-id, initiator, ttl,
                      req-ack-option, *ack-option, (+locator-option
                      // divert-option), ?cGRASP objective]
  ttl = 0..4294967295 ; in milliseconds

  request-negotiation-message = [M_REQ_NEG, session-id, req-ack-option,
                                 *ack-option, cGRASP objective]

  request-synchronization-message = [M_REQ_SYN, session-id,
                                     req-ack-option,
                                     *ack-option, cGRASP objective]

  negotiation-message = [M_NEGOTIATE, session-id, req-ack-option,
                         *ack-option,cGRASP objective]

  end-message = [M_END, session-id, req-ack-option, *ack-option,
                 cGRASP 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,
                   cGRASP objective]

  invalid-message = [M_INVALID, session-id, req-ack-option, *ack-option,
                     ?any]

   In addition, cGRASP 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.

A.2.4.  cGRASP constants

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




Zhu, et al.              Expires 21 January 2026               [Page 21]

Internet-Draft                   cGRASP                        July 2025


   *  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[RFC8990].

A.3.  IANA Considerations

   This document defines the Constrained GeneRic Autonomic Signaling
   Protocol (cGRASP).

   As specified in Appendix A.2.4, 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:


    M_ACK = 10
    O_REQ_ACK = 107
    O_ACK = 108

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


    0-9 for Experimental
    10-255 Unassigned




Zhu, et al.              Expires 21 January 2026               [Page 22]

Internet-Draft                   cGRASP                        July 2025


A.4.  Security Considerations

   As a constrained version of GRASP, cGRASP 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 cGRASP is based, e.g., the constrained code space and
   CPU for implementing cryptographic primitives.

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 21 January 2026               [Page 23]
