draft-ietf-anima-grasp-03.txt   draft-ietf-anima-grasp-04.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: August 27, 2016 Univ. of Auckland Expires: September 12, 2016 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
February 24, 2016 March 11, 2016
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-03 draft-ietf-anima-grasp-04
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 August 27, 2016. This Internet-Draft will expire on September 12, 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 29 skipping to change at page 2, line 29
2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . 16 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16
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 . . . . . . . 20
3.4. High Level Deployment Model . . . . . . . . . . . . . . . 21 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 22
3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22
3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 22 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 23
3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23
3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 23 3.7.1. Message Overview . . . . . . . . . . . . . . . . . . 23
3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 23 3.7.2. GRASP Message Format . . . . . . . . . . . . . . . . 24
3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 24 3.7.3. Discovery Message . . . . . . . . . . . . . . . . . . 24
3.7.4. Discovery Response Message . . . . . . . . . . . . . 25 3.7.4. Discovery Response Message . . . . . . . . . . . . . 25
3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 25 3.7.5. Request Messages . . . . . . . . . . . . . . . . . . 26
3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 26 3.7.6. Negotiation Message . . . . . . . . . . . . . . . . . 27
3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 26 3.7.7. Negotiation End Message . . . . . . . . . . . . . . . 27
3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 27 3.7.8. Confirm Waiting Message . . . . . . . . . . . . . 27
3.7.9. Synchronization Message . . . . . . . . . . . . . . . 27 3.7.9. Synchronization Message . . . . . . . . . . . . . . . 28
3.7.10. Flood Synchronization Message . . . . . . . . . . . . 27 3.7.10. Flood Synchronization Message . . . . . . . . . . . . 28
3.7.11. No Operation Message . . . . . . . . . . . . . . . . 28 3.7.11. No Operation Message . . . . . . . . . . . . . . . . 28
3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 28 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 29
3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 28 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 29
3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 28 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 29
3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 29 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 29
3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 29 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 30
3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 29 3.8.5. Locator Options . . . . . . . . . . . . . . . . . . . 30
3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 31 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 31
3.9.1. Format of Objective Options . . . . . . . . . . . . . 31 3.9.1. Format of Objective Options . . . . . . . . . . . . . 32
3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 32 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 33
3.9.3. General Considerations for Objective Options . . . . 32 3.9.3. General Considerations for Objective Options . . . . 33
3.9.4. Organizing of Objective Options . . . . . . . . . . . 33 3.9.4. Organizing of Objective Options . . . . . . . . . . . 34
3.9.5. Experimental and Example Objective Options . . . . . 34 3.9.5. Experimental and Example Objective Options . . . . . 35
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 4. Security Considerations . . . . . . . . . . . . . . . . . . . 35
5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 36 5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . 40 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
8.2. Informative References . . . . . . . . . . . . . . . . . 41 8.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 44 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 45 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 45
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 51 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 52
Appendix D. Capability Analysis of Current Protocols . . . . . . 54 Appendix D. Capability Analysis of Current Protocols . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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].
skipping to change at page 17, line 21 skipping to change at page 17, line 21
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 multicast discovery initiator via UDP to the ALL_GRASP_NEIGHBOR link-
address (Section 3.5). Every network device that supports the local multicast address (Section 3.5). Every network device
GRASP always listens to a well-known UDP port to capture the that supports the GRASP always listens to a well-known UDP port
discovery messages. to capture the discovery messages.
If an ASA in the neighbor device supports the requested If an ASA in the neighbor device supports the requested
discovery objective, it MAY respond with a Discovery Response discovery objective, it MAY respond to the link-local multicast
message (Section 3.7.4) with locator option(s). Otherwise, if with a unicast Discovery Response message (Section 3.7.4) with
the neighbor has cached information about an ASA that supports locator option(s). Otherwise, if the neighbor has cached
the requested discovery objective (usually because it information about an ASA that supports the requested discovery
discovered the same objective before), it SHOULD respond with a objective (usually because it discovered the same objective
Discovery Response message with a Divert option pointing to the before), it SHOULD respond with a Discovery Response message
appropriate Discovery Responder. with a Divert option pointing to the appropriate Discovery
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),
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 Discovery
Responder supporting a specific objective, it MUST cache this Responder supporting a specific objective, it MUST cache this
skipping to change at page 18, line 20 skipping to change at page 18, line 21
will need to be repeated. If an ASA exits for any reason, its will need to be repeated. If an ASA exits for any reason, its
locator might still be cached for some time, and attempts to locator might still be cached for some time, and attempts to
connect to it will fail. ASAs need to be robust in these connect to it will fail. ASAs need to be robust in these
circumstances. circumstances.
A GRASP device with multiple link-layer interfaces (typically a A GRASP device with multiple link-layer interfaces (typically a
router) MUST support discovery on all interfaces. If it router) MUST support discovery on all interfaces. If it
receives a Discovery message on a given interface for a receives a Discovery message on a given interface for a
specific objective that it does not support and for which it specific objective that it does not support and for which it
has not previously cached a Discovery Responder, it MUST relay has not previously cached a Discovery Responder, it MUST relay
the query by re-issuing a Discovery message on its other the query by re-issuing a Discovery message as a link-local
interfaces. The relayed message MUST have a new Session ID. multicast on its other interfaces. The relayed discovery
Before this, it MUST decrement the loop count within the message MUST have the same Session ID as the incoming discovery
message and MUST be tagged with the IP address of its original
initiator. Since the relay device is unaware of the timeout
set by the original initiator it SHOULD set a timeout at least
equal to GRASP_DEF_TIMEOUT milliseconds.
The relaying device MUST decrement the loop count within the
objective, and MUST NOT relay the Discovery message if the objective, and MUST NOT relay the Discovery message if the
result is zero. Also, it MUST limit the total rate at which it result is zero. Also, it MUST limit the total rate at which it
relays discovery messages to a reasonable value, in order to relays discovery messages to a reasonable value, in order to
mitigate possible denial of service attacks. It MUST cache the mitigate possible denial of service attacks. It MUST cache the
Session ID value of each relayed discovery message and, to Session ID value and initiator address of each relayed
prevent loops, MUST NOT relay a Discovery message which carries Discovery message until any Discovery Responses have arrived or
such a cached Session ID. These precautions avoid discovery the discovery process has timed out. To prevent loops, it MUST
loops and mitigate potential overload. NOT relay a Discovery message which carries a given cached
Session ID and initiator address more than once. These
precautions avoid discovery loops and mitigate potential
overload.
The discovery results received by the relaying device MUST in
turn be sent as a Discovery Response message to the Discovery
message that caused the relay action.
This relayed discovery mechanism, with caching of the results, This relayed discovery mechanism, with caching of the results,
should be sufficient to support most network bootstrapping should be sufficient to support most network bootstrapping
scenarios. scenarios.
o A complete discovery process will start with a multicast on the o A complete discovery process will start with a multicast on the
local link. On-link neighbors supporting the discovery objective local link. On-link neighbors supporting the discovery objective
will respond directly. A neighbor with multiple interfaces will will respond directly. A neighbor with multiple interfaces will
respond with a cached discovery response if any. If not, it will respond with a cached discovery response if any. If not, it will
relay the discovery on its other interfaces, for example reaching relay the discovery on its other interfaces, for example reaching
skipping to change at page 21, line 9 skipping to change at page 21, line 23
suitable mechanism is needed to avoid excessive multicast traffic. suitable mechanism is needed to avoid excessive multicast traffic.
This mechanism MUST be defined as part of the specification of the This mechanism MUST be defined as part of the specification of the
synchronization objective(s) concerned. It might be a simple rate synchronization objective(s) concerned. It might be a simple rate
limit or a more complex mechanism such as the Trickle algorithm 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 a new message on its other interfaces. The relayed message MUST have the
Session ID. Before this, it MUST decrement the loop count within the same Session ID as the incoming message and MUST be tagged with the
IP address of its original initiator.
The relaying device MUST decrement the loop count within the first
objective, and MUST NOT relay the Flood Synchronization message if objective, and MUST NOT relay the Flood Synchronization message if
the result is zero. Also, it MUST limit the total rate at which it the result is zero. Also, it MUST limit the total rate at which it
relays Flood Synchronization messages to a reasonable value, in order relays Flood Synchronization messages to a reasonable value, in order
to mitigate possible denial of service attacks. It MUST cache the to mitigate possible denial of service attacks. It MUST cache the
Session ID value of each relayed Flood Synchronization message and, Session ID value and initiator address of each relayed Flood
to prevent loops, MUST NOT relay a Flood Synchronization message Synchronization message for a finite time not less than twice
which carries such a cached Session ID. These precautions avoid GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay
a Flood Synchronization message which carries a given cached Session
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. However, because of the security
skipping to change at page 23, line 14 skipping to change at page 23, line 35
The Session ID SHOULD have a very low collision rate locally. It The Session ID SHOULD have a very low collision rate locally. It
MUST be generated by a pseudo-random algorithm using a locally MUST be generated by a pseudo-random algorithm using a locally
generated seed which is unlikely to be used by any other device in generated seed which is unlikely to be used by any other device in
the same network [RFC4086]. the same network [RFC4086].
However, there is a finite probability that two nodes might generate However, there is a finite probability that two nodes might generate
the same Session ID value. For that reason, when a Session ID is the same Session ID value. For that reason, when a Session ID is
communicated via GRASP, the receiving node MUST tag it with the communicated via GRASP, the receiving node MUST tag it with the
initiator's IP address to allow disambiguation. Multicast GRASP initiator's IP address to allow disambiguation. Multicast GRASP
messages, which may be relayed between links, therefore require a new messages and their responses, which may be relayed between links,
Session ID each time they are relayed. therefore include a field that carries the initiator's global IP
address.
3.7. GRASP Messages 3.7. GRASP Messages
3.7.1. Message Overview 3.7.1. Message Overview
This section defines the GRASP message format and message types. This section defines the GRASP message format and message types.
Message types not listed here are reserved for future use. Message types not listed here are reserved for future use.
The messages currently defined are: The messages currently defined are:
skipping to change at page 24, line 7 skipping to change at page 24, line 29
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
message-structure = [MESSAGE_TYPE, session-id, +grasp-option] message-structure = [MESSAGE_TYPE, session-id, ?initiator,
*grasp-option]
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 5.
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 5.
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, 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 to the link-
local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores
the discovery results (including responding discovery objectives and the discovery results (including responding discovery objectives and
corresponding unicast addresses, FQDNs or URIs). corresponding unicast addresses, FQDNs or URIs).
The 'initiator' field in the message is a globally unique IP address
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
globally unique IP address, it MUST use a link-local address for this
purpose that is highly likely to be unique, for example using
[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).
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
skipping to change at page 25, line 18 skipping to change at page 25, line 48
a Synchronization message for rapid processing, if it could act as a Synchronization message for rapid processing, if it could act as
the corresponding synchronization counterpart. Its loop count the corresponding synchronization counterpart. Its loop count
MUST be set to a suitable value to prevent discovery loops MUST be set to a suitable value to prevent discovery loops
(default value is GRASP_DEF_LOOPCT). (default value is GRASP_DEF_LOOPCT).
3.7.4. Discovery Response Message 3.7.4. Discovery Response Message
In fragmentary CDDL, a Discovery Response message follows the In fragmentary CDDL, a Discovery Response message follows the
pattern: pattern:
response-message = [M_RESPONSE, session-id, 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
MAY include a copy of the discovery objective from the Discovery MUST contain the same Session ID and initiator as the Discovery
message. message. It MAY include a copy of the discovery objective from the
Discovery message.
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 27, line 44 skipping to change at page 28, line 27
message in Rapid Mode, sends back a unicast Synchronization message message in Rapid Mode, sends back a unicast Synchronization message
with the synchronization data, in the form of a GRASP Option for the with the synchronization data, in the form of a GRASP Option for the
specific synchronization objective present in the Request specific synchronization objective present in the Request
Synchronization. Synchronization.
3.7.10. Flood Synchronization Message 3.7.10. Flood Synchronization Message
In fragmentary CDDL, a Flood Synchronization message follows the In fragmentary CDDL, a Flood Synchronization message follows the
pattern: pattern:
flood-message = [M_FLOOD, session-id, +objective] flood-message = [M_FLOOD, session-id, initiator, +objective]
A node MAY initiate flooding by sending an unsolicited Flood A node MAY initiate flooding by sending an unsolicited Flood
Synchronization Message with synchronization data. This MAY be sent Synchronization Message with synchronization data. This MAY be sent
to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance
with the rules in Section 3.3.5. The synchronization data will be in with the rules in Section 3.3.5. The initiator address is provided
the form of GRASP Option(s) for specific synchronization as described for Discovery messages. The synchronization data will
be in the form of GRASP Option(s) for specific synchronization
objective(s). The loop count(s) MUST be set to a suitable value to objective(s). The loop count(s) MUST be set to a suitable value to
prevent flood loops (default value is GRASP_DEF_LOOPCT). prevent flood loops (default value is GRASP_DEF_LOOPCT).
A node that receives a Flood Synchronization message SHOULD cache the A node that receives a Flood Synchronization message SHOULD cache the
received objectives for use by local ASAs. received objectives for use by local ASAs.
3.7.11. No Operation Message 3.7.11. No Operation Message
In fragmentary CDDL, a No Operation message follows the pattern: In fragmentary CDDL, a No Operation message follows the pattern:
skipping to change at page 36, line 45 skipping to change at page 37, line 35
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 5. 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, *grasp-option] message-structure = [MESSAGE_TYPE, session-id, ?initiator,
*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, 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, 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 message /= flood-message
flood-message = [M_FLOOD, session-id, +objective] flood-message = [M_FLOOD, session-id, initiator, +objective]
message /= request-negotiation-message message /= request-negotiation-message
request-negotiation-message = [M_REQ_NEG, session-id, objective] request-negotiation-message = [M_REQ_NEG, session-id, objective]
message /= request-synchronization-message message /= request-synchronization-message
request-synchronization-message = [M_REQ_SYN, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective]
message /= negotiation-message message /= negotiation-message
negotiation-message = [M_NEGOTIATE, session-id, objective] negotiation-message = [M_NEGOTIATE, session-id, objective]
skipping to change at page 38, line 4 skipping to change at page 38, line 42
locator-option /= ipv4-locator-option locator-option /= ipv4-locator-option
ipv4-locator-option = bytes .size 4 ipv4-locator-option = bytes .size 4
; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] ; this is simpler than [O_IPv4_LOCATOR, bytes .size 4]
locator-option /= ipv6-locator-option locator-option /= ipv6-locator-option
ipv6-locator-option = bytes .size 16 ipv6-locator-option = bytes .size 16
locator-option /= fqdn-locator-option locator-option /= fqdn-locator-option
fqdn-locator-option = [O_FQDN_LOCATOR, text] fqdn-locator-option = [O_FQDN_LOCATOR, text]
locator-option /= uri-locator-option locator-option /= uri-locator-option
uri-locator-option = [O_URI_LOCATOR, text] uri-locator-option = [O_URI_LOCATOR, text]
initiator = ipv4-locator-option / ipv6-locator-option
objective-flags = uint .bits objective-flag objective-flags = uint .bits objective-flag
objective-flag = &( objective-flag = &(
F_DISC: 0 ; valid for discovery only F_DISC: 0 ; valid for discovery only
F_NEG: 1 ; valid for discovery and negotiation F_NEG: 1 ; valid for discovery and negotiation
F_SYNCH: 2) ; valid for discovery and synchronization F_SYNCH: 2) ; valid for discovery and synchronization
objective = [objective-name, objective-flags, loop-count, ?any] objective = [objective-name, objective-flags, loop-count, ?any]
objective-name = text ;see specification for uniqueness rules objective-name = text ;see specification for uniqueness rules
skipping to change at page 39, line 23 skipping to change at page 40, line 14
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_REQUEST = 3 M_REQ_NEG = 3
M_NEGOTIATE = 4 M_REQ_SYN = 4
M_END = 5 M_NEGOTIATE = 5
M_WAIT = 6 M_END = 6
M_WAIT = 7
M_SYNCH = 8
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_FQDN_LOCATOR = 103
O_URI_LOCATOR = 104 O_URI_LOCATOR = 104
O_DEVICE_ID = 105
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
skipping to change at page 51, line 20 skipping to change at page 52, line 15
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-04, 2016-03-11:
Protocol change: Restored initiator field in certain messages and
adjusted relaying rules to provide complete loop detection.
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
adjusted relaying requirement to simplify loop detection. Also adjusted relaying requirement to simplify loop detection. Also
clarified narrative explanation of discovery relaying. clarified narrative explanation of discovery relaying.
Protocol change: Split Request message into two (Request Negotiation Protocol change: Split Request message into two (Request Negotiation
and Request Synchronization) and updated other message names for and Request Synchronization) and updated other message names for
clarity. clarity.
 End of changes. 38 change blocks. 
82 lines changed or deleted 124 lines changed or added

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