rfc8990v1.txt   rfc8990.txt 
Internet Engineering Task Force (IETF) C. Bormann Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 8990 Universität Bremen TZI Request for Comments: 8990 Universität Bremen TZI
Category: Standards Track B. Carpenter, Ed. Category: Standards Track B. Carpenter, Ed.
ISSN: 2070-1721 Univ. of Auckland ISSN: 2070-1721 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
April 2021 April 2021
A GeneRic Autonomic Signaling Protocol (GRASP) GeneRic Autonomic Signaling Protocol (GRASP)
Abstract Abstract
This document specifies the GeneRic Autonomic Signaling Protocol This document specifies the GeneRic Autonomic Signaling Protocol
(GRASP), which enables autonomic nodes and Autonomic Service Agents (GRASP), which enables autonomic nodes and Autonomic Service Agents
to dynamically discover peers, to synchronize state with each other, to dynamically discover peers, to synchronize state with each other,
and to negotiate parameter settings with each other. GRASP depends and to negotiate parameter settings with each other. GRASP depends
on an external security environment that is described elsewhere. The on an external security environment that is described elsewhere. The
technical objectives and parameters for specific application technical objectives and parameters for specific application
scenarios are to be described in separate documents. Appendices scenarios are to be described in separate documents. Appendices
skipping to change at line 131 skipping to change at line 131
become more and more problematic for human-based management. Also, become more and more problematic for human-based management. Also,
operational costs are growing quickly. Consequently, there are operational costs are growing quickly. Consequently, there are
increased requirements for autonomic behavior in the networks. increased requirements for autonomic behavior in the networks.
General aspects of autonomic networks are discussed in [RFC7575] and General aspects of autonomic networks are discussed in [RFC7575] and
[RFC7576]. [RFC7576].
One approach is to largely decentralize the logic of network One approach is to largely decentralize the logic of network
management by migrating it into network elements. A reference model management by migrating it into network elements. A reference model
for Autonomic Networking on this basis is given in [RFC8993]. The for Autonomic Networking on this basis is given in [RFC8993]. The
reader should consult this document to understand how various reader should consult this document to understand how various
autonomic components fit together. In order to fulfill autonomy, autonomic components fit together. In order to achieve autonomy,
devices that embody Autonomic Service Agents (ASAs, [RFC7575]) have devices that embody Autonomic Service Agents (ASAs, [RFC7575]) have
specific signaling requirements. In particular, they need to specific signaling requirements. In particular, they need to
discover each other, to synchronize state with each other, and to discover each other, to synchronize state with each other, and to
negotiate parameters and resources directly with each other. There negotiate parameters and resources directly with each other. There
is no limitation on the types of parameters and resources concerned, is no limitation on the types of parameters and resources concerned,
which can include very basic information needed for addressing and which can include very basic information needed for addressing and
routing, as well as anything else that might be configured in a routing, as well as anything else that might be configured in a
conventional non-autonomic network. The atomic unit of discovery, conventional non-autonomic network. The atomic unit of discovery,
synchronization, or negotiation is referred to as a technical synchronization, or negotiation is referred to as a technical
objective, i.e, a configurable parameter or set of parameters objective, i.e, a configurable parameter or set of parameters
skipping to change at line 272 skipping to change at line 272
Negotiation Initiator: Negotiation Initiator:
An ASA that starts negotiation by sending a request message An ASA that starts negotiation by sending a request message
referring to a specific negotiation objective. referring to a specific negotiation objective.
Negotiation Counterpart: Negotiation Counterpart:
A peer with which the Negotiation Initiator negotiates a specific A peer with which the Negotiation Initiator negotiates a specific
negotiation objective. negotiation objective.
GRASP Instance: GRASP Instance:
This refers to an instantiation of a GRASP engine, likely This refers to an instantiation of a GRASP protocol engine, likely
including multiple threads or processes as well as dynamic data including multiple threads or processes as well as dynamic data
structures such as a discovery cache, running in a given security structures such as a discovery cache, running in a given security
environment on a single device. environment on a single device.
GRASP Core: GRASP Core:
This refers to the code and shared data structures of a GRASP This refers to the code and shared data structures of a GRASP
instance, which will communicate with individual ASAs via a instance, which will communicate with individual ASAs via a
suitable Application Programming Interface (API). suitable Application Programming Interface (API).
Interface or GRASP Interface: Interface or GRASP Interface:
Unless otherwise stated, this refer to a network interface, which Unless otherwise stated, this refers to a network interface, which
might be physical or virtual, that a specific instance of GRASP is might be physical or virtual, that a specific instance of GRASP is
currently using. A device might have other interfaces that are currently using. A device might have other interfaces that are
not used by GRASP and which are outside the scope of the Autonomic not used by GRASP and which are outside the scope of the Autonomic
Network. Network.
2.2. High-Level Deployment Model 2.2. High-Level Deployment Model
A GRASP implementation will be part of the Autonomic Networking A GRASP implementation will be part of the Autonomic Networking
Infrastructure (ANI) in an autonomic node, which must also provide an Infrastructure (ANI) in an autonomic node, which must also provide an
appropriate security environment. In accordance with [RFC8993], this appropriate security environment. In accordance with [RFC8993], this
skipping to change at line 366 skipping to change at line 366
This section describes the behavior model and general design of This section describes the behavior model and general design of
GRASP, supporting discovery, synchronization, and negotiation, to act GRASP, supporting discovery, synchronization, and negotiation, to act
as a platform for different technical objectives. as a platform for different technical objectives.
A generic platform: A generic platform:
The protocol design is generic and independent of the The protocol design is generic and independent of the
synchronization or negotiation contents. The technical contents synchronization or negotiation contents. The technical contents
will vary according to the various technical objectives and the will vary according to the various technical objectives and the
different pairs of counterparts. different pairs of counterparts.
Normally, a single main instance of the GRASP engine will exist in Multiple instances:
an autonomic node, and each ASA will run as an independent Normally, a single main instance of the GRASP protocol engine will
asynchronous process. However, scenarios where multiple instances exist in an autonomic node, and each ASA will run as an
of GRASP run in a single node, perhaps with different security independent asynchronous process. However, scenarios where
properties, are possible (Section 2.5.2). In this case, each multiple instances of GRASP run in a single node, perhaps with
instance MUST listen independently for GRASP link-local different security properties, are possible (Section 2.5.2). In
multicasts, and all instances MUST be woken by each such multicast this case, each instance MUST listen independently for GRASP link-
in order for discovery and flooding to work correctly. local multicasts, and all instances MUST be woken by each such
multicast in order for discovery and flooding to work correctly.
Security infrastructure: Security infrastructure:
As noted above, the protocol itself has no built-in security As noted above, the protocol itself has no built-in security
functionality and relies on a separate secure infrastructure. functionality and relies on a separate secure infrastructure.
Discovery, synchronization, and negotiation are designed together: Discovery, synchronization, and negotiation are designed together:
The discovery method and the synchronization and negotiation The discovery method and the synchronization and negotiation
methods are designed in the same way and can be combined when this methods are designed in the same way and can be combined when this
is useful, allowing a rapid mode of operation described in is useful, allowing a rapid mode of operation described in
Section 2.5.4. These processes can also be performed Section 2.5.4. These processes can also be performed
independently when appropriate. independently when appropriate.
Thus, for some objectives, especially those concerned with Thus, for some objectives, especially those concerned with
application-layer services, another discovery mechanism such as application-layer services, another discovery mechanism such as
the future DNS Service Discovery [RFC7558] MAY be used. The DNS-based Service Discovery [RFC7558] MAY be used. The choice
choice is left to the designers of individual ASAs. is left to the designers of individual ASAs.
A uniform pattern for technical objectives: A uniform pattern for technical objectives:
The synchronization and negotiation objectives are defined The synchronization and negotiation objectives are defined
according to a uniform pattern. The values that they contain according to a uniform pattern. The values that they contain
could be carried either in a simple binary format or in a complex could be carried either in a simple binary format or in a complex
object format. The basic protocol design uses the Concise Binary object format. The basic protocol design uses the Concise Binary
Object Representation (CBOR) [RFC8949], which is readily Object Representation (CBOR) [RFC8949], which is readily
extensible for unknown, future requirements. extensible for unknown, future requirements.
A flexible model for synchronization: A flexible model for synchronization:
skipping to change at line 623 skipping to change at line 624
between adjacent GRASP nodes. The GRASP security and transport between adjacent GRASP nodes. The GRASP security and transport
substrate needs to specify how these link-local multicasts are substrate needs to specify how these link-local multicasts are
transported. This can be unreliable transport (UDP) but it SHOULD be transported. This can be unreliable transport (UDP) but it SHOULD be
reliable transport (e.g., TCP). reliable transport (e.g., TCP).
If the substrate specifies an unreliable transport such as UDP for If the substrate specifies an unreliable transport such as UDP for
discovery and flooding messages, then it MUST NOT use IP discovery and flooding messages, then it MUST NOT use IP
fragmentation because of its loss characteristic, especially in fragmentation because of its loss characteristic, especially in
multi-hop flooding. GRASP MUST then enforce at the user API level a multi-hop flooding. GRASP MUST then enforce at the user API level a
limit to the size of discovery and flooding messages, so that no limit to the size of discovery and flooding messages, so that no
fragmentation can occur. For IPv6 transport, this means that those fragmentation can occur. For IPv6 transport, this means that the
messages must be at most 1280 bytes sized IPv6 packets (unless there size of those messages' IPv6 packets must be at most 1280 bytes
is a known larger minimum link MTU across the whole GRASP domain). (unless there is a known larger minimum link MTU across the whole
GRASP domain).
All other GRASP messages are unicast between group members of the All other GRASP messages are unicast between group members of the
GRASP domain. These MUST use a reliable transport protocol because GRASP domain. These MUST use a reliable transport protocol because
GRASP itself does not provide for error detection, retransmission, or GRASP itself does not provide for error detection, retransmission, or
flow control. Unless otherwise specified by the security and flow control. Unless otherwise specified by the security and
transport substrate, TCP MUST be used. transport substrate, TCP MUST be used.
The security and transport substrate for GRASP in the ANI is the ACP. The security and transport substrate for GRASP in the ANI is the ACP.
Unless otherwise noted, we assume this security and transport Unless otherwise noted, we assume this security and transport
substrate in the remainder of this document when describing GRASP's substrate in the remainder of this document when describing GRASP's
message transport. In the ACP, TCP is used for GRASP unicast message transport. In the ACP, TCP is used for GRASP unicast
messages. GRASP discovery and flooding messages also use TCP: these messages. GRASP discovery and flooding messages also use TCP: these
link-local messages are forwarded by replicating them to all adjacent link-local messages are forwarded by replicating them to all adjacent
GRASP nodes on the link via TCP connections. Because of this, GRASP GRASP nodes on the link via TCP connections to those adjacent GRASP
in the ANI has no limitations on the size of discovery and flooding nodes. Because of this, GRASP in the ANI has no limitations on the
messages with respect to fragmentation issues. UDP is used in the size of discovery and flooding messages with respect to fragmentation
ANI with GRASP only with DULL when the ACP is built to discover ACP/ issues. While the ACP is being built using a DULL instance of GRASP,
GRASP neighbors on links. native UDP multicast is used to discover ACP/GRASP neighbors on
links.
For link-local UDP multicast, GRASP listens to the well-known GRASP For link-local UDP multicast, GRASP listens to the well-known GRASP
Listen Port (Section 2.6). Transport connections for discovery and Listen Port (Section 2.6). Transport connections for discovery and
flooding on relay nodes must terminate in GRASP instances (e.g., flooding on relay nodes must terminate in GRASP instances (e.g.,
GRASP ASAs) so that link-local multicast, hop-by-hop flooding of GRASP ASAs) so that link-local multicast, hop-by-hop flooding of
M_DISCOVERY and M_FLOOD messages and hop-by-hop forwarding of M_DISCOVERY and M_FLOOD messages and hop-by-hop forwarding of
M_RESPONSE responses and caching of those responses along the path M_RESPONSE responses and caching of those responses along the path
work correctly. work correctly.
Unicast transport connections used for synchronization and Unicast transport connections used for synchronization and
skipping to change at line 864 skipping to change at line 867
A Discovery message MAY include an objective option. This allows a A Discovery message MAY include an objective option. This allows a
rapid mode of negotiation (Section 2.5.5.1) or synchronization rapid mode of negotiation (Section 2.5.5.1) or synchronization
(Section 2.5.6.3). Rapid mode is currently limited to a single (Section 2.5.6.3). Rapid mode is currently limited to a single
objective for simplicity of design and implementation. A possible objective for simplicity of design and implementation. A possible
future extension is to allow multiple objectives in rapid mode for future extension is to allow multiple objectives in rapid mode for
greater efficiency. greater efficiency.
2.5.5. Negotiation Procedures 2.5.5. Negotiation Procedures
A negotiation initiator opens a transport connection to a counterpart A negotiation initiator opens a transport connection to a counterpart
ASA using the address, protocol,and port obtained during discovery. ASA using the address, protocol, and port obtained during discovery.
It then sends a negotiation request (using M_REQ_NEG) to the It then sends a negotiation request (using M_REQ_NEG) to the
counterpart, including a specific negotiation objective. It may counterpart, including a specific negotiation objective. It may
request the negotiation counterpart to make a specific configuration. request the negotiation counterpart to make a specific configuration.
Alternatively, it may request a certain simulation or forecast result Alternatively, it may request a certain simulation or forecast result
by sending a dry-run configuration. The details, including the by sending a dry-run configuration. The details, including the
distinction between a dry run and a live configuration change, will distinction between a dry run and a live configuration change, will
be defined separately for each type of negotiation objective. Any be defined separately for each type of negotiation objective. Any
state associated with a dry-run operation, such as temporarily state associated with a dry-run operation, such as temporarily
reserving a resource for subsequent use in a live run, is entirely a reserving a resource for subsequent use in a live run, is entirely a
matter for the designer of the ASA concerned. matter for the designer of the ASA concerned.
skipping to change at line 1062 skipping to change at line 1065
or off by Intent. or off by Intent.
2.6. GRASP Constants 2.6. GRASP Constants
ALL_GRASP_NEIGHBORS ALL_GRASP_NEIGHBORS
A link-local scope multicast address used by a GRASP-enabled A link-local scope multicast address used by a GRASP-enabled
device to discover GRASP-enabled neighbor (i.e., on-link) devices. device to discover GRASP-enabled neighbor (i.e., on-link) devices.
All devices that support GRASP are members of this multicast All devices that support GRASP are members of this multicast
group. group.
* IPv6 multicast address: FF02::13 * IPv6 multicast address: ff02::13
* IPv4 multicast address: 224.0.0.119 * IPv4 multicast address: 224.0.0.119
GRASP_LISTEN_PORT (7017) GRASP_LISTEN_PORT (7017)
A well-known UDP user port that every GRASP-enabled network device A well-known UDP user port that every GRASP-enabled network device
MUST listen to for link-local multicasts when UDP is used for MUST listen to for link-local multicasts when UDP is used for
M_DISCOVERY or M_FLOOD messages in the GRASP instance. This user M_DISCOVERY or M_FLOOD messages in the GRASP instance. This user
port MAY also be used to listen for TCP or UDP unicast messages in port MAY also be used to listen for TCP or UDP unicast messages in
a simple implementation of GRASP (Section 2.5.3). a simple implementation of GRASP (Section 2.5.3).
skipping to change at line 1150 skipping to change at line 1153
GRASP messages share an identical header format and a variable format GRASP messages share an identical header format and a variable format
area for options. GRASP message headers and options are transmitted area for options. GRASP message headers and options are transmitted
in Concise Binary Object Representation (CBOR) [RFC8949]. In this in Concise Binary Object Representation (CBOR) [RFC8949]. In this
specification, they are described using Concise Data Definition specification, they are described using Concise Data Definition
Language (CDDL) [RFC8610]. Fragmentary CDDL is used to describe each Language (CDDL) [RFC8610]. Fragmentary CDDL is used to describe each
item in this section. A complete and normative CDDL specification of item in this section. A complete and normative CDDL specification of
GRASP is given in Section 4, including constants such as message GRASP is given in Section 4, including constants such as message
types. types.
Every GRASP message, except the No Operation message, carries a Every GRASP message, except the No Operation message, carries a
Session ID (Section 2.7). Options are then presented serially in the Session ID (Section 2.7). Options are then presented serially.
options field.
In fragmentary CDDL, every GRASP message follows the pattern: In fragmentary CDDL, every GRASP message follows the pattern:
grasp-message = (message .within message-structure) / noop-message grasp-message = (message .within message-structure) / noop-message
message-structure = [MESSAGE_TYPE, session-id, ?initiator, message-structure = [MESSAGE_TYPE, session-id, ?initiator,
*grasp-option] *grasp-option]
MESSAGE_TYPE = 1..255 MESSAGE_TYPE = 0..255
session-id = 0..4294967295 ; up to 32 bits session-id = 0..4294967295 ; up to 32 bits
grasp-option = any grasp-option = any
The MESSAGE_TYPE indicates the type of the message and thus defines The MESSAGE_TYPE indicates the type of the message and thus defines
the expected options. Any options received that are not consistent the expected options. Any options received that are not consistent
with the MESSAGE_TYPE SHOULD be silently discarded. with the MESSAGE_TYPE SHOULD be silently discarded.
The No Operation (noop) message is described in Section 2.8.13. The No Operation (noop) message is described in Section 2.8.13.
The various MESSAGE_TYPE values are defined in Section 4. The various MESSAGE_TYPE values are defined in Section 4.
skipping to change at line 1264 skipping to change at line 1266
As mentioned in Section 2.5.4.2, a Discovery message MAY be sent As mentioned in Section 2.5.4.2, a Discovery message MAY be sent
unicast to a peer node, which SHOULD then proceed exactly as if the unicast to a peer node, which SHOULD then proceed exactly as if the
message had been multicast. message had been multicast.
2.8.5. Discovery Response Message 2.8.5. Discovery Response Message
In fragmentary CDDL, a Discovery Response message follows the In fragmentary CDDL, a Discovery Response message follows the
pattern: pattern:
response-message = [M_RESPONSE, session-id, initiator, ttl, response-message = [M_RESPONSE, session-id, initiator, ttl,
(+locator-option // divert-option), ?objective)] (+locator-option // divert-option, ?objective)]
ttl = 0..4294967295 ; in milliseconds ttl = 0..4294967295 ; in milliseconds
A node that receives a Discovery message SHOULD send a Discovery A node that receives a Discovery message SHOULD send a Discovery
Response message if and only if it can respond to the discovery. Response message if and only if it can respond to the discovery.
It MUST contain the same Session ID and initiator as the Discovery It MUST contain the same Session ID and initiator as the Discovery
message. message.
It MUST contain a time-to-live (ttl) for the validity of the It MUST contain a time-to-live (ttl) for the validity of the
skipping to change at line 1361 skipping to change at line 1363
simultaneously request sessions with each other using the same simultaneously request sessions with each other using the same
Session ID (Section 2.7), a node MUST verify that the received Session ID (Section 2.7), a node MUST verify that the received
Session ID is not already locally active when it receives a Request Session ID is not already locally active when it receives a Request
message. In case of a clash, it MUST discard the Request message, in message. In case of a clash, it MUST discard the Request message, in
which case the initiator will detect a timeout. which case the initiator will detect a timeout.
2.8.7. Negotiation Message 2.8.7. Negotiation Message
In fragmentary CDDL, a Negotiation message follows the pattern: In fragmentary CDDL, a Negotiation message follows the pattern:
negotiate-message = [M_NEGOTIATE, session-id, objective] negotiation-message = [M_NEGOTIATE, session-id, objective]
A negotiation counterpart sends a Negotiation message in response to A negotiation counterpart sends a Negotiation message in response to
a Request Negotiation message, a Negotiation message, or a Discovery a Request Negotiation message, a Negotiation message, or a Discovery
message in rapid mode. A negotiation process MAY include multiple message in rapid mode. A negotiation process MAY include multiple
steps. steps.
The Negotiation message MUST include the relevant Negotiation The Negotiation message MUST include the relevant Negotiation
Objective option, with its value updated according to progress in the Objective option, with its value updated according to progress in the
negotiation. The sender MUST decrement the loop count by 1. If the negotiation. The sender MUST decrement the loop count by 1. If the
loop count becomes zero, the message MUST NOT be sent. In this case, loop count becomes zero, the message MUST NOT be sent. In this case,
skipping to change at line 1476 skipping to change at line 1478
Cached entries MUST be ignored or deleted after their lifetime Cached entries MUST be ignored or deleted after their lifetime
expires. expires.
2.8.12. Invalid Message 2.8.12. Invalid Message
In fragmentary CDDL, an Invalid message follows the pattern: In fragmentary CDDL, an Invalid message follows the pattern:
invalid-message = [M_INVALID, session-id, ?any] invalid-message = [M_INVALID, session-id, ?any]
This message MAY be sent by an implementation in response to an This message MAY be sent by an implementation in response to an
incoming unicast message that it considers invalid. The session-id incoming unicast message that it considers invalid. The Session ID
MUST be copied from the incoming message. The content SHOULD be value MUST be copied from the incoming message. The content SHOULD
diagnostic information such as a partial copy of the invalid message be diagnostic information such as a partial copy of the invalid
up to the maximum message size. An M_INVALID message MAY be silently message up to the maximum message size. An M_INVALID message MAY be
ignored by a recipient. However, it could be used in support of silently ignored by a recipient. However, it could be used in
extensibility, since it indicates that the remote node does not support of extensibility, since it indicates that the remote node
support a new or obsolete message or option. does not support a new or obsolete message or option.
An M_INVALID message MUST NOT be sent in response to an M_INVALID An M_INVALID message MUST NOT be sent in response to an M_INVALID
message. message.
2.8.13. No Operation Message 2.8.13. No Operation Message
In fragmentary CDDL, a No Operation message follows the pattern: In fragmentary CDDL, a No Operation message follows the pattern:
noop-message = [M_NOOP] noop-message = [M_NOOP]
skipping to change at line 1505 skipping to change at line 1507
a recipient. a recipient.
2.9. GRASP Options 2.9. GRASP Options
This section defines the GRASP options for the negotiation and This section defines the GRASP options for the negotiation and
synchronization protocol signaling. Additional options may be synchronization protocol signaling. Additional options may be
defined in the future. defined in the future.
2.9.1. Format of GRASP Options 2.9.1. Format of GRASP Options
GRASP options are CBOR objects that MUST start with an unsigned GRASP options SHOULD be CBOR arrays that MUST start with an unsigned
integer identifying the specific option type carried in this option. integer identifying the specific option type carried in this option.
These option types are formally defined in Section 4. Apart from These option types are formally defined in Section 4.
that, the only format requirement is that each option MUST be a well-
formed CBOR object. In general, a CBOR array format is RECOMMENDED
to limit overhead.
GRASP options may be defined to include encapsulated GRASP options. GRASP options may be defined to include encapsulated GRASP options.
2.9.2. Divert Option 2.9.2. Divert Option
The Divert option is used to redirect a GRASP request to another The Divert option is used to redirect a GRASP request to another
node, which may be more appropriate for the intended negotiation or node, which may be more appropriate for the intended negotiation or
synchronization. It may redirect to an entity that is known as a synchronization. It may redirect to an entity that is known as a
specific negotiation or synchronization counterpart (on-link or off- specific negotiation or synchronization counterpart (on-link or off-
link) or a default gateway. The Divert option MUST only be link) or a default gateway. The Divert option MUST only be
skipping to change at line 1653 skipping to change at line 1652
when this option is used within the Divert option. when this option is used within the Divert option.
Note 2: Normal GRASP operations are not expected to use this option. Note 2: Normal GRASP operations are not expected to use this option.
It is intended for special purposes such as discovering external It is intended for special purposes such as discovering external
services. services.
2.9.5.4. Locator URI Option 2.9.5.4. Locator URI Option
In fragmentary CDDL, the Locator URI option follows the pattern: In fragmentary CDDL, the Locator URI option follows the pattern:
uri-locator = [O_URI_LOCATOR, text, uri-locator-option = [O_URI_LOCATOR, text,
transport-proto / null, port-number / null] transport-proto / null, port-number / null]
The content of this option is the URI of the target followed by the The content of this option is the URI of the target followed by the
protocol number and port number to be used (or by null values if not protocol number and port number to be used (or by null values if not
required) [RFC3986]. required) [RFC3986].
Note 1: Any URI which might not be valid throughout the network in Note 1: Any URI which might not be valid throughout the network in
question, such as one based on a Multicast DNS name [RFC6762], MUST question, such as one based on a Multicast DNS name [RFC6762], MUST
NOT be used when this option is used within the Divert option. NOT be used when this option is used within the Divert option.
Note 2: Normal GRASP operations are not expected to use this option. Note 2: Normal GRASP operations are not expected to use this option.
skipping to change at line 1723 skipping to change at line 1722
described in Section 2.8.7. It is also used for terminating described in Section 2.8.7. It is also used for terminating
discovery as described in Section 2.5.4 and for terminating flooding discovery as described in Section 2.5.4 and for terminating flooding
as described in Section 2.5.6.2. It is placed in the objective as described in Section 2.5.6.2. It is placed in the objective
rather than in the GRASP message format because, as far as the ASA is rather than in the GRASP message format because, as far as the ASA is
concerned, it is a property of the objective itself. concerned, it is a property of the objective itself.
The 'objective-value' field expresses the actual value of a The 'objective-value' field expresses the actual value of a
negotiation or synchronization objective. Its format is defined in negotiation or synchronization objective. Its format is defined in
the specification of the objective and may be a simple value or a the specification of the objective and may be a simple value or a
data structure of any kind, as long as it can be represented in CBOR. data structure of any kind, as long as it can be represented in CBOR.
It is optional because it is optional in a Discovery or Discovery It is optional only in a Discovery or Discovery Response message.
Response message.
2.10.2. Objective Flags 2.10.2. Objective Flags
An objective may be relevant for discovery only, for discovery and An objective may be relevant for discovery only, for discovery and
negotiation, or for discovery and synchronization. This is expressed negotiation, or for discovery and synchronization. This is expressed
in the objective by logical flag bits: in the objective by logical flag bits:
objective-flags = uint .bits objective-flag objective-flags = uint .bits objective-flag
objective-flag = &( objective-flag = &(
F_DISC: 0 ; valid for discovery F_DISC: 0 ; valid for discovery
skipping to change at line 1759 skipping to change at line 1757
As mentioned above, objective options MUST be assigned a unique name. As mentioned above, objective options MUST be assigned a unique name.
As long as privately defined objective options obey the rules above, As long as privately defined objective options obey the rules above,
this document does not restrict their choice of name, but the entity this document does not restrict their choice of name, but the entity
or person concerned SHOULD publish the names in use. or person concerned SHOULD publish the names in use.
Names are expressed as UTF-8 strings for convenience in designing Names are expressed as UTF-8 strings for convenience in designing
objective options for localized use. For generic usage, names objective options for localized use. For generic usage, names
expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers
planning to use non-ASCII names are strongly advised to consult planning to use non-ASCII names are strongly advised to consult
[RFC7564] or its successor to understand the complexities involved. [RFC8264] or its successor to understand the complexities involved.
Since GRASP compares names byte by byte, all issues of Unicode Since GRASP compares names byte by byte, all issues of Unicode
profiling and canonicalization MUST be specified in the design of the profiling and canonicalization MUST be specified in the design of the
objective option. objective option.
All objective options MUST respect the CBOR patterns defined above as All objective options MUST respect the CBOR patterns defined above as
"objective" and MUST replace the 'any' field with a valid CBOR data "objective" and MUST replace the 'any' field with a valid CBOR data
definition for the relevant use case and application. definition for the relevant use case and application.
An objective option that contains no additional fields beyond its An objective option that contains no additional fields beyond its
'loop-count' can only be a discovery objective and MUST only be used 'loop-count' can only be a discovery objective and MUST only be used
skipping to change at line 2002 skipping to change at line 2000
MESSAGE_TYPE = 0..255 MESSAGE_TYPE = 0..255
session-id = 0..4294967295 ; up to 32 bits session-id = 0..4294967295 ; up to 32 bits
grasp-option = any grasp-option = any
message /= discovery-message message /= discovery-message
discovery-message = [M_DISCOVERY, session-id, initiator, objective] discovery-message = [M_DISCOVERY, session-id, initiator, objective]
message /= response-message ; response to Discovery message /= response-message ; response to Discovery
response-message = [M_RESPONSE, session-id, initiator, ttl, response-message = [M_RESPONSE, session-id, initiator, ttl,
(+locator-option // divert-option), ?objective] (+locator-option // divert-option), ?objective]
message /= synch-message ; response to Synchronization request message /= synch-message ; response to Synchronization request
synch-message = [M_SYNCH, session-id, objective] synch-message = [M_SYNCH, session-id, objective]
message /= flood-message message /= flood-message
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
message /= request-negotiation-message message /= request-negotiation-message
request-negotiation-message = [M_REQ_NEG, session-id, objective] request-negotiation-message = [M_REQ_NEG, session-id, objective]
message /= request-synchronization-message message /= request-synchronization-message
request-synchronization-message = [M_REQ_SYN, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective]
message /= negotiation-message message /= negotiation-message
negotiation-message = [M_NEGOTIATE, session-id, objective] negotiation-message = [M_NEGOTIATE, session-id, objective]
skipping to change at line 2114 skipping to change at line 2112
This document defines the GeneRic Autonomic Signaling Protocol This document defines the GeneRic Autonomic Signaling Protocol
(GRASP). (GRASP).
Section 2.6 explains the following link-local multicast addresses Section 2.6 explains the following link-local multicast addresses
that IANA has assigned for use by GRASP. that IANA has assigned for use by GRASP.
Assigned in the "Link-Local Scope Multicast Addresses" subregistry of Assigned in the "Link-Local Scope Multicast Addresses" subregistry of
the "IPv6 Multicast Address Space Registry": the "IPv6 Multicast Address Space Registry":
Address(es): FF02::13 Address(es): ff02::13
Description: ALL_GRASP_NEIGHBORS Description: ALL_GRASP_NEIGHBORS
Reference: RFC 8990 Reference: RFC 8990
Assigned in the "Local Network Control Block (224.0.0.0 - 224.0.0.255 Assigned in the "Local Network Control Block (224.0.0.0 - 224.0.0.255
(224.0.0/24))" subregistry of the "IPv4 Multicast Address Space (224.0.0/24))" subregistry of the "IPv4 Multicast Address Space
Registry": Registry":
Address(es): 224.0.0.119 Address(es): 224.0.0.119
Description: ALL_GRASP_NEIGHBORS Description: ALL_GRASP_NEIGHBORS
Reference: RFC 8990 Reference: RFC 8990
skipping to change at line 2329 skipping to change at line 2327
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, "Service Location Protocol, Version 2", RFC 2608,
DOI 10.17487/RFC2608, June 1999, DOI 10.17487/RFC2608, June 1999,
<https://www.rfc-editor.org/info/rfc2608>. <https://www.rfc-editor.org/info/rfc2608>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
<https://www.rfc-editor.org/info/rfc3416>. <https://www.rfc-editor.org/info/rfc3416>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>. <https://www.rfc-editor.org/info/rfc3493>.
skipping to change at line 2390 skipping to change at line 2383
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013, DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>. <https://www.rfc-editor.org/info/rfc6887>.
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-Based Service Discovery "Requirements for Scalable DNS-Based Service Discovery
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
DOI 10.17487/RFC7558, July 2015, DOI 10.17487/RFC7558, July 2015,
<https://www.rfc-editor.org/info/rfc7558>. <https://www.rfc-editor.org/info/rfc7558>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 7564, DOI 10.17487/RFC7564, May 2015,
<https://www.rfc-editor.org/info/rfc7564>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<https://www.rfc-editor.org/info/rfc7576>. <https://www.rfc-editor.org/info/rfc7576>.
skipping to change at line 2424 skipping to change at line 2411
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, [RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
"GeneRic Autonomic Signaling Protocol Application Program "GeneRic Autonomic Signaling Protocol Application Program
Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991, Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
April 2021, <https://www.rfc-editor.org/info/rfc8991>. April 2021, <https://www.rfc-editor.org/info/rfc8991>.
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
L., and J. Nobre, "A Reference Model for Autonomic L., and J. Nobre, "A Reference Model for Autonomic
Networking", RFC 8993, DOI 10.17487/RFC8993, April 2021, Networking", RFC 8993, DOI 10.17487/RFC8993, April 2021,
<https://www.rfc-editor.org/rfc/rfc8993>. <https://www.rfc-editor.org/rfc/rfc8993>.
skipping to change at line 2860 skipping to change at line 2859
configuration. Both SLP and DNS-SD are text-based protocols. configuration. Both SLP and DNS-SD are text-based protocols.
Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ Simple Network Management Protocol (SNMP) [RFC3416] uses a command/
response model not well suited for peer negotiation. NETCONF response model not well suited for peer negotiation. NETCONF
[RFC6241] uses an RPC model that does allow positive or negative [RFC6241] uses an RPC model that does allow positive or negative
responses from the target system, but this is still not adequate for responses from the target system, but this is still not adequate for
negotiation. negotiation.
There are various existing protocols that have elementary negotiation There are various existing protocols that have elementary negotiation
abilities, such as Dynamic Host Configuration Protocol for IPv6 abilities, such as Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control (DHCPv6) [RFC8415], Neighbor Discovery (ND) [RFC4861], Port Control
Protocol (PCP) [RFC6887], Remote Authentication Dial-In User Service Protocol (PCP) [RFC6887], Remote Authentication Dial-In User Service
(RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are
configuration or management protocols. However, they either provide configuration or management protocols. However, they either provide
only a simple request/response model in a master/slave context or only a simple request/response model in a master/slave context or
very limited negotiation abilities. very limited negotiation abilities.
There are some signaling protocols with an element of negotiation. There are some signaling protocols with an element of negotiation.
For example, Resource ReSerVation Protocol (RSVP) [RFC2205] was For example, Resource ReSerVation Protocol (RSVP) [RFC2205] was
designed for negotiating quality-of-service parameters along the path designed for negotiating quality-of-service parameters along the path
of a unicast or multicast flow. RSVP is a very specialized protocol of a unicast or multicast flow. RSVP is a very specialized protocol
skipping to change at line 2976 skipping to change at line 2975
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Email: cabo@tzi.org Email: cabo@tzi.org
Brian Carpenter (editor) Brian Carpenter (editor)
Department of Computer Science School of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Bing Liu (editor) Bing Liu (editor)
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus Q14, Huawei Campus
 End of changes. 29 change blocks. 
62 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/