draft-ietf-anima-grasp-04.txt   draft-ietf-anima-grasp-05.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track B. Carpenter, Ed. Intended status: Standards Track B. Carpenter, Ed.
Expires: September 12, 2016 Univ. of Auckland Expires: November 14, 2016 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
March 11, 2016 May 13, 2016
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-04 draft-ietf-anima-grasp-05
Abstract Abstract
This document establishes requirements for a signaling protocol that This document establishes requirements for a signaling protocol that
enables autonomic devices and autonomic service agents to dynamically enables autonomic devices and autonomic service agents to dynamically
discover peers, to synchronize state with them, and to negotiate discover peers, to synchronize state with them, and to negotiate
parameter settings mutually with them. The document then defines a parameter settings mutually with them. The document then defines a
general protocol for discovery, synchronization and negotiation, general protocol for discovery, synchronization and negotiation,
while the technical objectives for specific scenarios are to be while the technical objectives for specific scenarios are to be
described in separate documents. An Appendix briefly discusses described in separate documents. An Appendix briefly discusses
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2016. This Internet-Draft will expire on November 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirement Analysis of Discovery, Synchronization and 2. Requirement Analysis of Discovery, Synchronization and
Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 5
2.2. Requirements for Synchronization and Negotiation 2.2. Requirements for Synchronization and Negotiation
Capability . . . . . . . . . . . . . . . . . . . . . . . 6 Capability . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 2.3. Specific Technical Requirements . . . . . . . . . . . . . 9
3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 12
3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15 3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15
3.3.1. Required External Security Mechanism . . . . . . . . 15 3.3.1. Required External Security Mechanism . . . . . . . . 15
3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 16 3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 16
3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 17
3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 19 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 19
3.3.5. Synchronization and Flooding Procedure . . . . . . . 20 3.3.5. Synchronization and Flooding Procedure . . . . . . . 21
3.4. High Level Deployment Model . . . . . . . . . . . . . . . 22 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 22
3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23
3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 23 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 23
3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 24
3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 23 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 24
3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 24 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 24
3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 24 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 25
3.7.4. Discovery Response Message . . . . . . . . . . . . . 25 3.7.4. Discovery Response Message . . . . . . . . . . . . . 26
3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 26 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 27
3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 27 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 27
3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 27 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 28
3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 27 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 28
3.7.9. Synchronization Message . . . . . . . . . . . . . . . 28 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 28
3.7.10. Flood Synchronization Message . . . . . . . . . . . . 28 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 29
3.7.11. No Operation Message . . . . . . . . . . . . . . . . 28 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 29
3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 29 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 29
3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 29 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 29
3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 29 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 30
3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 29 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 30
3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 30 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 30
3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 30 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 31
3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 31 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 33
3.9.1. Format of Objective Options . . . . . . . . . . . . . 32 3.9.1. Format of Objective Options . . . . . . . . . . . . . 33
3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 33 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 34
3.9.3. General Considerations for Objective Options . . . . 33 3.9.3. General Considerations for Objective Options . . . . 34
3.9.4. Organizing of Objective Options . . . . . . . . . . . 34 3.9.4. Organizing of Objective Options . . . . . . . . . . . 35
3.9.5. Experimental and Example Objective Options . . . . . 35 3.9.5. Experimental and Example Objective Options . . . . . 36
4. Security Considerations . . . . . . . . . . . . . . . . . . . 35 4. Implementation Status [RFC Editor: please remove] . . . . . . 36
5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 37 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 36
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . 41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . 42 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 45 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 45 9.1. Normative References . . . . . . . . . . . . . . . . . . 44
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 52 9.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix D. Capability Analysis of Current Protocols . . . . . . 55 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 48
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 55
Appendix D. Capability Analysis of Current Protocols . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
The success of the Internet has made IP-based networks bigger and The success of the Internet has made IP-based networks bigger and
more complicated. Large-scale ISP and enterprise networks have more complicated. Large-scale ISP and enterprise networks have
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 for autonomic networking on this basis is given in
[I-D.behringer-anima-reference-model]. In order to fulfil autonomy, [I-D.ietf-anima-reference-model]. In order to fulfil autonomy,
devices that embody autonomic service agents have specific signaling devices that embody autonomic service agents have specific signaling
requirements. In particular they need to discover each other, to requirements. In particular they need to discover each other, to
synchronize state with each other, and to negotiate parameters and synchronize state with each other, and to negotiate parameters and
resources directly with each other. There is no restriction on the resources directly with each other. There is no restriction on the
type of parameters and resources concerned, which include very basic type of parameters and resources concerned, which include very basic
information needed for addressing and routing, as well as anything information needed for addressing and routing, as well as anything
else that might be configured in a conventional non-autonomic else that might be configured in a conventional non-autonomic
network. The atomic unit of synchronization or negotiation is network. The atomic unit of synchronization or negotiation is
referred to as a technical objective, i.e, a configurable parameter referred to as a technical objective, i.e, a configurable parameter
or set of parameters (defined more precisely in Section 3.1). or set of parameters (defined more precisely in Section 3.1).
skipping to change at page 6, line 28 skipping to change at page 6, line 30
trust with the rest of the network and join an authentication trust with the rest of the network and join an authentication
mechanism. Although this will inevitably start with a discovery mechanism. Although this will inevitably start with a discovery
action, it is a special case precisely because trust is not yet action, it is a special case precisely because trust is not yet
established. This topic is the subject of established. This topic is the subject of
[I-D.ietf-anima-bootstrapping-keyinfra]. We require that once [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once
trust has been established for a device, all ASAs within the trust has been established for a device, all ASAs within the
device inherit the device's credentials and are also trusted. device inherit the device's credentials and are also trusted.
o Depending on the type of network involved, discovery of other o Depending on the type of network involved, discovery of other
central functions might be needed, such as the Network Operations central functions might be needed, such as the Network Operations
Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol
must be capable of supporting such discovery during must be capable of supporting such discovery during
initialisation, as well as discovery during ongoing operation. initialisation, as well as discovery during ongoing operation.
D8. The discovery process must not generate excessive traffic and D8. The discovery process must not generate excessive traffic and
must take account of sleeping nodes in the case of a constrained-node must take account of sleeping nodes in the case of a constrained-node
network [RFC7228]. network [RFC7228].
D9. There must be a mechanism for handling stale discovery results. D9. There must be a mechanism for handling stale discovery results.
2.2. Requirements for Synchronization and Negotiation Capability 2.2. Requirements for Synchronization and Negotiation Capability
skipping to change at page 8, line 35 skipping to change at page 8, line 38
o Since the goal is to minimize human intervention, it is necessary o Since the goal is to minimize human intervention, it is necessary
that the network can in effect "think ahead" before changing its that the network can in effect "think ahead" before changing its
parameters. In other words there must be a possibility of parameters. In other words there must be a possibility of
forecasting the effect of a change by a "dry run" mechanism before forecasting the effect of a change by a "dry run" mechanism before
actually installing the change. This will be an application of actually installing the change. This will be an application of
the protocol rather than a feature of the protocol itself. the protocol rather than a feature of the protocol itself.
o Management logging, monitoring, alerts and tools for intervention o Management logging, monitoring, alerts and tools for intervention
are required. However, these can only be features of individual are required. However, these can only be features of individual
ASAs. Another document [I-D.eckert-anima-stable-connectivity] ASAs. Another document [I-D.ietf-anima-stable-connectivity]
discusses how such agents may be linked into conventional OAM discusses how such agents may be linked into conventional OAM
systems via an Autonomic Control Plane systems via an Autonomic Control Plane
[I-D.ietf-anima-autonomic-control-plane]. [I-D.ietf-anima-autonomic-control-plane].
SN8. The protocol will be able to deal with a wide variety of SN8. The protocol will be able to deal with a wide variety of
technical objectives, covering any type of network parameter. technical objectives, covering any type of network parameter.
Therefore the protocol will need either an explicit information model Therefore the protocol will need either an explicit information model
describing its messages, or at least a flexible and easily extensible describing its messages, or at least a flexible and easily extensible
message format. One design consideration is whether to adopt an message format. One design consideration is whether to adopt an
existing information model or to design a new one. existing information model or to design a new one.
2.3. Specific Technical Requirements 2.3. Specific Technical Requirements
T1. It should be convenient for ASA designers to define new T1. It should be convenient for ASA designers to define new
technical objectives and for programmers to express them, without technical objectives and for programmers to express them, without
excessive impact on run-time efficiency and footprint. The classes excessive impact on run-time efficiency and footprint. In
of device in which the protocol might run is discussed in particular, it should be possible for ASAs to be implemented
[I-D.behringer-anima-reference-model]. independently of each other as user space programs rather than as
kernel code. The classes of device in which the protocol might run
is discussed in [I-D.ietf-anima-reference-model].
T2. The protocol should be easily extensible in case the initially T2. The protocol should be easily extensible in case the initially
defined discovery, synchronization and negotiation mechanisms prove defined discovery, synchronization and negotiation mechanisms prove
to be insufficient. to be insufficient.
T3. To be a generic platform, the protocol payload format should be T3. To be a generic platform, the protocol payload format should be
independent of the transport protocol or IP version. In particular, independent of the transport protocol or IP version. In particular,
it should be able to run over IPv6 or IPv4. However, some functions, it should be able to run over IPv6 or IPv4. However, some functions,
such as multicasting on a link, might need to be IP version such as multicasting on a link, might need to be IP version
dependent. In case of doubt, IPv6 should be preferred. dependent. In case of doubt, IPv6 should be preferred.
skipping to change at page 11, line 25 skipping to change at page 11, line 32
technical content needs to be synchronized among two or more technical content needs to be synchronized among two or more
ASAs. ASAs.
* Negotiation Objective: an objective whose specific technical * Negotiation Objective: an objective whose specific technical
content needs to be decided in coordination with another ASA. content needs to be decided in coordination with another ASA.
o Discovery Initiator: an ASA that spontaneously starts discovery by o Discovery Initiator: an ASA that spontaneously starts discovery by
sending a discovery message referring to a specific discovery sending a discovery message referring to a specific discovery
objective. objective.
o Discovery Responder: a peer ASA which responds to the discovery o Discovery Responder: a peer that either contains an ASA supporting
objective initiated by the discovery initiator. the discovery objective indicated by the discovery initiator, or
caches the locator(s) of the ASA(s) supporting the objective. The
locator(s) are indicated in a Discovery Response, which is
normally sent by the protocol kernel, as described later.
o Synchronization Initiator: an ASA that spontaneously starts o Synchronization Initiator: an ASA that spontaneously starts
synchronization by sending a request message referring to a synchronization by sending a request message referring to a
specific synchronization objective. specific synchronization objective.
o Synchronization Responder: a peer ASA which responds with the o Synchronization Responder: a peer ASA which responds with the
value of a synchronization objective. value of a synchronization objective.
o Negotiation Initiator: an ASA that spontaneously starts o Negotiation Initiator: an ASA that spontaneously starts
negotiation by sending a request message referring to a specific negotiation by sending a request message referring to a specific
skipping to change at page 12, line 4 skipping to change at page 12, line 13
Initiator negotiates a specific negotiation objective. Initiator negotiates a specific negotiation objective.
3.2. High-Level Design Choices 3.2. High-Level Design Choices
This section describes a behavior model and some considerations for This section describes a behavior model and some considerations for
designing a generic signaling protocol initially supporting designing a generic signaling protocol initially supporting
discovery, synchronization and negotiation, which can act as a discovery, synchronization and negotiation, which can act as a
platform for different technical objectives. platform for different technical objectives.
o A generic platform o A generic platform
The protocol is designed as a generic platform, which is The protocol is designed as a generic platform, which is
independent from the synchronization or negotiation contents. It independent from the synchronization or negotiation contents. It
takes care of the general intercommunication between counterparts. takes care of the general intercommunication between counterparts.
The technical contents will vary according to the various The technical contents will vary according to the various
technical objectives and the different pairs of counterparts. technical objectives and the different pairs of counterparts.
o The protocol is expected to form part of an Autonomic Networking o The protocol is expected to form part of an Autonomic Networking
Infrastructure [I-D.behringer-anima-reference-model]. It will Infrastructure [I-D.ietf-anima-reference-model]. It will provide
provide services to ASAs via a suitable application programming services to ASAs via a suitable application programming interface,
interface, which will reflect the protocol elements but will not which will reflect the protocol elements but will not necessarily
necessarily be in one-to-one correspondence to them. It is be in one-to-one correspondence to them. It is expected that a
expected that a single instance of GRASP will exist in an single instance of GRASP will exist in an autonomic node, and that
autonomic node, and that the protocol engine and each ASA will run the protocol engine and each ASA will run as independent
as independent asynchronous processes. asynchronous processes.
o Security infrastructure and trust relationship o Security infrastructure and trust relationship
Because this negotiation protocol may directly cause changes to Because this negotiation protocol may directly cause changes to
device configurations and bring significant impacts to a running device configurations and bring significant impacts to a running
network, this protocol is assumed to run within an existing secure network, this protocol is assumed to run within an existing secure
environment with strong authentication. environment with strong authentication.
On the other hand, a limited negotiation model might be deployed On the other hand, a limited negotiation model might be deployed
based on a limited trust relationship. For example, between two based on a limited trust relationship. For example, between two
skipping to change at page 13, line 20 skipping to change at page 13, line 31
o A flexible model for synchronization o A flexible model for synchronization
GRASP supports bilateral synchronization, which could be used to GRASP supports bilateral synchronization, which could be used to
perform synchronization among a small number of nodes. It also perform synchronization among a small number of nodes. It also
supports an unsolicited flooding mode when large groups of nodes, supports an unsolicited flooding mode when large groups of nodes,
possibly including all autonomic nodes, need data for the same possibly including all autonomic nodes, need data for the same
technical objective. technical objective.
* There may be some network parameters for which a more * There may be some network parameters for which a more
traditional flooding mechanism such as DNCP traditional flooding mechanism such as DNCP [RFC7787] is
[I-D.ietf-homenet-dncp] is considered more appropriate. GRASP considered more appropriate. GRASP can coexist with DNCP.
can coexist with DNCP.
o A simple initiator/responder model for negotiation o A simple initiator/responder model for negotiation
Multi-party negotiations are too complicated to be modeled and Multi-party negotiations are too complicated to be modeled and
there might be too many dependencies among the parties to converge there might be too many dependencies among the parties to converge
efficiently. A simple initiator/responder model is more feasible efficiently. A simple initiator/responder model is more feasible
and can complete multi-party negotiations by indirect steps. and can complete multi-party negotiations by indirect steps.
o Organizing of synchronization or negotiation content o Organizing of synchronization or negotiation content
skipping to change at page 16, line 37 skipping to change at page 16, line 47
condition, UDP might become unreliable. Since this is when autonomic condition, UDP might become unreliable. Since this is when autonomic
functions are most necessary, automatic fallback to TCP MUST be functions are most necessary, automatic fallback to TCP MUST be
implemented. The simplest implementation is therefore to use only implemented. The simplest implementation is therefore to use only
TCP. TCP.
When running without an ACP, TLS MUST be supported and used by When running without an ACP, TLS MUST be supported and used by
default, except for link-local multicast messages. DTLS MAY be default, except for link-local multicast messages. DTLS MAY be
supported as an alternative but the details are out of scope for this supported as an alternative but the details are out of scope for this
document. document.
For all transport protocols, the GRASP protocol listens to the GRASP For link-local multicast, the GRASP protocol listens to the GRASP
Listen Port (Section 3.5). Listen Port (Section 3.5). This port is also used to listen for
unicast discovery responses. For unicast transport sessions used for
synchronization and negotiation, the ASA concerned listens on its own
dynamically assigned port, which is communicated to its peers during
discovery.
3.3.3. Discovery Mechanism and Procedures 3.3.3. Discovery Mechanism and Procedures
o Separated discovery and negotiation mechanisms o Separated discovery and negotiation mechanisms
Although discovery and negotiation or synchronization are Although discovery and negotiation or synchronization are
defined together in the GRASP, they are separated mechanisms. defined together in the GRASP, they are separated mechanisms.
The discovery process could run independently from the The discovery process could run independently from the
negotiation or synchronization process. Upon receiving a negotiation or synchronization process. Upon receiving a
Discovery (Section 3.7.3) message, the recipient ASA should Discovery (Section 3.7.3) message, the recipient node should
return a response message in which it either indicates itself return a response message in which it either indicates itself
as a discovery responder or diverts the initiator towards as a discovery responder or diverts the initiator towards
another more suitable ASA. another more suitable ASA.
The discovery action will normally be followed by a negotiation The discovery action will normally be followed by a negotiation
or synchronization action. The discovery results could be or synchronization action. The discovery results could be
utilized by the negotiation protocol to decide which ASA the utilized by the negotiation protocol to decide which ASA the
initiator will negotiate with. initiator will negotiate with.
It is entirely possible to use GRASP discovery without a The initiator of a discovery action for a given objective need
not be capable of supporting that objective for negotiation or
as a source for synchronization or flooding. In other words an
ASA might perform discovery because it only wishes to receive
synchronization data.
It is entirely possible to use GRASP discovery without any
subsequent negotiation or synchronization action. In this subsequent negotiation or synchronization action. In this
case, the discovered objective is simply used as a name during case, the discovered objective is simply used as a name during
the discovery process and any subsequent operations between the the discovery process and any subsequent operations between the
peers are outside the scope of GRASP. peers are outside the scope of GRASP.
o Discovery Procedures o Discovery Procedures
Discovery starts as an on-link operation. The Divert option Discovery starts as an on-link operation. The Divert option
can tell the discovery initiator to contact an off-link ASA for can tell the discovery initiator to contact an off-link ASA for
that discovery objective. Every Discovery message is sent by a that discovery objective. Every Discovery message is sent by a
discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link- discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link-
local multicast address (Section 3.5). Every network device local multicast address (Section 3.5). Every network device
that supports the GRASP always listens to a well-known UDP port that supports GRASP always listens to a well-known UDP port to
to capture the discovery messages. capture the discovery messages. Because this port is unique in
a device, this is a function of the GRASP kernel and not of an
individual ASA. As a result, each ASA will need to register
the objectives that it supports with the GRASP kernel.
If an ASA in the neighbor device supports the requested If an ASA in a neighbor device supports the requested discovery
discovery objective, it MAY respond to the link-local multicast objective, the device MAY respond to the link-local multicast
with a unicast Discovery Response message (Section 3.7.4) with with a unicast Discovery Response message (Section 3.7.4) with
locator option(s). Otherwise, if the neighbor has cached locator option(s). Otherwise, if the neighbor has cached
information about an ASA that supports the requested discovery information about an ASA that supports the requested discovery
objective (usually because it discovered the same objective objective (usually because it discovered the same objective
before), it SHOULD respond with a Discovery Response message before), it SHOULD respond with a Discovery Response message
with a Divert option pointing to the appropriate Discovery with a Divert option pointing to the appropriate Discovery
Responder. Responder.
If no discovery response is received within a reasonable If no discovery response is received within a reasonable
timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5),
skipping to change at page 21, line 4 skipping to change at page 21, line 29
timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the
synchronization request MAY be repeated, with a newly generated synchronization request MAY be repeated, with a newly generated
Session ID (Section 3.6). An exponential backoff SHOULD be used for Session ID (Section 3.6). An exponential backoff SHOULD be used for
subsequent repetitions. subsequent repetitions.
3.3.5.1. Flooding 3.3.5.1. Flooding
In the case just described, the message exchange is unicast and In the case just described, the message exchange is unicast and
concerns only one synchronization objective. For large groups of concerns only one synchronization objective. For large groups of
nodes requiring the same data, synchronization flooding is available. nodes requiring the same data, synchronization flooding is available.
For this, a flooding initiator MAY send an unsolicited Flood For this, a flooding initiator MAY send an unsolicited Flood
Synchronization message containing one or more Synchronization Synchronization message containing one or more Synchronization
Objective option(s), if and only if the specification of those Objective option(s), if and only if the specification of those
objectives permits it. This is sent as a multicast message to the objectives permits it. This is sent as a multicast message to the
ALL_GRASP_NEIGHBOR multicast address (Section 3.5). To ensure that ALL_GRASP_NEIGHBOR multicast address (Section 3.5).
flooding does not result in a loop, the originator of the Flood
Synchronization message MUST set the loop count in the objectives to Every network device that supports GRASP always listens to a well-
a suitable value (the default is GRASP_DEF_LOOPCT). In this case a known UDP port to capture flooding messages. Because this port is
suitable mechanism is needed to avoid excessive multicast traffic. unique in a device, this is a function of the GRASP kernel.
This mechanism MUST be defined as part of the specification of the
synchronization objective(s) concerned. It might be a simple rate To ensure that flooding does not result in a loop, the originator of
limit or a more complex mechanism such as the Trickle algorithm the Flood Synchronization message MUST set the loop count in the
objectives to a suitable value (the default is GRASP_DEF_LOOPCT).
Also, a suitable mechanism is needed to avoid excessive multicast
traffic. This mechanism MUST be defined as part of the specification
of the synchronization objective(s) concerned. It might be a simple
rate limit or a more complex mechanism such as the Trickle algorithm
[RFC6206]. [RFC6206].
A GRASP device with multiple link-layer interfaces (typically a A GRASP device with multiple link-layer interfaces (typically a
router) MUST support synchronization flooding on all interfaces. If router) MUST support synchronization flooding on all interfaces. If
it receives a multicast Flood Synchronization message on a given it receives a multicast Flood Synchronization message on a given
interface, it MUST relay it by re-issuing a Flood Synchronization interface, it MUST relay it by re-issuing a Flood Synchronization
message on its other interfaces. The relayed message MUST have the message on its other interfaces. The relayed message MUST have the
same Session ID as the incoming message and MUST be tagged with the same Session ID as the incoming message and MUST be tagged with the
IP address of its original initiator. IP address of its original initiator.
skipping to change at page 21, line 47 skipping to change at page 22, line 27
synchronization loops and mitigate potential overload. synchronization loops and mitigate potential overload.
Note that this mechanism is unreliable in the case of sleeping nodes. Note that this mechanism is unreliable in the case of sleeping nodes.
Sleeping nodes that require an objective subject to flooding SHOULD Sleeping nodes that require an objective subject to flooding SHOULD
periodically request unicast synchronization for that objective. periodically request unicast synchronization for that objective.
The multicast messages for synchronization flooding are subject to The multicast messages for synchronization flooding are subject to
the security rules in Section 3.3.1. In practice this means that the security rules in Section 3.3.1. In practice this means that
they MUST NOT be transmitted and MUST be ignored on receipt unless they MUST NOT be transmitted and MUST be ignored on receipt unless
there is an operational ACP. However, because of the security there is an operational ACP. However, because of the security
weakness of link-local multicast (Section 4), synchronization weakness of link-local multicast (Section 5), synchronization
objectives that are flooded SHOULD NOT contain unencrypted sensitive objectives that are flooded SHOULD NOT contain unencrypted sensitive
information and SHOULD be validated by the recipient ASA. information and SHOULD be validated by the recipient ASA.
3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage) 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage)
A Discovery message MAY include a Synchronization Objective option. A Discovery message MAY include a Synchronization Objective option.
In this case the Discovery message also acts as a Request In this case the Discovery message also acts as a Request
Synchronization message to indicate to the Discovery Responder that Synchronization message to indicate to the Discovery Responder that
it could directly reply to the Discovery Initiator with a it could directly reply to the Discovery Initiator with a
Synchronization message Section 3.7.9 with synchronization data for Synchronization message Section 3.7.9 with synchronization data for
skipping to change at page 22, line 32 skipping to change at page 23, line 10
It is expected that a GRASP implementation will reside in an It is expected that a GRASP implementation will reside in an
autonomic node that also contains both the appropriate security autonomic node that also contains both the appropriate security
environment (preferably the ACP) and one or more Autonomic Service environment (preferably the ACP) and one or more Autonomic Service
Agents (ASAs). In the minimal case of a single-purpose device, these Agents (ASAs). In the minimal case of a single-purpose device, these
three components might be fully integrated. A more common model is three components might be fully integrated. A more common model is
expected to be a multi-purpose device capable of containing several expected to be a multi-purpose device capable of containing several
ASAs. In this case it is expected that the ACP, GRASP and the ASAs ASAs. In this case it is expected that the ACP, GRASP and the ASAs
will be implemented as separate processes, which are probably multi- will be implemented as separate processes, which are probably multi-
threaded to support asynchronous operation. It is expected that threaded to support asynchronous operation. It is expected that
GRASP will access the ACP by using a typical socket interface. Well GRASP will access the ACP by using a typical socket interface. A
defined Application Programming Interfaces (APIs) will be needed well defined Application Programming Interface (API) will be needed
between GRASP and the ASAs. For further details of possible between GRASP and the ASAs. In some implementations, ASAs would run
deployment models, see [I-D.behringer-anima-reference-model]. in user space with a GRASP library providing the API, and this
library would in turn communicate via system calls with core GRASP
functions running in kernel mode. For further details of possible
deployment models, see [I-D.ietf-anima-reference-model].
3.5. GRASP Constants 3.5. GRASP Constants
o ALL_GRASP_NEIGHBOR o ALL_GRASP_NEIGHBOR
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.
skipping to change at page 24, line 18 skipping to change at page 24, line 47
No Operation. No Operation.
3.7.2. GRASP Message Format 3.7.2. GRASP Message Format
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) [RFC7049]. In this in Concise Binary Object Representation (CBOR) [RFC7049]. In this
specification, they are described using CBOR data definition language specification, they are described using CBOR data definition language
(CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is
used to describe each item in this section. A complete and normative used to describe each item in this section. A complete and normative
CDDL specification of GRASP is given in Section 5, including CDDL specification of GRASP is given in Section 6, including
constants such as message types. constants such as message types.
Every GRASP message, except the No Operation message, carries a Every GRASP message, except the No Operation message, carries a
Session ID (Section 3.6). Options are then presented serially in the Session ID (Section 3.6). Options are then presented serially in the
options field. 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
skipping to change at page 24, line 42 skipping to change at page 25, line 26
MESSAGE_TYPE = 1..255 MESSAGE_TYPE = 1..255
session-id = 0..16777215 ;up to 24 bits session-id = 0..16777215 ;up to 24 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 3.7.11. The No Operation (noop) message is described in Section 3.7.11.
The various MESSAGE_TYPE values are defined in Section 5. The various MESSAGE_TYPE values are defined in Section 6.
All other message elements are described below and formally defined All other message elements are described below and formally defined
in Section 5. in Section 6.
3.7.3. Discovery Message 3.7.3. Discovery Message
In fragmentary CDDL, a Discovery message follows the pattern: In fragmentary CDDL, a Discovery message follows the pattern:
discovery-message = [M_DISCOVERY, session-id, initiator, objective] discovery-message = [M_DISCOVERY, session-id, initiator, objective]
A discovery initiator sends a Discovery message to initiate a A discovery initiator sends a Discovery message to initiate a
discovery process for a particular objective option. discovery process for a particular objective option.
The discovery initiator sends the Discovery messages to the link- The discovery initiator sends the Discovery messages via UDP to port
local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast
the discovery results (including responding discovery objectives and address. It then listens for unicast TCP responses on the same port,
corresponding unicast addresses, FQDNs or URIs). and stores the discovery results (including responding discovery
objectives and corresponding unicast locators).
The 'initiator' field in the message is a globally unique IP address The 'initiator' field in the message is a globally unique IP address
of the initiator, for the sole purpose of disambiguating the Session of the initiator, for the sole purpose of disambiguating the Session
ID in other nodes. If for some reason the initiator does not have a ID in other nodes. If for some reason the initiator does not have a
globally unique IP address, it MUST use a link-local address for this globally unique IP address, it MUST use a link-local address for this
purpose that is highly likely to be unique, for example using purpose that is highly likely to be unique, for example using
[RFC7217]. [RFC7217].
A Discovery message MUST include exactly one of the following: A Discovery message MUST include exactly one of the following:
skipping to change at page 26, line 6 skipping to change at page 26, line 40
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, response-message = [M_RESPONSE, session-id, initiator,
(+locator-option // divert-option), ?objective)] (+locator-option // divert-option), ?objective)]
A node which receives a Discovery message SHOULD send a Discovery A node which receives a Discovery message SHOULD send a Discovery
Response message if and only if it can respond to the discovery. It Response message if and only if it can respond to the discovery. It
MUST contain the same Session ID and initiator as the Discovery MUST contain the same Session ID and initiator as the Discovery
message. It MAY include a copy of the discovery objective from the message. It MAY include a copy of the discovery objective from the
Discovery message. Discovery message. It is sent to the sender of the Discovery message
via TCP at the port GRASP_LISTEN_PORT.
If the responding node supports the discovery objective of the If the responding node supports the discovery objective of the
discovery, it MUST include at least one kind of locator option discovery, it MUST include at least one kind of locator option
(Section 3.8.5) to indicate its own location. A sequence of multiple (Section 3.8.5) to indicate its own location. A sequence of multiple
kinds of locator options (e.g. IP address option and FQDN option) is kinds of locator options (e.g. IP address option and FQDN option) is
also valid. also valid.
If the responding node itself does not support the discovery If the responding node itself does not support the discovery
objective, but it knows the locator of the discovery objective, then objective, but it knows the locator of the discovery objective, then
it SHOULD respond to the discovery message with a divert option it SHOULD respond to the discovery message with a divert option
skipping to change at page 26, line 32 skipping to change at page 27, line 18
In fragmentary CDDL, Request Negotiation and Request Synchronization In fragmentary CDDL, Request Negotiation and Request Synchronization
messages follow the patterns: messages follow the patterns:
request-negotiation-message = [M_REQ_NEG, session-id, objective] request-negotiation-message = [M_REQ_NEG, session-id, objective]
request-synchronization-message = [M_REQ_SYN, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective]
A negotiation or synchronization requesting node sends the A negotiation or synchronization requesting node sends the
appropriate Request message to the unicast address (directly stored appropriate Request message to the unicast address (directly stored
or resolved from an FQDN) of the negotiation or synchronization or resolved from an FQDN or URI) of the negotiation or
counterpart (selected from the discovery results). synchronization counterpart, using the appropriate protocol and port
numbers (selected from the discovery results).
A Request message MUST include the relevant objective option. In the A Request message MUST include the relevant objective option. In the
case of Request Negotiation, the objective option MUST include the case of Request Negotiation, the objective option MUST include the
requested value. requested value.
When an initiator sends a Request Negotiation message, it MUST When an initiator sends a Request Negotiation message, it MUST
initialize a negotiation timer for the new negotiation thread with initialize a negotiation timer for the new negotiation thread with
the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is the value GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is
modified by a Confirm Waiting message (Section 3.7.8), the initiator modified by a Confirm Waiting message (Section 3.7.8), the initiator
will consider that the negotiation has failed when the timer expires. will consider that the negotiation has failed when the timer expires.
skipping to change at page 29, line 15 skipping to change at page 29, line 47
3.8. GRASP Options 3.8. 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.
3.8.1. Format of GRASP Options 3.8.1. Format of GRASP Options
GRASP options are CBOR objects that MUST start with an unsigned GRASP options are CBOR objects 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 5. Apart from These option types are formally defined in Section 6. Apart from
that the only format requirement is that each option MUST be a well- 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 formed CBOR object. In general a CBOR array format is RECOMMENDED to
limit overhead. limit overhead.
GRASP options are usually scoped by using encapsulation. However, GRASP options are usually scoped by using encapsulation. However,
this is not a requirement this is not a requirement
3.8.2. Divert Option 3.8.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
skipping to change at page 30, line 29 skipping to change at page 31, line 12
Note: there are scenarios where a negotiation counterpart wants to Note: there are scenarios where a negotiation counterpart wants to
decline the proposed negotiation content and continue the negotiation decline the proposed negotiation content and continue the negotiation
process. For these scenarios, the negotiation counterpart SHOULD use process. For these scenarios, the negotiation counterpart SHOULD use
a Negotiate message, with either an objective option that contains a a Negotiate message, with either an objective option that contains a
data field set to indicate a meaningless initial value, or a specific data field set to indicate a meaningless initial value, or a specific
objective option that provides further conditions for convergence. objective option that provides further conditions for convergence.
3.8.5. Locator Options 3.8.5. Locator Options
These locator options are used to present reachability information These locator options are used to present reachability information
for an ASA, a device or an interface. They are Locator IPv4 Address for an ASA, a device or an interface. They are Locator IPv6 Address
Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified
Domain Name) Option and Uniform Resource Identifier Option. Domain Name) Option and URI (Uniform Resource Identifier) Option.
Since ASAs will normally run as independent user programs, locator
options need to indicate the network layer locator plus the transport
protocol and port number for reaching the target. For this reason,
the Locator Options for IP addresses and FQDNs include this
information explicitly. In the case of the URI Option, this
information can be encoded in the URI itself.
Note: It is assumed that all locators are in scope throughout the Note: It is assumed that all locators are in scope throughout the
GRASP domain. GRASP is not intended to work across disjoint GRASP domain. GRASP is not intended to work across disjoint
addressing or naming realms. addressing or naming realms.
3.8.5.1. Locator IPv4 address option 3.8.5.1. Locator IPv6 address option
In fragmentary CDDL, the IPv4 address option follows the pattern:
ipv4-locator-option = bytes .size 4
The content of this option is a binary IPv4 address.
Note: If an operator has internal network address translation for
IPv4, this option MUST NOT be used within the Divert option.
3.8.5.2. Locator IPv6 address option
In fragmentary CDDL, the IPv6 address option follows the pattern: In fragmentary CDDL, the IPv6 address option follows the pattern:
ipv6-locator-option = bytes .size 16 ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number]
ipv6-address = bytes .size 16
The content of this option is a binary IPv6 address. transport-proto = IPPROTO_TCP / IPPROTO_UDP
IPPROTO_TCP = 6
IPPROTO_UDP = 17
port-number = 0..65535
The content of this option is a binary IPv6 address followed by the
protocol number and port number to be used.
Note 1: The IPv6 address MUST normally have global scope. Note 1: The IPv6 address MUST normally have global scope.
Exceptionally, during node bootstrap, a link-local address MAY be Exceptionally, during node bootstrap, a link-local address MAY be
used for specific objectives only. used for specific objectives only.
Note 2: A link-local IPv6 address MUST NOT be used when this option Note 2: A link-local IPv6 address MUST NOT be used when this option
is included in a Divert option. is included in a Divert option.
3.8.5.2. Locator IPv4 address option
In fragmentary CDDL, the IPv4 address option follows the pattern:
ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address,
transport-proto, port-number]
ipv4-address = bytes .size 4
The content of this option is a binary IPv4 address followed by the
protocol number and port number to be used.
Note: If an operator has internal network address translation for
IPv4, this option MUST NOT be used within the Divert option.
3.8.5.3. Locator FQDN option 3.8.5.3. Locator FQDN option
In fragmentary CDDL, the FQDN option follows the pattern: In fragmentary CDDL, the FQDN option follows the pattern:
fqdn-locator-option = [O_FQDN_LOCATOR, text] fqdn-locator-option = [O_FQDN_LOCATOR, text,
transport-proto, port-number]
The content of this option is the Fully Qualified Domain Name of the The content of this option is the Fully Qualified Domain Name of the
target. target followed by the protocol number and port number to be used.
Note 1: Any FQDN which might not be valid throughout the network in Note 1: Any FQDN which might not be valid throughout the network in
question, such as a Multicast DNS name [RFC6762], MUST NOT be used question, such as a Multicast DNS name [RFC6762], MUST NOT be used
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.
3.8.5.4. Locator URI option 3.8.5.4. Locator URI option
In fragmentary CDDL, the URI option follows the pattern: In fragmentary CDDL, the URI option follows the pattern:
uri-locator-option = [O_URI_LOCATOR, text] uri-locator = [O_URI_LOCATOR, text]
The content of this option is the Uniform Resource Identifier of the The content of this option is the Uniform Resource Identifier of the
target [RFC3986]. target [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.
It is intended for special purposes such as discovering external It is intended for special purposes such as discovering external
skipping to change at page 32, line 19 skipping to change at page 33, line 22
objective = [objective-name, objective-flags, loop-count, ?any] objective = [objective-name, objective-flags, loop-count, ?any]
objective-name = text objective-name = text
loop-count = 0..255 loop-count = 0..255
All objectives are identified by a unique name which is a case- All objectives are identified by a unique name which is a case-
sensitive UTF-8 string. sensitive UTF-8 string.
The names of generic objectives MUST NOT include a colon (":") and The names of generic objectives MUST NOT include a colon (":") and
MUST be registered with IANA (Section 6). MUST be registered with IANA (Section 7).
The names of privately defined objectives MUST include at least one The names of privately defined objectives MUST include at least one
colon (":"). The string preceding the last colon in the name MUST be colon (":"). The string preceding the last colon in the name MUST be
globally unique and in some way identify the entity or person globally unique and in some way identify the entity or person
defining the objective. The following three methods MAY be used to defining the objective. The following three methods MAY be used to
create such a globally unique string: create such a globally unique string:
1. The unique string is a decimal number representing a registered 1. The unique string is a decimal number representing a registered
32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that
uniquely identifies the enterprise defining the objective. uniquely identifies the enterprise defining the objective.
skipping to change at page 35, line 32 skipping to change at page 36, line 32
The names "EX0" through "EX9" have been reserved for experimental The names "EX0" through "EX9" have been reserved for experimental
options. Multiple names have been assigned because a single options. Multiple names have been assigned because a single
experiment may use multiple options simultaneously. These experiment may use multiple options simultaneously. These
experimental options are highly likely to have different meanings experimental options are highly likely to have different meanings
when used for different experiments. Therefore, they SHOULD NOT be when used for different experiments. Therefore, they SHOULD NOT be
used without an explicit human decision and SHOULD NOT be used in used without an explicit human decision and SHOULD NOT be used in
unmanaged networks such as home networks. unmanaged networks such as home networks.
These names are also RECOMMENDED for use in documentation examples. These names are also RECOMMENDED for use in documentation examples.
4. Security Considerations 4. Implementation Status [RFC Editor: please remove]
Two prototype implementations of GRASP have been made.
4.1. BUPT C++ Implementation
o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp
o Description: C++ implementation of GRASP kernel and API
o Maturity: Prototype code, interoperable between Ubuntu.
o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03.
Since it was implemented based on the old version draft, the most
significant limitations comparing to current protocol design
include:
* Not support CBOR
* Not support Flooding
* Not support loop avoidance
* only coded for IPv6, any IPv4 is accidental
o Licensing: Huawei License.
o Experience: https://github.com/liubingpang/IETF-Anima-Signaling-
Protocol/blob/master/README.md
o Contact: https://github.com/liubingpang/IETF-Anima-Signaling-
Protocol
4.2. Python Implementation
o Name: graspy
o Description: Python 3 implementation of GRASP kernel and API.
o Maturity: Prototype code, interoperable between Windows 7 and
Debian.
o Coverage: Corresponds to draft-ietf-anima-grasp-05. Limitations
include:
* insecure: uses a dummy ACP module and does not implement TLS
* only coded for IPv6, any IPv4 is accidental
* FQDN and URI locators incompletely supported
* no code for rapid mode
* relay code is lazy (no rate control)
* all unicast transactions use TCP (no unicast UDP)
* optional Objective option in Response messages not implemented
* workarounds for defects in Python socket module and Windows
socket peculiarities
o Licensing: Simplified BSD
o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf
o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/
5. Security Considerations
It is obvious that a successful attack on negotiation-enabled nodes It is obvious that a successful attack on negotiation-enabled nodes
would be extremely harmful, as such nodes might end up with a would be extremely harmful, as such nodes might end up with a
completely undesirable configuration that would also adversely affect completely undesirable configuration that would also adversely affect
their peers. GRASP nodes and messages therefore require full their peers. GRASP nodes and messages therefore require full
protection. protection.
- Authentication - Authentication
A cryptographically authenticated identity for each device is A cryptographically authenticated identity for each device is
skipping to change at page 37, line 30 skipping to change at page 40, line 5
inevitably be insecure and GRASP synchronization and negotiation inevitably be insecure and GRASP synchronization and negotiation
will be impossible until enrollment is complete. will be impossible until enrollment is complete.
- Security of discovered locators - Security of discovered locators
When GRASP discovery returns an IP address, it MUST be that of a When GRASP discovery returns an IP address, it MUST be that of a
node within the secure environment (Section 3.3.1). If it returns node within the secure environment (Section 3.3.1). If it returns
an FQDN or a URI, the ASA that receives it MUST NOT assume that an FQDN or a URI, the ASA that receives it MUST NOT assume that
the target of the locator is within the secure environment. the target of the locator is within the secure environment.
5. CDDL Specification of GRASP 6. CDDL Specification of GRASP
<CODE BEGINS> <CODE BEGINS>
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 = 0..255 MESSAGE_TYPE = 0..255
session-id = 0..16777215 ;up to 24 bits session-id = 0..16777215 ;up to 24 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, response-message = [M_RESPONSE, session-id, initiator,
(+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
flood-message = [M_FLOOD, session-id, initiator, +objective]
message /= request-negotiation-message message /= flood-message
request-negotiation-message = [M_REQ_NEG, session-id, objective] flood-message = [M_FLOOD, session-id, initiator, +objective]
message /= request-synchronization-message message /= request-negotiation-message
request-synchronization-message = [M_REQ_SYN, session-id, objective] request-negotiation-message = [M_REQ_NEG, session-id, objective]
message /= negotiation-message message /= request-synchronization-message
negotiation-message = [M_NEGOTIATE, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective]
message /= end-message message /= negotiation-message
end-message = [M_END, session-id, accept-option / decline-option ] negotiation-message = [M_NEGOTIATE, session-id, objective]
message /= wait-message message /= end-message
wait-message = [M_WAIT, session-id, waiting-time] end-message = [M_END, session-id, accept-option / decline-option ]
noop-message = [M_NOOP] message /= wait-message
wait-message = [M_WAIT, session-id, waiting-time]
divert-option = [O_DIVERT, +locator-option] noop-message = [M_NOOP]
accept-option = [O_ACCEPT] divert-option = [O_DIVERT, +locator-option]
decline-option = [O_DECLINE, ?reason] accept-option = [O_ACCEPT]
reason = text ;optional error message
waiting-time = 0..4294967295 ; in milliseconds decline-option = [O_DECLINE, ?reason]
reason = text ;optional error message
waiting-time = 0..4294967295 ; in milliseconds
locator-option /= ipv4-locator-option locator-option /= [O_IPv4_LOCATOR, ipv4-address,
ipv4-locator-option = bytes .size 4 transport-proto, port-number]
; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] ipv4-address = bytes .size 4
locator-option /= ipv6-locator-option locator-option /= [O_IPv6_LOCATOR, ipv6-address,
ipv6-locator-option = bytes .size 16 transport-proto, port-number]
ipv6-address = bytes .size 16
locator-option /= fqdn-locator-option locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number]
fqdn-locator-option = [O_FQDN_LOCATOR, text]
locator-option /= uri-locator-option transport-proto = IPPROTO_TCP / IPPROTO_UDP
uri-locator-option = [O_URI_LOCATOR, text] IPPROTO_TCP = 6
IPPROTO_UDP = 17
port-number = 0..65535
initiator = ipv4-locator-option / ipv6-locator-option locator-option /= [O_URI_LOCATOR, text]
objective-flags = uint .bits objective-flag initiator = ipv4-address / ipv6-address
objective-flag = &( objective-flags = uint .bits objective-flag
F_DISC: 0 ; valid for discovery only
F_NEG: 1 ; valid for discovery and negotiation
F_SYNCH: 2) ; valid for discovery and synchronization
objective = [objective-name, objective-flags, loop-count, ?any] objective-flag = &(
F_DISC: 0 ; valid for discovery only
F_NEG: 1 ; valid for discovery and negotiation
F_SYNCH: 2) ; valid for discovery and synchronization
objective-name = text ;see specification for uniqueness rules objective = [objective-name, objective-flags, loop-count, ?any]
loop-count = 0..255 objective-name = text ;see specification for uniqueness rules
; Constants for message types and option types loop-count = 0..255
M_NOOP = 0 ; Constants for message types and option types
M_DISCOVERY = 1
M_RESPONSE = 2
M_REQ_NEG = 3
M_REQ_SYN = 4
M_NEGOTIATE = 5
M_END = 6
M_WAIT = 7
M_SYNCH = 8
M_FLOOD = 9
O_DIVERT = 100 M_NOOP = 0
O_ACCEPT = 101 M_DISCOVERY = 1
O_DECLINE = 102 M_RESPONSE = 2
O_FQDN_LOCATOR = 103 M_REQ_NEG = 3
O_URI_LOCATOR = 104 M_REQ_SYN = 4
<CODE ENDS> M_NEGOTIATE = 5
M_END = 6
M_WAIT = 7
M_SYNCH = 8
M_FLOOD = 9
6. IANA Considerations O_DIVERT = 100
O_ACCEPT = 101
O_DECLINE = 102
O_IPv6_LOCATOR = 103
O_IPv4_LOCATOR = 104
O_FQDN_LOCATOR = 105
O_URI_LOCATOR = 106
<CODE ENDS>
7. IANA Considerations
This document defines the General Discovery and Negotiation Protocol This document defines the General Discovery and Negotiation Protocol
(GRASP). (GRASP).
Section 3.5 explains the following link-local multicast addresses, Section 3.5 explains the following link-local multicast addresses,
which IANA is requested to assign for use by GRASP: which IANA is requested to assign for use by GRASP:
ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in
the IPv6 Link-Local Scope Multicast Addresses registry. the IPv6 Link-Local Scope Multicast Addresses registry.
skipping to change at page 40, line 4 skipping to change at page 42, line 30
ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in
the IPv6 Link-Local Scope Multicast Addresses registry. the IPv6 Link-Local Scope Multicast Addresses registry.
ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in
the IPv4 Multicast Local Network Control Block. the IPv4 Multicast Local Network Control Block.
Section 3.5 explains the following UDP and TCP port, which IANA is Section 3.5 explains the following UDP and TCP port, which IANA is
requested to assign for use by GRASP: requested to assign for use by GRASP:
GRASP_LISTEN_PORT: (TBD3) GRASP_LISTEN_PORT: (TBD3)
The IANA is requested to create a GRASP Parameter Registry including The IANA is requested to create a GRASP Parameter Registry including
two registry tables. These are the GRASP Messages and Options two registry tables. These are the GRASP Messages and Options
Table and the GRASP Objective Names Table. Table and the GRASP Objective Names Table.
GRASP Messages and Options Table. The values in this table are names GRASP Messages and Options Table. The values in this table are names
paired with decimal integers. Future values MUST be assigned using paired with decimal integers. Future values MUST be assigned using
the Standards Action policy defined by [RFC5226]. The following the Standards Action policy defined by [RFC5226]. The following
initial values are assigned by this document: initial values are assigned by this document:
M_NOOP = 0 M_NOOP = 0
M_DISCOVERY = 1 M_DISCOVERY = 1
M_RESPONSE = 2 M_RESPONSE = 2
M_REQ_NEG = 3 M_REQ_NEG = 3
M_REQ_SYN = 4 M_REQ_SYN = 4
M_NEGOTIATE = 5 M_NEGOTIATE = 5
M_END = 6 M_END = 6
M_WAIT = 7 M_WAIT = 7
M_SYNCH = 8 M_SYNCH = 8
M_FLOOD = 9 M_FLOOD = 9
O_DIVERT = 100 O_DIVERT = 100
O_ACCEPT = 101 O_ACCEPT = 101
O_DECLINE = 102 O_DECLINE = 102
O_FQDN_LOCATOR = 103 O_IPv6_LOCATOR = 103
O_URI_LOCATOR = 104 O_IPv4_LOCATOR = 104
O_FQDN_LOCATOR = 105
O_URI_LOCATOR = 106
GRASP Objective Names Table. The values in this table are UTF-8 GRASP Objective Names Table. The values in this table are UTF-8
strings. Future values MUST be assigned using the Specification strings. Future values MUST be assigned using the Specification
Required policy defined by [RFC5226]. The following initial values Required policy defined by [RFC5226]. The following initial values
are assigned by this document: are assigned by this document:
EX0 EX0
EX1 EX1
EX2 EX2
EX3 EX3
EX4 EX4
EX5 EX5
EX6 EX6
EX7 EX7
EX8 EX8
EX9 EX9
7. Acknowledgements 8. Acknowledgements
A major contribution to the original version of this document was A major contribution to the original version of this document was
made by Sheng Jiang. made by Sheng Jiang.
Valuable comments were received from Michael Behringer, Jeferson Valuable comments were received from Michael Behringer, Jeferson
Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Halpern, Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Toerless Eckert, Yu Fu,
Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Joel Halpern, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso,
Michael Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and Reshad Rahman, Michael Richardson, Markus Stenberg, Rene Struik,
other participants in the NMRG research group and the ANIMA working Dacheng Zhang, and other participants in the NMRG research group and
group. the ANIMA working group.
This document was produced using the xml2rfc tool [RFC2629].
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language Vigano, C. and H. Birkholz, "CBOR data definition language
(CDDL): a notational convention to express CBOR data (CDDL): a notational convention to express CBOR data
structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work
in progress), October 2015. in progress), March 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 42, line 15 skipping to change at page 45, line 11
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
8.2. Informative References 9.2. Informative References
[I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-behringer-anima-
reference-model-04 (work in progress), October 2015.
[I-D.chaparadza-intarea-igcp] [I-D.chaparadza-intarea-igcp]
Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. Behringer, M., Chaparadza, R., Petre, R., Li, X., and H.
Mahkonen, "IP based Generic Control Protocol (IGCP)", Mahkonen, "IP based Generic Control Protocol (IGCP)",
draft-chaparadza-intarea-igcp-00 (work in progress), July draft-chaparadza-intarea-igcp-00 (work in progress), July
2011. 2011.
[I-D.eckert-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-
eckert-anima-stable-connectivity-02 (work in progress),
October 2015.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", draft-ietf-anima-autonomic- Autonomic Control Plane", draft-ietf-anima-autonomic-
control-plane-01 (work in progress), October 2015. control-plane-02 (work in progress), March 2016.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S. Pritikin, M., Richardson, M., Behringer, M., and S.
Bjarnason, "Bootstrapping Key Infrastructures", draft- Bjarnason, "Bootstrapping Key Infrastructures", draft-
ietf-anima-bootstrapping-keyinfra-01 (work in progress), ietf-anima-bootstrapping-keyinfra-02 (work in progress),
October 2015. March 2016.
[I-D.ietf-homenet-dncp] [I-D.ietf-anima-reference-model]
Stenberg, M. and S. Barth, "Distributed Node Consensus Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Protocol", draft-ietf-homenet-dncp-12 (work in progress), Liu, B., Jeff, J., and J. Strassner, "A Reference Model
November 2015. for Autonomic Networking", draft-ietf-anima-reference-
model-01 (work in progress), March 2016.
[I-D.ietf-homenet-hncp] [I-D.ietf-anima-stable-connectivity]
Stenberg, M., Barth, S., and P. Pfister, "Home Networking Eckert, T. and M. Behringer, "Using Autonomic Control
Control Protocol", draft-ietf-homenet-hncp-10 (work in Plane for Stable Connectivity of Network OAM", draft-ietf-
progress), November 2015. anima-stable-connectivity-00 (work in progress), January
2016.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in Protocol", draft-ietf-netconf-restconf-13 (work in
progress), December 2015. progress), April 2016.
[I-D.liang-iana-pen] [I-D.liang-iana-pen]
Liang, P., Melnikov, A., and D. Conrad, "Private Liang, P., Melnikov, A., and D. Conrad, "Private
Enterprise Number (PEN) practices and Internet Assigned Enterprise Number (PEN) practices and Internet Assigned
Numbers Authority (IANA) registration considerations", Numbers Authority (IANA) registration considerations",
draft-liang-iana-pen-06 (work in progress), July 2015. draft-liang-iana-pen-06 (work in progress), July 2015.
[I-D.stenberg-anima-adncp] [I-D.stenberg-anima-adncp]
Stenberg, M., "Autonomic Distributed Node Consensus Stenberg, M., "Autonomic Distributed Node Consensus
Protocol", draft-stenberg-anima-adncp-00 (work in Protocol", draft-stenberg-anima-adncp-00 (work in
progress), March 2015. progress), March 2015.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy,
"Server Cache Synchronization Protocol (SCSP)", RFC 2334,
DOI 10.17487/RFC2334, April 1998,
<http://www.rfc-editor.org/info/rfc2334>.
[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,
<http://www.rfc-editor.org/info/rfc2608>. <http://www.rfc-editor.org/info/rfc2608>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[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,
<http://www.rfc-editor.org/info/rfc2865>. <http://www.rfc-editor.org/info/rfc2865>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 45, line 32 skipping to change at page 48, line 16
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,
<http://www.rfc-editor.org/info/rfc7575>. <http://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,
<http://www.rfc-editor.org/info/rfc7576>. <http://www.rfc-editor.org/info/rfc7576>.
[RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
<http://www.rfc-editor.org/info/rfc7787>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>.
Appendix A. Open Issues Appendix A. Open Issues
o 7. Cross-check against other ANIMA WG documents for consistency o 7. Cross-check against other ANIMA WG documents for consistency
and gaps. and gaps.
o 43. Rapid mode synchronization and negotiation is currently o 43. Rapid mode synchronization and negotiation is currently
limited to a single objective for simplicity of design and limited to a single objective for simplicity of design and
implementation. A future consideration is to allow multiple implementation. A future consideration is to allow multiple
objectives in rapid mode for greater efficiency. objectives in rapid mode for greater efficiency.
skipping to change at page 52, line 15 skipping to change at page 55, line 7
o 47. REQUEST is a dual purpose message (request negotiation or o 47. REQUEST is a dual purpose message (request negotiation or
request synchronization). Would it be better to split this into request synchronization). Would it be better to split this into
two different messages (and adjust various message names two different messages (and adjust various message names
accordingly)? accordingly)?
RESOLVED: Yes. Done. RESOLVED: Yes. Done.
Appendix C. Change log [RFC Editor: Please remove] Appendix C. Change log [RFC Editor: Please remove]
draft-ietf-anima-grasp-05, 2016-05-13:
Noted in requirement T1 that it should be possible to implement ASAs
independently as user space programs.
Protocol change: Added protocol number and port to discovery
response. Updated protocol description, CDDL and IANA considerations
accordingly.
Clarified that discovery and flood multicasts are handled by the
GRASP kernel, not directly by ASAs.
Clarified that a node may discover an objective without supporting it
for synchronization or negotiation.
Added Implementation Status section.
Added reference to SCSP.
Editorial fixes.
draft-ietf-anima-grasp-04, 2016-03-11: draft-ietf-anima-grasp-04, 2016-03-11:
Protocol change: Restored initiator field in certain messages and Protocol change: Restored initiator field in certain messages and
adjusted relaying rules to provide complete loop detection. adjusted relaying rules to provide complete loop detection.
Updated IANA Considerations. Updated IANA Considerations.
draft-ietf-anima-grasp-03, 2016-02-24: draft-ietf-anima-grasp-03, 2016-02-24:
Protocol change: Removed initiator field from certain messages and Protocol change: Removed initiator field from certain messages and
skipping to change at page 56, line 46 skipping to change at page 60, line 8
of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a of this writing. Firstly, RESTCONF [I-D.ietf-netconf-restconf] is a
protocol intended to convey NETCONF information expressed in the YANG protocol intended to convey NETCONF information expressed in the YANG
language via HTTP, including the ability to transit HTML language via HTTP, including the ability to transit HTML
intermediaries. While this is a powerful approach in the context of intermediaries. While this is a powerful approach in the context of
centralised configuration of a complex network, it is not well centralised configuration of a complex network, it is not well
adapted to efficient interactive negotiation between peer devices, adapted to efficient interactive negotiation between peer devices,
especially simple ones that are unlikely to include YANG processing especially simple ones that are unlikely to include YANG processing
already. already.
Secondly, we consider Distributed Node Consensus Protocol (DNCP) Secondly, we consider Distributed Node Consensus Protocol (DNCP)
[I-D.ietf-homenet-dncp]. This is defined as a generic form of state [RFC7787]. This is defined as a generic form of state
synchronization protocol, with a proposed usage profile being the synchronization protocol, with a proposed usage profile being the
Home Networking Control Protocol (HNCP) [I-D.ietf-homenet-hncp] for Home Networking Control Protocol (HNCP) [RFC7788] for configuring
configuring Homenet routers. A specific application of DNCP for Homenet routers. A specific application of DNCP for autonomic
autonomic networking was proposed in [I-D.stenberg-anima-adncp]. networking was proposed in [I-D.stenberg-anima-adncp].
DNCP "is designed to provide a way for each participating node to DNCP "is designed to provide a way for each participating node to
publish a set of TLV (Type-Length-Value) tuples, and to provide a publish a set of TLV (Type-Length-Value) tuples, and to provide a
shared and common view about the data published... DNCP is most shared and common view about the data published... DNCP is most
suitable for data that changes only infrequently... If constant rapid suitable for data that changes only infrequently... If constant rapid
state changes are needed, the preferable choice is to use an state changes are needed, the preferable choice is to use an
additional point-to-point channel..." additional point-to-point channel..."
Specific features of DNCP include: Specific features of DNCP include:
skipping to change at page 57, line 38 skipping to change at page 60, line 47
addresses. addresses.
DNCP does not meet the needs of a general negotiation protocol, DNCP does not meet the needs of a general negotiation protocol,
because it is designed specifically for flooding synchronization. because it is designed specifically for flooding synchronization.
Also, in its HNCP profile it is limited to link-local messages and to Also, in its HNCP profile it is limited to link-local messages and to
IPv6. However, at the minimum it is a very interesting test case for IPv6. However, at the minimum it is a very interesting test case for
this style of interaction between devices without needing a central this style of interaction between devices without needing a central
authority, and it is a proven method of network-wide state authority, and it is a proven method of network-wide state
synchronization by flooding. synchronization by flooding.
The Server Cache Synchronization Protocol (SCSP) [RFC2334] also
describes a method for cache synchronization and cache replication
among a group of nodes.
A proposal was made some years ago for an IP based Generic Control A proposal was made some years ago for an IP based Generic Control
Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at
information exchange and negotiation but not directly at peer information exchange and negotiation but not directly at peer
discovery. However, it has many points in common with the present discovery. However, it has many points in common with the present
work. work.
None of the above solutions appears to completely meet the needs of None of the above solutions appears to completely meet the needs of
generic discovery, state synchronization and negotiation in a single generic discovery, state synchronization and negotiation in a single
solution. Many of the protocols assume that they are working in a solution. Many of the protocols assume that they are working in a
traditional top-down or north-south scenario, rather than a fluid traditional top-down or north-south scenario, rather than a fluid
 End of changes. 103 change blocks. 
231 lines changed or deleted 379 lines changed or added

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