< draft-liu-anima-grasp-distribution-10.txt   draft-liu-anima-grasp-distribution-11.txt >
ANIMA WG B. Liu ANIMA WG B. Liu
INTERNET-DRAFT S. Jiang INTERNET-DRAFT Huawei Technologies
Intended Status: Standard Track Huawei Technologies Intended Status: Standard Track X. Xiao
Expires: September 8, 2019 X. Xiao Expires: January 9, 2020 MRC, Huawei Technologies
S. Jiang
Huawei Technologies
A. Hecker A. Hecker
Z. Despotovic Z. Despotovic
MRC, Huawei Technologies MRC, Huawei Technologies
March 11, 2019 July 8, 2019
Information Distribution in Autonomic Networking Information Distribution in Autonomic Networking
draft-liu-anima-grasp-distribution-10 draft-liu-anima-grasp-distribution-11
Abstract Abstract
This document discusses the requirement of capability of information This document discusses the requirement to autonomic nodes supporting
distribution among autonomic nodes in autonomic networks. In general, information distribution based over GRASP in autonomic networks. In
information distribution can be categorized into two different modes: general, information distribution can be categorized into two
1) one autonomic node instantly sends information to other nodes in different modes: 1) one autonomic node instantly sends information to
the domain; 2) one autonomic node publishes some information and other nodes in the domain; 2) one autonomic node publishes some
asynchronously some other interested nodes request the published information and asynchronously some other interested nodes request
information. In the former case, information data will be generated the published information. In the former case, information data will
and consumed instantly. In the latter case, information data live be generated and consumed instantly. In the latter case, information
longer in the network. data live longer in the network.
These capabilities are basic and fundamental to an autonomous network These capabilities are basic and fundamental to an autonomous network
system (i.e. ANI [I-D.ietf-anima-reference-model]). This document system (i.e. ANI [I-D.ietf-anima-reference-model]). This document
clarifies possible use cases of information distribution in ANI and clarifies possible use cases of information distribution in ANI and
requirements to ANI so that rich information distribution can be requirements to ANI so that rich information distribution can be
natively supported. Possible options to realize the information natively supported. Extensions to autonomic nodes are proposed and
distribution function are also briefly discussed. detailed embodiments based on GRASP are discussed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 32
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements of Advanced Information Distribution . . . . . . . 4 3. Requirements of Advanced Information Distribution . . . . . . . 4
4. Information Distribution in ANI . . . . . . . . . . . . . . . . 5 4. Information Distribution in ANI . . . . . . . . . . . . . . . . 5
5. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Node Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Instant Information Distribution . . . . . . . . . . . . . . 6 5.1 Instant Information Distribution . . . . . . . . . . . . . . 6
5.1.1 Instant P2P and Flooding Communications . . . . . . . . 6
5.1.2 Instant Selective Flooding Communication . . . . . . . 6
5.2 Asynchronous Information Distribution . . . . . . . . . . . 7 5.2 Asynchronous Information Distribution . . . . . . . . . . . 7
5.2.1 Information Storage . . . . . . . . . . . . . . . . . . 7
5.2.2 Event Queue . . . . . . . . . . . . . . . . . . . . . . 9
5.2.3 Interface between IS and EQ Modules . . . . . . . . . 10
5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Specification (GRASP extension) . . . . . . . . . . . 11 6. Protocol Specification (GRASP extension) . . . . . . . . . . . 12
6.1 Un-solicited Synchronization Message (A new GRASP Message) 11 6.1 Un-solicited Synchronization Message (A new GRASP Message) 12
6.2 Selective Flooding Option . . . . . . . . . . . . . . . . 11 6.2 Selective Flooding Option . . . . . . . . . . . . . . . . 12
6.3 Subscription Objective Option . . . . . . . . . . . . . . 12 6.3 Subscription Objective Option . . . . . . . . . . . . . . 13
6.4 Un_Subscription Objective Option . . . . . . . . . . . . . 12 6.4 Un_Subscription Objective Option . . . . . . . . . . . . . 13
6.5 Publishing Objective Option . . . . . . . . . . . . . . . 13 6.5 Publishing Objective Option . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14
9.2 Informative References . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1 Introduction 1 Introduction
In an autonomic network, autonomic functions (AFs) running on In an autonomic network, autonomic functions (AFs) running on
autonomic nodes would exchange information constantly, both for autonomic nodes would exchange information constantly, both for
controlling/management signaling and data exchange. This document controlling/management signaling and data exchange. This document
discusses the information distribution capability of such exchanges discusses the information distribution capability of such exchanges
between AFs. between AFs.
According to the number of participants, information distribution can According to the number of participants, information distribution can
happen with the following scenarios: happen with the following scenarios:
1) Point-to-point (P2P) Communication: information are exchanged 1) Point-to-point (P2P) Communication: information are exchanged
between two communicating parties from one node to another node. between two communicating parties from one node to another node.
2) One-to-Many Communication: information exchanges involve an 2) One-to-Many Communication: information exchanges involve an
information source and multiple receivers. information source and multiple receivers.
The approaches of distributing information could be categorized into The approaches of distributing information could be categorized into
two basic models: two basic modes:
1) An instant communication: a sender connects and sends the 1) An instant communication: a sender connects and sends the
information data (e.g. control/management signaling, information data (e.g. control/management signaling,
synchronization data and so on) to the receiver(s) immediately. synchronization data and so on) to the receiver(s) immediately.
2) An asynchronous communication: a sender saves the information 2) An asynchronous communication: a sender saves the information
in the network, may or may not publish the information to the in the network, may or may not publish the information to the
other who is interested in the published information, to which a other who is interested in the published information, to which a
node asks to retrieve. node asks to retrieve.
The ANI should have provided a generic way to support these various The ANI should have provided a generic way to support these
scenarios, rather than assisted by other transport or routing information distribution scenarios among AFs, rather than AFs
protocols (HTTP, BGP/IGP as bearing protocols etc.). In fact, GRASP managing to use other transport or routing protocols (HTTP, BGP/IGP
already provides part of the capabilities. as bearing protocols etc.). In fact, GRASP already provides part of
the capabilities.
In this document, we first analyze requirements of information In this document, we first analyze requirements of information
distribution in autonomic networks (Section 3), and then introduce distribution in autonomic networks (Section 3), and then introduce
its relationship to the other modules in ANI (Section 4). After that, its relationship to the other modules in ANI (Section 4). After that,
the node behaviors and extensions to the existing GRASP are the node behaviors and extensions to the existing GRASP are
introduced in Section 5 and Section 6, respectively. introduced in Section 5 and Section 6, respectively.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Requirements of Advanced Information Distribution 3. Requirements of Advanced Information Distribution
If the information exchanged is just short and simple, this can be If the information exchanged is just short and simple, this can be
done instantly. In practice, however, this is not always the case. In done instantly. In practice, however, this is not always the case. In
the following cases, a mixture of instant and asynchronous the following cases, a mixture of instant and asynchronous
communication models is more appropriate. communication models is more appropriate.
skipping to change at page 5, line 19 skipping to change at page 5, line 17
information distribution module is required, and both instant and information distribution module is required, and both instant and
asynchronous communication models should be supported. asynchronous communication models should be supported.
4. Information Distribution in ANI 4. Information Distribution in ANI
This section describes how the information distribution module fits This section describes how the information distribution module fits
into the ANI including what extensions of GRASP are required [I- into the ANI including what extensions of GRASP are required [I-
D.ietf-anima-grasp]. D.ietf-anima-grasp].
+-------------------+ +-------------------+
| ASAs + | ASAs |
+-------------------+ +-------------------+
^ ^
| |
v v
+-------------------------Info-Dist. APIs-----------------------+ +------------------------Info-Dist. APIs-----------------------+
| +---------------+ +-------------------+ +---------------+ | | +--------------------+ +-------------+ +---------------+ |
| | Event Queue |-|-| Selective Flooding|-|-| Info. Storage | | | | Selective Flooding |-|-| Event Queue |-|-| Info. Storage | |
| +---------------+ +-------------------+ +---------------+ | | +--------------------+ +-------------+ +---------------+ |
+---------------------------------------------------------------+ +--------------------------------------------------------------+
^ ^
| |
v v
+-------------GRASP APIs----------------+ +-------------GRASP APIs----------------+
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
| | GRASP Base |-|-| Extension | | | | | GRASP Base |-|-| Extension | | |
| +---------------+ +---------------+ | | +---------------+ +---------------+ |
+---------------------------------------+ +---------------------------------------+
Figure 1. Information Distribution Module and GRASP Extension. Figure 1. Information Distribution Module and GRASP Extension.
As the Fig 1 shows, the information distribution module includes As the Fig 1 shows, the information distribution module includes
three sub-modules, all of which provides APIs for ASAs. Specific three sub-modules, all of which provides APIs for ASAs. Specific
behaviors of these modules is described in Section 5. In order to behaviors of these modules is described in Section 5. In order to
support the modules, the GRASP is also extended, which is described support the modules, the GRASP is also extended, which is described
in Section 6. in Section 6.
5. Node Behaviors 5. Node Behaviors
ANI is a distributed system, so the information distribution module In this section, we discuss how each autonomic node should behave in
must be implemented in a distributed way as well. This means that order to support the two modes of information distribution introduced
every node participate to contribute. In this section, we discuss how before. ANI is a distributed system, so the information distribution
each autonomic node should behave in order to realize the information module must be implemented in a distributed way as well, where every
distribution module. Node interactions and information data exchange node participates to contribute.
between network nodes are necessary in order to support the instant
and asynchronous information distribution, which will be introduced
in the follow sections, respectively.
5.1 Instant Information Distribution 5.1 Instant Information Distribution
In this case, sender(s) and receiver(s) are specified. Information In this case, sender(s) and receiver(s) are specified. Information
will be directly sent from the sender(s) to the receiver(s). This will be directly sent from the sender(s) to the receiver(s). This
requires that every node is equipped by some signaling/transport requires that every node is equipped by some signaling/transport
protocols so that they can coordinate with each other and correctly protocols so that they can coordinate with each other and correctly
deliver the information. deliver the information.
5.1.1 Instant P2P and Flooding Communications 5.1.1 Instant P2P and Flooding Communications
Current GRASP already provides the capability to support instant P2P Current GRASP already provides the capability to support instant P2P
and flooding. It is natural to use the GRASP Synchronization message and flooding. It is natural to use the GRASP Synchronization message
directly for P2P distribution. Furthermore, it is also natural to use directly for P2P distribution. Furthermore, it is also natural to use
the GRASP Flood Synchronization message for 1-to-all distribution. the GRASP Flood Synchronization message for broadcast.
However, as mentioned in Section 3, in some scenarios one node needs However, as mentioned in Section 3, in some scenarios one node needs
to actively send some information to another. GRASP Synchronization to actively send some information to another. GRASP Synchronization
just lacks such capability. An un-solicited synchronization mechanism just lacks such capability, therefore an un-solicited synchronization
is needed. A relevant GRASP extension is defined in Section 6. mechanism is needed. An extension of GRASP message (i.e.
M_UNSOLIDSYN) is defined in Section 6.1.
5.1.2 Instant Selective Flooding Communication 5.1.2 Instant Selective Flooding Communication
When doing selective flooding, the distributed information needs to When doing selective flooding, the distributed information needs to
contain the criteria for nodes to judge which interfaces should be contain the criteria for nodes to judge which interfaces should be
sent the distributed information and which are not. Specifically, the sent the distributed information and which are not. Specifically, the
criteria contain: criteria contain:
o Matching condition: a set of matching rules. o Matching condition: a set of matching rules.
o Matching object: the object that the match condition would be o Matching object: the object that the match condition would be
applied to. For example, the matching object could be node itself applied to. For example, the matching object could be node itself
skipping to change at page 7, line 19 skipping to change at page 7, line 14
neighbor. If not, the node discards forwarding the message to the neighbor. If not, the node discards forwarding the message to the
neighbor. neighbor.
o When the Matching Object is the node itself, then the node o When the Matching Object is the node itself, then the node
matches the relevant information of its own to the Matching matches the relevant information of its own to the Matching
Condition. If the node finds itself matches the Matching Condition. If the node finds itself matches the Matching
Condition, then it forwards the distributed message to its Condition, then it forwards the distributed message to its
neighbors; if not, the node discards forwarding the message to the neighbors; if not, the node discards forwarding the message to the
neighbors. neighbors.
An example of selective flooding is briefly described in the Appendix GRASP is extended with a new option field (i.e. selective-flood-
A. option) to support selective flooding, shown in Section 6.2. This
option will be included in the original flooding message of GRASP. An
example of selective flooding is briefly described in the Appendix A.
5.2 Asynchronous Information Distribution 5.2 Asynchronous Information Distribution
Asynchronous information distribution happens in a different way Asynchronous information distribution happens in a different way
where sender(s) and receiver(s) are normally not immediately where sender(s) and receiver(s) are not immediately specified. Both
specified. Both senders and receivers may come up in an asynchronous senders and receivers may come up in an asynchronous way. First of
way. First of all, this requires that the information can be stored; all, this requires that the information can be stored; secondly, it
secondly, it requires an information publication and subscription requires an information publication and subscription (Pub/Sub)
(Pub/Sub) mechanism (corresponding protocol specification of Pub/Sub mechanism (corresponding protocol specification of Pub/Sub is defined
is defined in Section 6). in Section 6).
As we sketched in the previous section, in general, each node As we sketched in the previous section that in general each node
requires two modules: 1) Information Storage (IS) module and 2) Event requires two modules: 1) Information Storage (IS) module and 2) Event
Queue (EQ) module in the information distribution module. We Queue (EQ) module in the information distribution module. We
introduce details of the two modules in the following sections. introduce details of the two modules in the following sections.
5.2.1 Information Storage 5.2.1 Information Storage
IS module handles how to save and retrieve information for ASAs IS module handles how to save and retrieve information for ASAs
across the network. The IS module uses a syntax to index information, across the network. The IS module uses a syntax to index information,
generating the hash index value (e.g. a key) of the information and generating the hash index value (e.g. a hash key) of the information
mapping the hash index to a certain node in ANI. Note that, this and mapping the hash index to a certain node in ANI. Note that, this
mechanism can use existing solutions. Specifically, storing mechanism can use existing solutions. Specifically, storing
information in an ANIMA network will be realized in the following information in an ANIMA network will be realized in the following
steps. steps.
1) ASA-to-IS Negotiation. An ASA calls the API provided by 1) ASA-to-IS Negotiation. An ASA calls the API provided by
information distribution module (directly supported by IS sub- information distribution module (directly supported by IS sub-
module) to request to store the information somewhere in the module) to request to store the information somewhere in the
network. Such a request will be checked by the IS module who will network. Such a request will be checked by the IS module who will
be responsible for the request whether such a request is feasible be responsible for the request whether such a request is feasible
according to criteria such as permitted information size. according to criteria such as permitted information size.
skipping to change at page 9, line 34 skipping to change at page 9, line 33
5) (Optional) New Destination Request. If the information is not 5) (Optional) New Destination Request. If the information is not
found after the source IS module gets the response from the found after the source IS module gets the response from the
original destination node, the source IS module will have to original destination node, the source IS module will have to
discover where the location storing the requested information is. discover where the location storing the requested information is.
IS module can reuse distributed databases and key value stores like IS module can reuse distributed databases and key value stores like
NoSQL, Cassandra, DHT technologies. storage and retrieval of NoSQL, Cassandra, DHT technologies. storage and retrieval of
information are all event-driven responsible by the EQ module. information are all event-driven responsible by the EQ module.
5.2.2 Event Queue 5.2.2 Event Queue
The main job of Event Queue (EQ) module is to help ASAs to show The main job of Event Queue (EQ) module is to help ASAs to show
interests to particular information and notify the occurrences of interests to particular information and notify the occurrences of
that in asynchronous communication scenarios. In ANI, information that in asynchronous communication scenarios. In ANI, information
generated on network nodes is labeled as an event identified with an generated on network nodes is labeled as an event identified with an
event ID, which is semantically related to the topic of the event ID, which is semantically related to the topic of the
information. Key features of EQ module are summarized as follows. information. Key features of EQ module are summarized as follows.
1) Event Group: EQ module provides isolated queues for different 1) Event Group: EQ module provides isolated queues for different
event groups. If two groups of AFs could have completely different event groups. If two groups of AFs could have completely different
skipping to change at page 10, line 50 skipping to change at page 10, line 48
5) Event Match and Notification: While propagating updated event 5) Event Match and Notification: While propagating updated event
states, EQ module in parallel keeps matching published events and states, EQ module in parallel keeps matching published events and
its interested consumers. Once a match is found, the provider and its interested consumers. Once a match is found, the provider and
subscriber(s) will be notified for final information retrieval. subscriber(s) will be notified for final information retrieval.
Event contains the address where the information is stored, after a Event contains the address where the information is stored, after a
subscriber is notified, it directly retrieves the information from subscriber is notified, it directly retrieves the information from
the given location. the given location.
5.2.3 Interface between IS and EQ Modules 5.2.3 Integrating with GRASP APIs
EQ and IS modules are correlated. When an AF publishes information,
not only an publishing event is translated and sent to EQ module, but Actions triggered to the information distribution module will
also the information is indexed and stored simultaneously. Similarly, eventually invoke underlying GRASP APIs. Moreover, EQ and IS modules
when an AF subscribes information, not only subscribing event is are usually correlated. When an AF(ASA) publishes information, not
only such an event is translated and sent to EQ module, but also the
information is indexed and stored simultaneously. Similarly, when an
AF(ASA) subscribes information, not only subscribing event is
triggered and sent to EQ module, but also the information will be triggered and sent to EQ module, but also the information will be
retrieved by IS module at the same time. retrieved by IS module at the same time.
o Storing and publishing information: This action involves both IS
and EQ modules where a node that can store the information will be
discovered first and related event will e published to the network.
For this, GRASP APIs discover(), synchronize() and flood() are
combined to compose such a procedure. In specific, discover() call
will specific its objective being to "store_data" and the return
parameters could be either an ASA_locator who will accept to store
the data, or an error code indicating that no one could afford such
data; after that, synchronize() call will send the data to the
specified ASA_locator and the data will be stored at that node, with
return of processing results like store_data_ack; meanwhile, such a
successful event (i.e. data is stored successfully) will be flooded
via a flood() call to interesting parties (such a multicast group
existed).
o Subscribing and getting information: This action involves both IS
and EQ modules as well where a node that is interested in a topic
will subscribe the topic by triggering EQ module and if the topic is
ready IS module will retrieve the content of the topic (i.e. the
data). GRASP APIs such as register_objective(), flood(),
synchronize() are combined to compose the procedure. In specific, any
subscription action received by EQ module will be translated to
register_objective() call where the interested topic will be the
parameter inside of the call; the registration will be (selectively)
flooded to the network by an API call of flood() with the option we
extended in this draft; once a matched topic is found (because of the
previous procedure), the node finding such a match will call API
synchronize() to send the stored data to the subscriber.
5.3 Summary 5.3 Summary
In summary, the general requirements for the information distribution In summary, the general requirements for the information distribution
module on each autonomic node are two sub-modules handling instant module on each autonomic node are two sub-modules handling instant
communications and asynchronous communications, respectively. For communications and asynchronous communications, respectively. For
instant communications, node requirements are simple, in which instant communications, node requirements are simple, in which
signaling protocols have to be supported. With minimum efforts, signaling protocols have to be supported. With minimum efforts,
reusing the existing GRASP is possible. For asynchronous reusing the existing GRASP is possible. For asynchronous
communications, information distribution module requires event queue communications, information distribution module requires event queue
and information storage mechanism to be supported. and information storage mechanism to be supported.
6. Protocol Specification (GRASP extension) 6. Protocol Specification (GRASP extension)
There are multiple ways to integrate the information distribution There are multiple ways to integrate the information distribution
module. The principle we follow is to minimize modifications made to module. The principle we follow is to minimize modifications made to
the current ANI. the current ANI. We consider to use GRASP as a base to build up the
information distribution module. The main reason is that the current
We consider to use GRASP as an interface to access the information version of GRASP is already an information distribution module for
distribution module. The main reason is that the current version of the cases of P2P and flooding. In the following discussions, we
GRASP is already an information distribution module for the cases of introduce how to complete the missing part.
P2P and flooding. In the following discussions, we introduce how to
complete the missing part.
6.1 Un-solicited Synchronization Message (A new GRASP Message) 6.1 Un-solicited Synchronization Message (A new GRASP Message)
In fragmentary CDDL, a Un-solicited Synchronization message follows In fragmentary CDDL, a Un-solicited Synchronization message follows
the pattern: the pattern:
unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id,
objective]
A node MAY actively send a unicast Un-solicited Synchronization A node MAY actively send a unicast Un-solicited Synchronization
message with the Synchronization data, to another node. This MAY be message with the Synchronization data, to another node. This MAY be
sent to port GRASP_LISTEN_PORT at the destination address, which sent to port GRASP_LISTEN_PORT at the destination address, which
might be obtained by GRASP Discovery or other possible ways. The might be obtained by GRASP Discovery or other possible ways. The
synchronization data are in the form of GRASP Option(s) for specific synchronization data are in the form of GRASP Option(s) for specific
synchronization objective(s). synchronization objective(s).
6.2 Selective Flooding Option 6.2 Selective Flooding Option
In fragmentary CDDL, the selective flood follows the pattern: In fragmentary CDDL, the selective flood follows the pattern:
selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION, selective-flood-option = [O_SELECTIVE_FLOOD, +O_MATCH-CONDITION,
match-object, action] match-object, action]
O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2] O_MATCH-CONDITION = [O_MATCH-CONDITION, Obj1, match-rule, Obj2]
Obj1 = text Obj1 = text
match-rule = GREATER / LESS / WITHIN / CONTAIN match-rule = GREATER / LESS / WITHIN / CONTAIN
Obj2 = text Obj2 = text
match-object = NEIGHBOR / SELF match-object = NEIGHBOR / SELF
action = FORWARD / DROP action = FORWARD / DROP
The selective flood option encapsulates a match-condition option The selective flood option encapsulates a match-condition option
which represents the conditions regarding to continue or discontinue which represents the conditions regarding to continue or discontinue
flood the current message. For the match-condition option, the Obj1 flood the current message. For the match-condition option, the Obj1
skipping to change at page 13, line 21 skipping to change at page 13, line 50
= PUBLISH = PUBLISH
objective-flags = 2 objective-flags = 2
loop-count = 2 loop-count = 2
pubobj = text pubobj = text
This option MAY be included in GRASP M_Synchronization, when This option MAY be included in GRASP M_Synchronization, when
included, it means this message is for a publish of a specific object included, it means this message is for a publish of a specific object
data. data.
Note that extended GRASP messages with new arguments inside here will Note that extended GRASP messages with new arguments inside here will
trigger interactions/actions of the underlying information be triggered by interactions/actions from information distribution
distribution module introduced in Section 5. module introduced in Section 5.
7. Security Considerations 7. Security Considerations
The distribution source authentication could be done at multiple The distribution source authentication could be done at multiple
layers: layers:
o Outer layer authentication: the GRASP communication is within o Outer layer authentication: the GRASP communication is within
ACP (Autonomic Control Plane, ACP (Autonomic Control Plane,
[I-D.ietf-anima-autonomic-control-plane]). This is the default [I-D.ietf-anima-autonomic-control-plane]). This is the default
GRASP behavior. GRASP behavior.
 End of changes. 33 change blocks. 
84 lines changed or deleted 112 lines changed or added

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