Lightweight GeneRic Autonomic Signaling Protocol
draft-zhu-anima-lightweight-grasp-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Longwei Zhu , Sheng Jiang | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhu-anima-lightweight-grasp-01
ANIMA L. Zhu
Internet-Draft S. Jiang
Intended status: Standards Track BUPT
Expires: 24 April 2025 21 October 2024
Lightweight GeneRic Autonomic Signaling Protocol
draft-zhu-anima-lightweight-grasp-01
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 the IoT, where lightweight and resource-constrained devices
dominate. 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 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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
Zhu & Jiang Expires 24 April 2025 [Page 1]
Internet-Draft LW-GRASP October 2024
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. IP-independent discussion . . . . . . . . . . . . . . . . . . 11
5.1. How LW-GRASP adapts to networks without IP . . . . . . . 11
5.2. An example: Exchange LW-GRASP over BLE . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Zhu & Jiang Expires 24 April 2025 [Page 2]
Internet-Draft LW-GRASP October 2024
1. Introduction
In the 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 the 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
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
Zhu & Jiang Expires 24 April 2025 [Page 3]
Internet-Draft LW-GRASP October 2024
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. 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
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.
Zhu & Jiang Expires 24 April 2025 [Page 4]
Internet-Draft LW-GRASP October 2024
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.
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
Zhu & Jiang Expires 24 April 2025 [Page 5]
Internet-Draft LW-GRASP October 2024
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
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
Zhu & Jiang Expires 24 April 2025 [Page 6]
Internet-Draft LW-GRASP October 2024
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
(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
Zhu & Jiang Expires 24 April 2025 [Page 7]
Internet-Draft LW-GRASP October 2024
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
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
Zhu & Jiang Expires 24 April 2025 [Page 8]
Internet-Draft LW-GRASP October 2024
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 & Jiang Expires 24 April 2025 [Page 9]
Internet-Draft LW-GRASP October 2024
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 & Jiang Expires 24 April 2025 [Page 10]
Internet-Draft LW-GRASP October 2024
* 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. 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.
5.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,
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
Zhu & Jiang Expires 24 April 2025 [Page 11]
Internet-Draft LW-GRASP October 2024
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.
5.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 LW-GRASP adapts 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.
Regarding address identification, BLE devices use a 48-bit device
address as a device identifier[BTCorev5.4]. As described in
Section 5.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.
Zhu & Jiang Expires 24 April 2025 [Page 12]
Internet-Draft LW-GRASP October 2024
6. IANA Considerations
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:
0-9 for Experimental
10-255 Unassigned
7. Security Considerations
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. References
8.1. Normative References
Zhu & Jiang Expires 24 April 2025 [Page 13]
Internet-Draft LW-GRASP October 2024
[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>.
[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
[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>.
[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>.
Authors' Addresses
Zhu & Jiang Expires 24 April 2025 [Page 14]
Internet-Draft LW-GRASP October 2024
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
Zhu & Jiang Expires 24 April 2025 [Page 15]