Information Distribution over
GRASP
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
leo.liubing@huawei.com
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
jiangsheng@huawei.com
This document discusses the requirement of information distribution
capability in autonomic networks. Ideally, the autonomic network should
support distributing some information which is generated/injected at an
arbitrary autonomic node and be distributed among the whole autonomic
domain. This docuemnt specifically proposes to achive this goal based on
the GRASP (A Generic Autonomic Signaling Protocol), and specifies
additional node behavior.
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 cretiria contains:
Matching condition: a set of matching rules.
Matching object: the object that the match condition would be
applied to. For example, the matching object could be node
itself or its neighbors.
Action: what behavior the node needs to do when the matching
object matches or failed the matching condition. For example,
the action could be forwarding or discarding the distributed
message.
Example:
Matching condition: "Device role=IPRAN_RSG"
Matching objective: "Neighbors"
Action: "Forward"
This example means: only distributing the information to
the neighbors who are IPRAN_RSG.
1) The distribution initial node Includes the Selecting Cretiria
information in the message that carries the distributed
information.
2) The recieving node decides the action according to the
Selecting Cretiria carried in the message.
When the Matching Object is "Neighbors", then
the node matches the relevant information of its neighbors to
the Matching Condition. If the node finds one neighbor matches
the Matching Condition, then it forwards the distributed messge
to the neighbor. If not, the node discards forwarding the
message to the neighbor.
When the Matching Object is the node itself,
then the node matches the relevant information of its own to the
Matching Condition. If the node finds itself matches the
Matching Condition, then it forwards the distributed messge to
its neighbors; if not, the node discards forwarding the message
to the neighbors.
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.
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 .