draft-ietf-anima-grasp-05.txt   draft-ietf-anima-grasp-06.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: November 14, 2016 Univ. of Auckland Expires: December 29, 2016 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
May 13, 2016 June 27, 2016
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-05 draft-ietf-anima-grasp-06
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 November 14, 2016. This Internet-Draft will expire on December 29, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 9 2.3. Specific Technical Requirements . . . . . . . . . . . . . 8
3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 12 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . 17 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16
3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 19 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 20
3.3.5. Synchronization and Flooding Procedure . . . . . . . 21 3.3.5. Synchronization and Flooding Procedure . . . . . . . 21
3.4. High Level Deployment Model . . . . . . . . . . . . . . . 22 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 23
3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 24
3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 23 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 24
3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 24 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 25
3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 24 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 25
3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 24 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 25
3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 25 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 26
3.7.4. Discovery Response Message . . . . . . . . . . . . . 26 3.7.4. Discovery Response Message . . . . . . . . . . . . . 27
3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 27 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 27
3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 27 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 28
3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 28 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 28
3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 28 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 29
3.7.9. Synchronization Message . . . . . . . . . . . . . . . 28 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 29
3.7.10. Flood Synchronization Message . . . . . . . . . . . . 29 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 29
3.7.11. No Operation Message . . . . . . . . . . . . . . . . 29 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 30
3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 29 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 30
3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 29 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 30
3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 30 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 30
3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 30 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 31
3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 30 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 31
3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 31 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 31
3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 33 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 33
3.9.1. Format of Objective Options . . . . . . . . . . . . . 33 3.9.1. Format of Objective Options . . . . . . . . . . . . . 33
3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 34 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 34
3.9.3. General Considerations for Objective Options . . . . 34 3.9.3. General Considerations for Objective Options . . . . 35
3.9.4. Organizing of Objective Options . . . . . . . . . . . 35 3.9.4. Organizing of Objective Options . . . . . . . . . . . 35
3.9.5. Experimental and Example Objective Options . . . . . 36 3.9.5. Experimental and Example Objective Options . . . . . 37
4. Implementation Status [RFC Editor: please remove] . . . . . . 36 4. Implementation Status [RFC Editor: please remove] . . . . . . 37
4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 36 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 37
4.2. Python Implementation . . . . . . . . . . . . . . . . . . 37 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38
6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 40 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 40
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . 45 9.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 48 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 49
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 55 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 55
Appendix D. Capability Analysis of Current Protocols . . . . . . 58 Appendix D. Capability Analysis of Current Protocols . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
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.ietf-anima-reference-model]. In order to fulfil autonomy, [I-D.ietf-anima-reference-model]. The reader should consult this
devices that embody autonomic service agents have specific signaling document to understand how various autonomic components fit together.
requirements. In particular they need to discover each other, to In order to fulfil autonomy, devices that embody Autonomic Service
synchronize state with each other, and to negotiate parameters and Agents (ASAs, [RFC7575]) have specific signaling requirements. In
resources directly with each other. There is no restriction on the particular they need to discover each other, to synchronize state
type of parameters and resources concerned, which include very basic with each other, and to negotiate parameters and resources directly
information needed for addressing and routing, as well as anything with each other. There is no limitation on the types of parameters
else that might be configured in a conventional non-autonomic and resources concerned, which can include very basic information
network. The atomic unit of synchronization or negotiation is needed for addressing and routing, as well as anything else that
referred to as a technical objective, i.e, a configurable parameter might be configured in a conventional non-autonomic network. The
or set of parameters (defined more precisely in Section 3.1). atomic unit of discovery, synchronization or negotiation is referred
to as a technical objective, i.e, a configurable parameter or set of
parameters (defined more precisely in Section 3.1).
Following this Introduction, Section 2 describes the requirements for Following this Introduction, Section 2 describes the requirements for
discovery, synchronization and negotiation. Negotiation is an discovery, synchronization and negotiation. Negotiation is an
iterative process, requiring multiple message exchanges forming a iterative process, requiring multiple message exchanges forming a
closed loop between the negotiating devices. State synchronization, closed loop between the negotiating entities. In fact, these
when needed, can be regarded as a special case of negotiation, entities are ASAs, normally but not necessarily in different network
without iteration. Section 3.2 describes a behavior model for a devices. State synchronization, when needed, can be regarded as a
protocol intended to support discovery, synchronization and special case of negotiation, without iteration. Section 3.2
negotiation. The design of GeneRic Autonomic Signaling Protocol describes a behavior model for a protocol intended to support
(GRASP) in Section 3 of this document is mainly based on this discovery, synchronization and negotiation. The design of GeneRic
behavior model. The relevant capabilities of various existing Autonomic Signaling Protocol (GRASP) in Section 3 of this document is
protocols are reviewed in Appendix D. mainly based on this behavior model. The relevant capabilities of
various existing protocols are reviewed in Appendix D.
The proposed discovery mechanism is oriented towards synchronization The proposed discovery mechanism is oriented towards synchronization
and negotiation objectives. It is based on a neighbor discovery and negotiation objectives. It is based on a neighbor discovery
process, but also supports diversion to off-link peers. Although process, but also supports diversion to off-link peers. There is no
many negotiations will occur between horizontally distributed peers, assumption of any particular form of network topology. When a device
many target scenarios are hierarchical networks, which is the starts up with no pre-configuration, it has no knowledge of the
predominant structure of current large-scale managed networks. topology. The protocol itself is capable of being used in a small
However, when a device starts up with no pre-configuration, it has no and/or flat network structure such as a small office or home network
knowledge of the topology. The protocol itself is capable of being as well as a professionally managed network. Therefore, the
used in a small and/or flat network structure such as a small office discovery mechanism needs to be able to allow a device to bootstrap
or home network as well as a professionally managed network. itself without making any prior assumptions about network structure.
Therefore, the discovery mechanism needs to be able to allow a device
to bootstrap itself without making any prior assumptions about
network structure.
Because GRASP can be used to perform a decision process among Because GRASP can be used to perform a decision process among
distributed devices or between networks, it must run in a secure and distributed devices or between networks, it must run in a secure and
strongly authenticated environment. strongly authenticated environment.
It is understood that in realistic deployments, not all devices will It is understood that in realistic deployments, not all devices will
support GRASP. It is expected that some autonomic service agents support GRASP. It is expected that some autonomic service agents
will directly manage a group of non-autonomic nodes, and that other will directly manage a group of non-autonomic nodes, and that other
non-autonomic nodes will be managed traditionally. Such mixed non-autonomic nodes will be managed traditionally. Such mixed
scenarios are not discussed in this specification. scenarios are not discussed in this specification.
2. Requirement Analysis of Discovery, Synchronization and Negotiation 2. Requirement Analysis of Discovery, Synchronization and Negotiation
This section discusses the requirements for discovery, negotiation This section discusses the requirements for discovery, negotiation
and synchronization capabilities. The primary user of the protocol and synchronization capabilities. The primary user of the protocol
is an autonomic service agent (ASA), so the requirements are mainly is an autonomic service agent (ASA), so the requirements are mainly
expressed as the features needed by an ASA. A single physical device expressed as the features needed by an ASA. A single physical device
might contain several ASAs, and a single ASA might manage several might contain several ASAs, and a single ASA might manage several
technical objectives. technical objectives. If a technical objective is managed by several
ASAs, any necessary coordination is outside the scope of the
signaling protocol itself.
Note that requirements for ASAs themselves, such as the processing of Note that requirements for ASAs themselves, such as the processing of
Intent [RFC7575] or interfaces for coordination between ASAs are out Intent [RFC7575] or interfaces for coordination between ASAs are out
of scope for the present document. of scope for the present document.
2.1. Requirements for Discovery 2.1. Requirements for Discovery
D1. ASAs may be designed to manage anything, as required in D1. ASAs may be designed to manage anything, as required in
Section 2.2. A basic requirement is therefore that the protocol can Section 2.2. A basic requirement is therefore that the protocol can
represent and discover any kind of technical objective among represent and discover any kind of technical objective among
arbitrary subsets of participating nodes. arbitrary subsets of participating nodes.
In an autonomic network we must assume that when a device starts up In an autonomic network we must assume that when a device starts up
it has no information about any peer devices, the network structure, it has no information about any peer devices, the network structure,
or what specific role it must play. The ASA(s) inside the device are or what specific role it must play. The ASA(s) inside the device are
in the same situation. In some cases, when a new application session in the same situation. In some cases, when a new application session
starts up within a device, the device or ASA may again lack starts up within a device, the device or ASA may again lack
information about relevant peers. It might be necessary to set up information about relevant peers. For example, it might be necessary
resources on multiple other devices, coordinated and matched to each to set up resources on multiple other devices, coordinated and
other so that there is no wasted resource. Security settings might matched to each other so that there is no wasted resource. Security
also need updating to allow for the new device or user. The relevant settings might also need updating to allow for the new device or
peers may be different for different technical objectives. Therefore user. The relevant peers may be different for different technical
discovery needs to be repeated as often as necessary to find peers objectives. Therefore discovery needs to be repeated as often as
capable of acting as counterparts for each objective that a discovery necessary to find peers capable of acting as counterparts for each
initiator needs to handle. From this background we derive the next objective that a discovery initiator needs to handle. From this
three requirements: background we derive the next three requirements:
D2. When an ASA first starts up, it has no knowledge of the specific D2. When an ASA first starts up, it has no knowledge of the specific
network to which it is attached. Therefore the discovery process network to which it is attached. Therefore the discovery process
must be able to support any network scenario, assuming only that the must be able to support any network scenario, assuming only that the
device concerned is bootstrapped from factory condition. device concerned is bootstrapped from factory condition.
D3. When an ASA starts up, it must require no information about any D3. When an ASA starts up, it must require no configured location
peers in order to discover them. information about any peers in order to discover them.
D4. If an ASA supports multiple technical objectives, relevant peers D4. If an ASA supports multiple technical objectives, relevant peers
may be different for different discovery objectives, so discovery may be different for different discovery objectives, so discovery
needs to be repeated to find counterparts for each objective. Thus, needs to be performed separately to find counterparts for each
there must be a mechanism by which an ASA can separately discover objective. Thus, there must be a mechanism by which an ASA can
peer ASAs for each of the technical objectives that it needs to separately discover peer ASAs for each of the technical objectives
manage, whenever necessary. that it needs to manage, whenever necessary.
D5. Following discovery, an ASA will normally perform negotiation or D5. Following discovery, an ASA will normally perform negotiation or
synchronization for the corresponding objectives. The design should synchronization for the corresponding objectives. The design should
allow for this by associating discovery, negotiation and allow for this by conveniently linking discovery to negotiation and
synchronization objectives. It may provide an optional mechanism to synchronization. It may provide an optional mechanism to combine
combine discovery and negotiation/synchronization in a single call. discovery and negotiation/synchronization in a single call.
D6. Some objectives may only be significant on the local link, but D6. Some objectives may only be significant on the local link, but
others may be significant across the routed network and require off- others may be significant across the routed network and require off-
link operations. Thus, the relevant peers might be immediate link operations. Thus, the relevant peers might be immediate
neighbors on the same layer 2 link, or they might be more distant and neighbors on the same layer 2 link, or they might be more distant and
only accessible via layer 3. The mechanism must therefore provide only accessible via layer 3. The mechanism must therefore provide
both on-link and off-link discovery of ASAs supporting specific both on-link and off-link discovery of ASAs supporting specific
technical objectives. technical objectives.
D7. The discovery process should be flexible enough to allow for D7. The discovery process should be flexible enough to allow for
special cases, such as the following: special cases, such as the following:
o In some networks, as mentioned above, there will be some
hierarchical structure, at least for certain synchronization or
negotiation objectives, but this is unknown in advance. The
discovery protocol must therefore operate regardless of
hierarchical structure, which is an attribute of individual
technical objectives and not of the autonomic network as a whole.
This is part of the more general requirement to discover off-link
peers.
o During initialisation, a device must be able to establish mutual o During initialisation, a device must be able to establish mutual
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
skipping to change at page 7, line 19 skipping to change at page 7, line 10
information and traffic metrics need to be shared between nodes for information and traffic metrics need to be shared between nodes for
dynamic adjustment of resources and for monitoring purposes. While dynamic adjustment of resources and for monitoring purposes. While
this might be achieved by existing protocols when they are available, this might be achieved by existing protocols when they are available,
the new protocol needs to be able to support parameter exchange, the new protocol needs to be able to support parameter exchange,
including mutual synchronization, even when no negotiation as such is including mutual synchronization, even when no negotiation as such is
required. In general, these parameters do not apply to all required. In general, these parameters do not apply to all
participating nodes, but only to a subset. participating nodes, but only to a subset.
SN1. A basic requirement for the protocol is therefore the ability SN1. A basic requirement for the protocol is therefore the ability
to represent, discover, synchronize and negotiate almost any kind of to represent, discover, synchronize and negotiate almost any kind of
network parameter among arbitrary subsets of participating nodes. network parameter among selected subsets of participating nodes.
SN2. Negotiation is a request/response process that must be SN2. Negotiation is a request/response process that must be
guaranteed to terminate (with success or failure) and if necessary it guaranteed to terminate (with success or failure) and if necessary it
must contain tie-breaking rules for each technical objective that must contain tie-breaking rules for each technical objective that
requires them. While these must be defined specifically for each use requires them. While these must be defined specifically for each use
case, the protocol should have some general mechanisms in support of case, the protocol should have some general mechanisms in support of
loop and deadlock prevention, such as hop count limits or timeouts. loop and deadlock prevention, such as hop count limits or timeouts.
SN3. Synchronization might concern small groups of nodes or very SN3. Synchronization might concern small groups of nodes or very
large groups. Different solutions might be needed at different large groups. Different solutions might be needed at different
scales. scales.
SN4. To avoid "reinventing the wheel", the protocol should be able SN4. To avoid "reinventing the wheel", the protocol should be able
to carry the message formats used by existing configuration protocols to encapsulate the data formats used by existing configuration
(such as NETCONF/YANG) in cases where that is convenient. protocols (such as NETCONF/YANG) in cases where that is convenient.
SN5. Human intervention in complex situations is costly and error- SN5. Human intervention in complex situations is costly and error-
prone. Therefore, synchronization or negotiation of parameters prone. Therefore, synchronization or negotiation of parameters
without human intervention is desirable whenever the coordination of without human intervention is desirable whenever the coordination of
multiple devices can improve overall network performance. It multiple devices can improve overall network performance. It
therefore follows that the protocol, as part of the Autonomic therefore follows that the protocol, as part of the Autonomic
Networking Infrastructure, must be capable of running in any device Networking Infrastructure, should be capable of running in any device
that would otherwise need human intervention. that would otherwise need human intervention. The issue of running
in constrained nodes is discussed in
[I-D.ietf-anima-reference-model].
SN6. Human intervention in large networks is often replaced by use SN6. Human intervention in large networks is often replaced by use
of a top-down network management system (NMS). It therefore follows of a top-down network management system (NMS). It therefore follows
that the protocol, as part of the Autonomic Networking that the protocol, as part of the Autonomic Networking
Infrastructure, must be capable of running in any device that would Infrastructure, should be capable of running in any device that would
otherwise be managed by an NMS, and that it can co-exist with an NMS, otherwise be managed by an NMS, and that it can co-exist with an NMS,
and with protocols such as SNMP and NETCONF. and with protocols such as SNMP and NETCONF.
SN7. Some features are expected to be implemented by individual SN7. Some features are expected to be implemented by individual
ASAs, but the protocol must be general enough to allow them: ASAs, but the protocol must be general enough to allow them:
o Dependencies and conflicts: In order to decide a configuration on o Dependencies and conflicts: In order to decide a configuration on
a given device, the device may need information from neighbors. a given device, the device may need information from neighbors.
This can be established through the negotiation procedure, or This can be established through the negotiation procedure, or
through synchronization if that is sufficient. However, a given through synchronization if that is sufficient. However, a given
item in a neighbor may depend on other information from its own item in a neighbor may depend on other information from its own
neighbors, which may need another negotiation or synchronization neighbors, which may need another negotiation or synchronization
procedure to obtain or decide. Therefore, there are potential procedure to obtain or decide. Therefore, there are potential
dependencies and conflicts among negotiation or synchronization dependencies and conflicts among negotiation or synchronization
procedures. Resolving dependencies and conflicts is a matter for procedures. Resolving dependencies and conflicts is a matter for
the individual ASAs involved. To allow this, there need to be the individual ASAs involved. To allow this, there need to be
clear boundaries and convergence mechanisms for negotiations. clear boundaries and convergence mechanisms for negotiations.
Also some mechanisms are needed to avoid loop dependencies. In Also some mechanisms are needed to avoid loop dependencies. In
such a case, the protocol's role is limited to signaling between such a case, the protocol's role is limited to bilateral signaling
ASAs. between ASAs.
o Recovery from faults and identification of faulty devices should o Recovery from faults and identification of faulty devices should
be as automatic as possible. The protocol's role is limited to be as automatic as possible. The protocol's role is limited to
the ability to handle discovery, synchronization and negotiation the ability to handle discovery, synchronization and negotiation
at any time, in case an ASA detects an anomaly such as a at any time, in case an ASA detects an anomaly such as a
negotiation counterpart failing. negotiation counterpart failing.
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. One aspect of this is an ASA that relies on a
forecasting the effect of a change by a "dry run" mechanism before knowledge base to predict network behavior. This is out of scope
actually installing the change. This will be an application of for the signaling protocol. However, another aspect is
the protocol rather than a feature of the protocol itself. forecasting the effect of a change by a "dry run" negotiation
before actually installing the change. This will be an
application of 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.ietf-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 a flexible and easily extensible
describing its messages, or at least a flexible and easily extensible format for describing objectives. At a later stage it may be
message format. One design consideration is whether to adopt an desirable to adopt an explicit information model. One consideration
existing information model or to design a new one. is whether to adopt an 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. In excessive impact on run-time efficiency and footprint. In
particular, it should be possible for ASAs to be implemented particular, it should be possible for ASAs to be implemented
independently of each other as user space programs rather than as independently of each other as user space programs rather than as
kernel code. The classes of device in which the protocol might run kernel code. The classes of device in which the protocol might run
is discussed in [I-D.ietf-anima-reference-model]. is discussed in [I-D.ietf-anima-reference-model].
skipping to change at page 9, line 32 skipping to change at page 9, line 24
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.
T4. The protocol must be able to access off-link counterparts via T4. The protocol must be able to access off-link counterparts via
routable addresses, i.e., must not be restricted to link-local routable addresses, i.e., must not be restricted to link-local
operation. operation.
T5. It must also be possible for an external discovery mechanism to T5. It must also be possible for an external discovery mechanism to
be used, if appropriate for a given technical objective. In other be used, if appropriate for a given technical objective. In other
words, GRASP discovery must not be a prerequisite for GRASP words, GRASP discovery must not be a prerequisite for GRASP
negotiation or synchronization; the prerequisite is discovering a negotiation or synchronization.
peer's locator by any method.
T6. ASAs and the signaling protocol need to run asynchronously when T6. The protocol must be capable of supporting multiple simultaneous
wait states occur. operations, especially when wait states occur.
T7. Intent: There must be provision for general Intent rules to be T7. Intent: There must be provision for general Intent rules to be
applied by all devices in the network (e.g., security rules, prefix applied by all devices in the network (e.g., security rules, prefix
length, resource sharing rules). However, Intent distribution might length, resource sharing rules). However, Intent distribution might
not use the signaling protocol itself, but its design should not not use the signaling protocol itself, but its design should not
exclude such use. exclude such use.
T8. Management monitoring, alerts and intervention: Devices should T8. Management monitoring, alerts and intervention: Devices should
be able to report to a monitoring system. Some events must be able be able to report to a monitoring system. Some events must be able
to generate operator alerts and some provision for emergency to generate operator alerts and some provision for emergency
skipping to change at page 10, line 36 skipping to change at page 10, line 29
The following additional terms are used throughout this document: The following additional terms are used throughout this document:
o Autonomic Device: identical to Autonomic Node. o Autonomic Device: identical to Autonomic Node.
o Discovery: a process by which an ASA discovers peers according to o Discovery: a process by which an ASA discovers peers according to
a specific discovery objective. The discovery results may be a specific discovery objective. The discovery results may be
different according to the different discovery objectives. The different according to the different discovery objectives. The
discovered peers may later be used as negotiation counterparts or discovered peers may later be used as negotiation counterparts or
as sources of synchronization data. as sources of synchronization data.
o Negotiation: a process by which two (or more) ASAs interact o Negotiation: a process by which two ASAs interact iteratively to
iteratively to agree on parameter settings that best satisfy the agree on parameter settings that best satisfy the objectives of
objectives of one or more ASAs. both ASAs.
o State Synchronization: a process by which two (or more) ASAs o State Synchronization: a process by which ASAs interact to receive
interact to agree on the current state of parameter values stored the current state of parameter values stored in other ASAs. This
in each ASA. This is a special case of negotiation in which is a special case of negotiation in which information is sent but
information is sent but the ASAs do not request their peers to the ASAs do not request their peers to change parameter settings.
change parameter settings. All other definitions apply to both All other definitions apply to both negotiation and
negotiation and synchronization. synchronization.
o Technical Objective (usually abbreviated as Objective): A o Technical Objective (usually abbreviated as Objective): A
technical objective is a configurable parameter or set of technical objective is a configurable parameter or set of
parameters of some kind, which occurs in three contexts: parameters of some kind, which occurs in three contexts:
Discovery, Negotiation and Synchronization. In the protocol, an Discovery, Negotiation and Synchronization. In the protocol, an
objective is represented by an identifier and if relevant a value. objective is represented by an identifier and if relevant a value.
Normally, a given objective will occur during discovery and Normally, a given objective will not occur in negotiation and
negotiation, or during discovery and synchronization, but not in synchronization contexts simultaneously.
all three contexts.
* One ASA may support multiple independent objectives. * One ASA may support multiple independent objectives.
* The parameter described by a given objective is naturally based * The parameter described by a given objective is naturally based
on a specific service or function or action. It may in on a specific service or function or action. It may in
principle be anything that can be set to a specific logical, principle be anything that can be set to a specific logical,
numerical or string value, or a more complex data structure, by numerical or string value, or a more complex data structure, by
a network node. That node is generally expected to contain an a network node. That node is generally expected to contain an
ASA which may itself manage other nodes. ASA which may itself manage subsidiary non-autonomic nodes.
* Discovery Objective: if a node needs to synchronize or * Discovery Objective: if a node needs to synchronize or
negotiate a specific objective but does not know a peer that negotiate a specific objective but does not know a peer that
supports this objective, it starts a discovery process. The supports this objective, it starts a discovery process. The
objective is called a Discovery Objective during this process. objective is called a Discovery Objective during this process.
* Synchronization Objective: an objective whose specific * Synchronization Objective: an objective whose specific
technical content needs to be synchronized among two or more technical content needs to be synchronized among two or more
ASAs. ASAs.
skipping to change at page 12, line 13 skipping to change at page 12, line 4
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.ietf-anima-reference-model]. It will provide Infrastructure [I-D.ietf-anima-reference-model]. It will provide
services to ASAs via a suitable application programming interface, services to ASAs via a suitable application programming interface
which will reflect the protocol elements but will not necessarily (API), which will reflect the protocol elements but will not
be in one-to-one correspondence to them. It is expected that a necessarily be in one-to-one correspondence to them. This API is
single instance of GRASP will exist in an autonomic node, and that out of scope for the present document.
the protocol engine and each ASA will run as independent
asynchronous processes. o It is normally expected that a single instance of GRASP will exist
in an autonomic node, and that the protocol engine and each ASA
will run as independent 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. As a design choice, the
protocol itself is not provided with built-in security
functionality.
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
administrative domains, ASAs might also exchange limited administrative domains, ASAs might also exchange limited
information and negotiate some particular configurations based on information and negotiate some particular configurations based on
a limited conventional or contractual trust relationship. a limited conventional or contractual trust relationship.
o Discovery, synchronization and negotiation are designed together. o Discovery, synchronization and negotiation are designed together.
The discovery method and the synchronization and negotiation The discovery method and the synchronization and negotiation
skipping to change at page 13, line 48 skipping to change at page 13, line 42
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
Naturally, the technical content will be organized according to Naturally, the technical content will be organized according to
the relevant function or service. The content from different the relevant function or service. The content from different
functions or services is kept independent from each other. They functions or services is kept independent from each other. They
are not combined into a single option or single session because are not combined into a single option or single session because
these contents may be negotiated or synchronized with different these contents may be negotiated or synchronized with different
counterparts or may be different in response time. counterparts or may be different in response time. Thus a normal
arrangement would be a single ASA managing a small set of closely
o Self-aware network device related objectives, with a version of that ASA in each relevant
autonomic node. Further discussion of this aspect is out of scope
Every autonomic device will be pre-loaded with various functions for the current document.
and ASAs and will be aware of its own capabilities, typically
decided by the hardware, firmware or pre-installed software. Its
exact role may depend on Intent and on the surrounding network
behaviors, which may include forwarding behaviors, aggregation
properties, topology location, bandwidth, tunnel or translation
properties, etc. The surrounding topology will depend on the
network planning. Following an initial discovery phase, the
device properties and those of its neighbors are the foundation of
the synchronization or negotiation behavior of a specific device.
A device has no pre-configuration for the particular network in
which it is installed.
o Requests and responses in negotiation procedures o Requests and responses in negotiation procedures
The initiator can negotiate with its relevant negotiation The initiator can negotiate with its relevant negotiation
counterpart ASAs, which may be different according to the specific counterpart ASAs, which may be different according to the specific
negotiation objective. It can request relevant information from negotiation objective. It can request relevant information from
the negotiation counterpart so that it can decide its local the negotiation counterpart so that it can decide its local
configuration to give the most coordinated performance. It can configuration to give the most coordinated performance. It can
request the negotiation counterpart to make a matching request the negotiation counterpart to make a matching
configuration in order to set up a successful communication with configuration in order to set up a successful communication with
it. It can request certain simulation or forecast results by it. It can request certain simulation or forecast results by
sending some dry run conditions. sending some dry run conditions.
Beyond the traditional yes/no answer, the responder can reply with Beyond the traditional yes/no answer, the responder can reply with
a suggested alternative if its answer is 'no'. This would start a a suggested alternative value for the objective concerned. This
bi-directional negotiation ending in a compromise between the two would start a bi-directional negotiation ending in a compromise
ASAs. between the two ASAs.
o Convergence of negotiation procedures o Convergence of negotiation procedures
To enable convergence, when a responder makes a suggestion of a To enable convergence, when a responder makes a suggestion of a
changed condition in a negative reply, it should be as close as changed condition in a negative reply, it should be as close as
possible to the original request or previous suggestion. The possible to the original request or previous suggestion. The
suggested value of the third or later negotiation steps should be suggested value of the third or later negotiation steps should be
chosen between the suggested values from the last two negotiation chosen between the suggested values from the last two negotiation
steps. In any case there must be a mechanism to guarantee steps. In any case there must be a mechanism to guarantee
convergence (or failure) in a small number of steps, such as a convergence (or failure) in a small number of steps, such as a
skipping to change at page 17, line 24 skipping to change at page 17, line 13
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.
The initiator of a discovery action for a given objective need The initiator of a discovery action for a given objective need
not be capable of supporting that objective for negotiation or not be capable of responding to that objective as a Negotiation
as a source for synchronization or flooding. In other words an Counterpart, as a Synchronization Responder or as source for
ASA might perform discovery because it only wishes to receive flooding. For example, an ASA might perform discovery even if
synchronization data. it only wishes to act a Synchronization Initiator or
Negotiation Initiator. Such an ASA does not itself need to
respond to discovery messages.
It is entirely possible to use GRASP discovery without any It is also 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 GRASP always listens to a well-known UDP port to that supports GRASP always listens to a well-known UDP port to
capture the discovery messages. Because this port is unique in capture the discovery messages. Because this port is unique in
a device, this is a function of the GRASP kernel and not of an 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 individual ASA. As a result, each ASA will need to register
the objectives that it supports with the GRASP kernel. the objectives that it supports with the GRASP kernel.
If an ASA in a neighbor device supports the requested discovery If an ASA in a neighbor device supports the requested discovery
objective, the device MAY respond to the link-local multicast objective, the device SHOULD respond to the link-local
with a unicast Discovery Response message (Section 3.7.4) with multicast with a unicast Discovery Response message
locator option(s). Otherwise, if the neighbor has cached (Section 3.7.4) with locator option(s), unless it is
temporarily unavailable. 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 a device has no information about the requested discovery
objective, and is not acting as a discovery relay (see below)
it MUST silently discard the Discovery message.
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),
the Discovery message MAY be repeated, with a newly generated the Discovery message MAY be repeated, with a newly generated
Session ID (Section 3.6). An exponential backoff SHOULD be Session ID (Section 3.6). An exponential backoff SHOULD be
used for subsequent repetitions, in order to mitigate possible used for subsequent repetitions, in order to mitigate possible
denial of service attacks. denial of service attacks.
After a GRASP device successfully discovers a Discovery After a GRASP device successfully discovers a locator for a
Responder supporting a specific objective, it MUST cache this Discovery Responder supporting a specific objective, it MUST
information. This cache record MAY be used for future cache this information, including the interface identifier via
negotiation or synchronization, and SHOULD be passed on when which it was discovered. This cache record MAY be used for
appropriate as a Divert option to another Discovery Initiator. future negotiation or synchronization, and the locator SHOULD
The cache lifetime is an implementation choice that MAY be be passed on when appropriate as a Divert option to another
modified by network Intent. Discovery Initiator.
The cache mechanism MUST include a lifetime for each entry.
The lifetime is an implementation choice that MAY be modified
by network Intent. In some environments, unplanned address
renumbering might occur. In such cases, the cache lifetime
SHOULD be short compared to the typical address lifetime and a
mechanism to flush the discovery cache SHOULD be implemented.
The discovery mechanism needs to track the node's current
address to ensure that Discovery Responses always indicate the
correct address.
If multiple Discovery Responders are found for the same If multiple Discovery Responders are found for the same
objective, they SHOULD all be cached, unless this creates a objective, they SHOULD all be cached, unless this creates a
resource shortage. The method of choosing between multiple resource shortage. The method of choosing between multiple
responders is an implementation choice. This choice MUST be responders is an implementation choice. This choice MUST be
available to each ASA but the GRASP implementation SHOULD available to each ASA but the GRASP implementation SHOULD
provide a default choice. provide a default choice.
Because Discovery Responders will be cached in a finite cache, Because Discovery Responders will be cached in a finite cache,
they might be deleted at any time. In this case, discovery they might be deleted at any time. In this case, discovery
skipping to change at page 21, line 6 skipping to change at page 21, line 16
A Discovery message MAY include a Negotiation Objective option. In A Discovery message MAY include a Negotiation Objective option. In
this case the Discovery message also acts as a Request Negotiation this case the Discovery message also acts as a Request Negotiation
message to indicate to the Discovery Responder that it could directly message to indicate to the Discovery Responder that it could directly
reply to the Discovery Initiator with a Negotiation message for rapid reply to the Discovery Initiator with a Negotiation message for rapid
processing, if it could act as the corresponding negotiation processing, if it could act as the corresponding negotiation
counterpart. However, the indication is only advisory not counterpart. However, the indication is only advisory not
prescriptive. prescriptive.
This rapid mode could reduce the interactions between nodes so that a This rapid mode could reduce the interactions between nodes so that a
higher efficiency could be achieved. This rapid negotiation function higher efficiency could be achieved. However, a network in which
SHOULD be configured off by default and MAY be configured on or off some nodes support rapid mode and others do not will have complex
by Intent. timing-dependent behaviors. Therefore, the rapid negotiation
function SHOULD be configured off by default and MAY be configured on
or off by Intent.
3.3.5. Synchronization and Flooding Procedure 3.3.5. Synchronization and Flooding Procedure
A synchronization initiator sends a synchronization request to a A synchronization initiator sends a synchronization request to a
counterpart, including a specific synchronization objective. The counterpart, including a specific synchronization objective. The
counterpart responds with a Synchronization message (Section 3.7.9) counterpart responds with a Synchronization message (Section 3.7.9)
containing the current value of the requested synchronization containing the current value of the requested synchronization
objective. No further messages are needed. objective. No further messages are needed.
If no reply message of any kind is received within a reasonable If no reply message of any kind is received within a reasonable
skipping to change at page 22, line 26 skipping to change at page 22, line 38
ID and initiator address more than once. These precautions avoid ID and initiator address more than once. These precautions avoid
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 or equivalent strong security in place.
weakness of link-local multicast (Section 5), synchronization However, because of the security weakness of link-local multicast
objectives that are flooded SHOULD NOT contain unencrypted sensitive (Section 5), synchronization objectives that are flooded SHOULD NOT
information and SHOULD be validated by the recipient ASA. contain unencrypted private 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
rapid processing, if the discovery target supports the corresponding rapid processing, if the discovery target supports the corresponding
synchronization objective. However, the indication is only advisory synchronization objective. However, the indication is only advisory
not prescriptive. not prescriptive.
This rapid mode could reduce the interactions between nodes so that a This rapid mode could reduce the interactions between nodes so that a
higher efficiency could be achieved. This rapid synchronization higher efficiency could be achieved. However, a network in which
some nodes support rapid mode and others do not will have complex
timing-dependent behaviors. Therefore, the rapid synchronization
function SHOULD be configured off by default and MAY be configured on function SHOULD be configured off by default and MAY be configured on
or off by Intent. or off by Intent.
3.4. High Level Deployment Model 3.4. High Level Deployment Model
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 and simultaneous operations. It is
GRASP will access the ACP by using a typical socket interface. A expected that GRASP will access the ACP by using a typical socket
well defined Application Programming Interface (API) will be needed interface. A well defined Application Programming Interface (API)
between GRASP and the ASAs. In some implementations, ASAs would run will be needed between GRASP and the ASAs. In some implementations,
in user space with a GRASP library providing the API, and this ASAs would run in user space with a GRASP library providing the API,
library would in turn communicate via system calls with core GRASP and this library would in turn communicate via system calls with core
functions running in kernel mode. For further details of possible GRASP functions running in kernel mode. For further details of
deployment models, see [I-D.ietf-anima-reference-model]. possible deployment models, see [I-D.ietf-anima-reference-model].
Because GRASP needs to work whatever happens, especially during
bootstrapping and during fault conditions, it is essential that every
implementation is as robust as possible. For example, discovery
failures, or any kind of socket error at any time, must not cause
irrecoverable failures in GRASP itself, and must return suitable
error codes through the API so that ASAs can also recover.
GRASP must always start up correctly after a system restart. All run
time error conditions, and events such as address renumbering,
network interface failures, and CPU sleep/wake cycles, must be
handled in such a way that GRASP will still operate correctly and
securely (Section 3.3.1) afterwards.
An autonomic node will normally run a single instance of GRASP, used
by multiple ASAs. However, scenarios where multiple instances of
GRASP run in a single node, perhaps with different security
properties, are not excluded. In this case, each instance MUST
listen independently for GRASP link-local muticasts in order for
discovery and flooding to work correctly.
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 26, line 9 skipping to change at page 26, line 42
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:
o a discovery objective option (Section 3.9.1). Its loop count MUST o a discovery objective option (Section 3.9.1). Its loop count MUST
be set to a suitable value to prevent discovery loops (default be set to a suitable value to prevent discovery loops (default
value is GRASP_DEF_LOOPCT). value is GRASP_DEF_LOOPCT). If the discovery initiator requires
only on-link responses, the loop count MUST be set to 1.
o a negotiation objective option (Section 3.9.1). This is used both o a negotiation objective option (Section 3.9.1). This is used both
for the purpose of discovery and to indicate to the discovery for the purpose of discovery and to indicate to the discovery
target that it MAY directly reply to the discovery initiatior with target that it MAY directly reply to the discovery initiatior with
a Negotiation message for rapid processing, if it could act as the a Negotiation message for rapid processing, if it could act as the
corresponding negotiation counterpart. The sender of such a corresponding negotiation counterpart. The sender of such a
Discovery message MUST initialize a negotiation timer and loop Discovery message MUST initialize a negotiation timer and loop
count in the same way as a Request Negotiation message count in the same way as a Request Negotiation message
(Section 3.7.5). (Section 3.7.5).
skipping to change at page 30, line 18 skipping to change at page 30, line 50
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
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
encapsulated in Discovery Response messages. If found elsewhere, it encapsulated in Discovery Response messages. If found elsewhere, it
SHOULD be silently ignored. SHOULD be silently ignored.
A discovery initiator MAY ignore a Divert option if it only requires
direct discovery responses.
In fragmentary CDDL, the Divert option follows the pattern: In fragmentary CDDL, the Divert option follows the pattern:
divert-option = [O_DIVERT, +locator-option] divert-option = [O_DIVERT, +locator-option]
The embedded Locator Option(s) (Section 3.8.5) point to diverted The embedded Locator Option(s) (Section 3.8.5) point to diverted
destination target(s) in response to a Discovery message. destination target(s) in response to a Discovery message.
3.8.3. Accept Option 3.8.3. Accept Option
The accept option is used to indicate to the negotiation counterpart The accept option is used to indicate to the negotiation counterpart
skipping to change at page 45, line 32 skipping to change at page 46, line 7
control-plane-02 (work in progress), March 2016. 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-02 (work in progress), ietf-anima-bootstrapping-keyinfra-02 (work in progress),
March 2016. March 2016.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model Liu, B., Nobre, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-ietf-anima-reference- for Autonomic Networking", draft-ietf-anima-reference-
model-01 (work in progress), March 2016. model-01 (work in progress), March 2016.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-00 (work in progress), January anima-stable-connectivity-00 (work in progress), January
2016. 2016.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
skipping to change at page 48, line 37 skipping to change at page 49, line 8
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.
o 48. Should the Appendix "Capability Analysis of Current o 48. Should the Appendix "Capability Analysis of Current
Protocols" be deleted before RFC publication? Protocols" be deleted before RFC publication?
o 49. Section 3.3.1 should say more about signaling between two
autonomic networks/domains.
o 50. Is Rapid mode limited to on-link only? What happens if first
discovery responder does not support Rapid Mode? (Section 3.3.4,
Section 3.3.5)
Appendix B. Closed Issues [RFC Editor: Please remove] Appendix B. Closed Issues [RFC Editor: Please remove]
o 1. UDP vs TCP: For now, this specification suggests UDP and TCP o 1. UDP vs TCP: For now, this specification suggests UDP and TCP
as message transport mechanisms. This is not clarified yet. UDP as message transport mechanisms. This is not clarified yet. UDP
is good for short conversations, is necessary for multicast is good for short conversations, is necessary for multicast
discovery, and generally fits the discovery and divert scenarios discovery, and generally fits the discovery and divert scenarios
well. However, it will cause problems with large messages. TCP well. However, it will cause problems with large messages. TCP
is good for stable and long sessions, with a little bit of time is good for stable and long sessions, with a little bit of time
consumption during the session establishment stage. If messages consumption during the session establishment stage. If messages
exceed a reasonable MTU, a TCP mode will be required in any case. exceed a reasonable MTU, a TCP mode will be required in any case.
skipping to change at page 55, line 7 skipping to change at page 55, line 34
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-06, 2016-06-27:
Added text on discovery cache timeouts.
Noted that ASAs that are only initiators do not need to respond to
discovery message.
Added text on unexpected address changes.
Added text on robust implementation.
Clarifications and editorial fixes for numerous review comments
Added open issues for some review comments.
draft-ietf-anima-grasp-05, 2016-05-13: draft-ietf-anima-grasp-05, 2016-05-13:
Noted in requirement T1 that it should be possible to implement ASAs Noted in requirement T1 that it should be possible to implement ASAs
independently as user space programs. independently as user space programs.
Protocol change: Added protocol number and port to discovery Protocol change: Added protocol number and port to discovery
response. Updated protocol description, CDDL and IANA considerations response. Updated protocol description, CDDL and IANA considerations
accordingly. accordingly.
Clarified that discovery and flood multicasts are handled by the Clarified that discovery and flood multicasts are handled by the
 End of changes. 58 change blocks. 
184 lines changed or deleted 241 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/