Information Distribution over GRASP

In an autonomic network, sometimes the nodes need to share a set of common information. One typical case is the Intent Distribution which is briefly discussed in Section 4.5 of . However, the distribution should be a general function that one autonomic node should support, rather than a specific mechanism dedicated for Intent. This document firstly analyzes several basic information distribution scenarios (Section 2), and then discusses the technical requirements (Section 3) that one autonomic node needs to fulfill. This document proposes to achieve distribution function based on the GRASP (A Generic Autonomic Signaling Protocol) . GRASP already provides some capability to support part of the distribution function. Along with that, this document also proposes some additional functionality. Detailed design is described in Section 4.

Once the information is input to the autonomic network, the node that firstly handle the information MUST be able to distribute it to all the other nodes in the autonomic domain. The distributed information might not relevant to every autonomic node, but it is flooded to all the devices.

When one node receive the information, it only replicates it to the neighbors that fit for a certain of conditions. This could reduce some unnecessary signaling amplification. However, this scenario implies there needs to be corresponding mechanisms to represent the conditions and to judge which neighbors fit for the conditions. Please refer to Section 4.3.2 (selective flooding behavior).

The distribution only goes to the nodes that newly get online. This might mostly happen between neighbors. The incremental distribution could also be a sub scenario of the whole domain distribution. When one node is doing the whole domain distribution, it is possible that some of its neighbors are sleeping/off-line, so when the neighbors get online again, the node should do incremental distribution of the previous whole domain distributed information.

The domain boundary devices are supposed to know themselves as boundary. When the distribution messages come to the devices, they do not distribute them outside the domain.

The distributed information SHOULD be injected at any autonomic node within the domain (or within a specific set of nodes [TBD]).

There should be a mechanism to prevent the distributed information to travel around the domain again and again, so that there would not be a large amount of redundant packets troubling the network.

When one node receive the information, it only floods it to the neighbors that fit for a certain of rules.

One node only distributes the information to another node. This is for the incremental distribution scenario.

Information integrity verification The receiving node SHOULD be able to verify whether the distributed information is from the certain node. In other words, it needs to make sure the information hasn't been modified. Source authorization verification Even the information integrity was verified, the distributed information might still be invalid, since the distribution source might not have the right to distribute such information that it just exceeds its authority.

As long as it supports arbitrary point of injecting distribution, there is possibility that two nodes advertise the same information but with conflict attribute(s). Hence, there should be a mechanism to handle the conflict.

This section specifies using certain GRASP messages for distribution, and also specifies the distribution behavior in an autonomic node.

It is natural to use the GRASP Flood Synchronization message for distribution, since the Flood Synchronization behavior specified in GRASP is identical to the the whole domain distribution scenario described in Section 2.1. And the Flood Synchronization naturally fits for "Arbitrary Injection Point" and "Avoiding Loops" requirements.

It is natural to use the GRASP Synchronization message for Point-to-Point distribution. The two behavior is identical.

When doing selective flooding, the distributed information needs to contain the cretiria for nodes to judge which interfaces should be sent the distributed information and which are not. Specifically, the indication information needs to include following attributes/meta-data: Matching condition: which represents the cretiria of the selection. Matching objective: the matching objective is either the node itself or the neighbors. Action: the action is eithor continueing the distribution or terminating it. Example: Matching condition: "Device role=IPRAN_RSG" Matching objective: "Neighbors" Action: "Distribute" This example means: only distributing the information to the neighbors who are IPRAN_RSG.

1) The distribution initial node Includes the Selecting Cretiria as attributes/meta-data in the distributed information. 2) The recieving node does the matching indicated by the Selecting Cretiria. When the Matching Objective is "Neighbors", then the node only distributes the information to the neighbors who match the Matching Condition. When the Matching Objective is "Self", if matched, the node terminates the distribution (not flooding it to any of the neighbor).

The distribution information needs to include timestamps or version information. When conflict happens, the node only accepts the latest information.

The distribution source authentication could be done at multiple layers: Outer layer authentication: the GRASP communication is within ACP (Autonomic Control Plane, ). This is the default GRASP behavior. Inner layer authentication: the GRASP communication might not be within a protected channel, then there should be embedded protection in distribution information itself. Public key infrastructure might be involved in this case.

TBD.

No IANA assignment is needed.

This document is inherited from and . So thanks all the contributors of the two work items. This document was produced using the xml2rfc tool .