One document matched: draft-liu-anima-grasp-distribution-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc category="std" docName="draft-liu-anima-grasp-distribution-03"
ipr="trust200902">
<front>
<title abbrev="GRASP Distribution">Information Distribution over
GRASP</title>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<!---->
<date day="31" month="October" year="2016"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref
target="I-D.behringer-anima-reference-model"/>. 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.</t>
<t>This document proposes to achieve distribution function based on the
GRASP (A Generic Autonomic Signaling Protocol) <xref
target="I-D.ietf-anima-grasp"/> . 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.</t>
</section>
<section title="Information Distribution Scenarios">
<t/>
<section title="Whole Domain Distribution">
<t>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.</t>
<t>The distributed information might not relevant to every autonomic
node, but it is flooded to all the devices.</t>
</section>
<section title="Selective Distribution">
<t>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.</t>
<t>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).</t>
</section>
<section title="Incremental Distribution">
<t>The distribution only goes to the nodes that newly get online. This
might mostly happen between neighbors.</t>
<t>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.</t>
</section>
</section>
<section title="Distribution Requirements">
<t/>
<section title="Identifying Autonomic Domain Boundary">
<t>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.</t>
</section>
<section title="Arbitrary Injecting Point">
<t>The distributed information SHOULD be injected at any autonomic
node within the domain (or within a specific set of nodes [TBD]).</t>
</section>
<section title="Avoiding Loops">
<t>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.</t>
</section>
<section title="Selective Flooding">
<t>When one node receive the information, it only floods it to the
neighbors that fit for a certain of rules.</t>
</section>
<section title="Point-to-Point Distribution">
<t>One node only distributes the information to another node. This is
for the incremental distribution scenario.</t>
</section>
<section title="Verification of Distributed Information">
<t><list style="symbols">
<t>Information integrity verification<list style="empty">
<t>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.</t>
</list></t>
<t>Source authorization verification<list style="empty">
<t>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.</t>
</list></t>
</list></t>
</section>
<section title="Conflict Handling">
<t>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.</t>
</section>
</section>
<section title="Distribution Function and Behavior Specification">
<t>This section specifies using certain GRASP messages for distribution,
and also specifies the distribution behavior in an autonomic node.</t>
<section title="Using GRASP Flood Synchronization Message">
<t>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.</t>
</section>
<section title="Using GRASP Synchronization Message">
<t>It is natural to use the GRASP Synchronization message for
Point-to-Point distribution. The two behavior is identical.</t>
</section>
<section title="Selective Flooding">
<t/>
<section anchor="FloodCtrl" title="Selecting Cretiria">
<t>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:</t>
<t><list style="symbols">
<t>Matching condition: a set of matching rules.</t>
<t>Matching object: the object that the match condition would be
applied to. For example, the matching object could be node
itself or its neighbors.</t>
<t>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.</t>
</list></t>
<t>Example:</t>
<t><list style="symbols">
<t>Matching condition: "Device role=IPRAN_RSG"</t>
<t>Matching objective: "Neighbors"</t>
<t>Action: "Forward"</t>
</list>This example means: only distributing the information to
the neighbors who are IPRAN_RSG.</t>
<t/>
</section>
<section title="Node Behavior">
<t>1) The distribution initial node Includes the Selecting Cretiria
information in the message that carries the distributed
information.</t>
<t>2) The recieving node decides the action according to the
Selecting Cretiria carried in the message.</t>
<t><list style="hanging">
<t hangText="2-1">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.</t>
<t hangText="2-2">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.</t>
</list></t>
</section>
</section>
<section title="Conflict Handling">
<t>The distribution information needs to include timestamps or version
information. When conflict happens, the node only accepts the latest
information.</t>
</section>
<section title="Distribution Source Authentication">
<t>The distribution source authentication could be done at multiple
layers:<list style="symbols">
<t>Outer layer authentication: the GRASP communication is within
ACP (Autonomic Control Plane, <xref
target="I-D.behringer-anima-autonomic-control-plane"/> ). This is
the default GRASP behavior.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>No IANA assignment is needed.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>This document is inherited from <xref target="I-D.ietf-anima-grasp"/>
and <xref target="I-D.behringer-anima-reference-model"/>. So thanks all
the contributors of the two work items.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.I-D.ietf-anima-grasp'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.behringer-anima-reference-model'?>
<?rfc include='reference.I-D.du-anima-an-intent'?>
<?rfc include='reference.I-D.pritikin-anima-bootstrapping-keyinfra'?>
<?rfc include='reference.I-D.behringer-anima-autonomic-control-plane'?>
<?rfc include='reference.I-D.irtf-nmrg-autonomic-network-definitions'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:49:52 |