One document matched: draft-liu-anima-grasp-distribution-00.txt
Network Working Group B. Liu
Internet-Draft S. Jiang
Intended status: Standards Track Huawei Technologies
Expires: April 21, 2016 October 19, 2015
Information Distribution over GRASP
draft-liu-anima-grasp-distribution-00
Abstract
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 proposes relevant protocol extension to GRASP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Liu & Jiang Expires April 21, 2016 [Page 1]
Internet-Draft GRASP Distribution October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Information Distribution Scenarios . . . . . . . . . . . . . 3
2.1. Whole Domain Distribution . . . . . . . . . . . . . . . . 3
2.2. Selective Distribution . . . . . . . . . . . . . . . . . 3
2.3. Incremental Distribution . . . . . . . . . . . . . . . . 3
3. Distribution Capability Requirements . . . . . . . . . . . . 3
3.1. Generic requirements . . . . . . . . . . . . . . . . . . 3
3.1.1. Autonomic Domain Boundary . . . . . . . . . . . . . . 3
3.1.2. Avoiding Signaling Storm . . . . . . . . . . . . . . 4
3.1.3. Arbitrary Injecting Point (Optional) . . . . . . . . 4
3.1.4. Confliction Handling (Optional) . . . . . . . . . . . 4
3.1.5. Verification of Distributed Information . . . . . . . 4
3.2. Node Behavior . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Flooding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Selective Flooding . . . . . . . . . . . . . . . . . 5
3.2.3. Point to Point . . . . . . . . . . . . . . . . . . . 5
3.3. Distribution indication . . . . . . . . . . . . . . . . . 5
3.4. Selective distribution indication . . . . . . . . . . . . 6
4. Information Distribution over GRASP . . . . . . . . . . . . . 6
4.1. Distribution indication . . . . . . . . . . . . . . . . . 6
4.1.1. Candidated solution 1: Overloading current messages . 6
4.1.2. Candidated solution 2: Information Distribution
Message . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Selective Distribution indication . . . . . . . . . . . . 7
4.3. Node behavior . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Flooding behavior . . . . . . . . . . . . . . . . . . 7
4.3.2. Selective Flooding behavior . . . . . . . . . . . . . 8
4.3.3. Point to Point behavior . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The GRASP is mostly for negotiation between two nodes. Besides
negotiation function, there is also requirement of simply delivering
information among nodes. GRASP synchronirozation is defined for this
requirement. However, the synchronization is a very simple mechanism
that might not fulfil all the information delivery requirements in a
Liu & Jiang Expires April 21, 2016 [Page 2]
Internet-Draft GRASP Distribution October 2015
autonomic network. So this document proposes a comprehensive
function called "Distribution Capability" to fulfil the goals.
Multicast/flooding behaviors are involved in distribution capability,
but distribution capability itself doesn't simply equal to these
behaviors.
This document describes the requirements of distributing information/
signal (e.g. Autonomic Network Intent, which is discussed in
[I-D.du-anima-an-intent] ) in an autonomic network. Although the
most obvious distributed information might be Intent, this document
considers distribution capablility as a general function that the
autonomic networks should support,rather than a specific mechanism
dedicated for Intent. Ideally, the information/signal may be
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) [I-D.ietf-anima-grasp] , and proposes relevant
protocol extension to GRASP.
2. Information Distribution Scenarios
2.1. Whole Domain Distribution
Once the information is input to the autonomic network, the node that
firstly handle the information MUST be able to distribute it to the
all the other nodes in the autonomic domain.
2.2. Selective Distribution
The distribution only works on a specific group nodes to control
unnecessary flooding.
2.3. Incremental Distribution
The distribution only goes to the nodes that newly get online.
3. Distribution Capability Requirements
3.1. Generic requirements
3.1.1. Autonomic Domain Boundary
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.
Liu & Jiang Expires April 21, 2016 [Page 3]
Internet-Draft GRASP Distribution October 2015
[Editor's Notes] It is a practical issue that how an autonomic node
recognizes itself as a domain boundary device. It is not in the
scope of this document.
3.1.2. Avoiding Signaling Storm
There should be a mechanism to prevent the distributed object to
travel around the domain again and again, so that there would not be
a large amout of redundant packets troubling the network.
3.1.3. Arbitrary Injecting Point (Optional)
The distributed object SHOULD be injected at any autonomic node
within the domain (or within a specific group [TBD]).
3.1.4. Confliction Handling (Optional)
As long as it supports arbitrary point of injecting an object, there
is possibility that two nodes advertise the same object but with
conflict content. Hence, there should be a mechanism to handle the
confliction.
3.1.5. Verification of Distributed Information
o Information integrity verification
The recieving 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.
o Source authorization verification
Even the information integrity was verified, the distibuted
information might still be invalid, since the distribution
source might doesn't have the right to distribute such
information that it just exceeds its authority.
3.2. Node Behavior
3.2.1. Flooding
The flooding behavior is mostly for the whole domain distribution
scenario.
o Flooding to all interfaces
Liu & Jiang Expires April 21, 2016 [Page 4]
Internet-Draft GRASP Distribution October 2015
a) Flooding to all the interfaces attached to the node. This is
the basic requirement. The interfaces include both phisical
interfaces and the virtual interfaces for example the ACP
tunnels.
b) Besides replicating the message to all interfaces, the node
might also replicate the message to all recorded IP addresses
of all the other nodes. The addresses might be got through
some mechanisms such as routing protocol. This L3
communication behavior could also be seen as a flooding. [Open
Question] Do we need this L3 distribution feature?
o Loop Avoidance
When messages are flooded off link, it is highly possible that
the message would be flooded back to the initiator again, thus
there would be a large amount of duplicated messages circling
around the network. So, there needs to be relevant mechanism
to avoid/limit the packets loop.
3.2.2. Selective Flooding
In contrast to flooding, there should be selective fooding of the
node to achieve selective distribution.
Selective flooding means the receiving node would only replica the
informaion to part of the interfaces.
[Editor's Note] Details TBD.
3.2.3. Point to Point
To fulfil the incremental distribution, the nodes also need to
support point to point mode. This behavior is already included in
current GRASP in the form of Synchronization.
3.3. Distribution indication
The autonomic nodes need to be able to distinguish the information
that needs to be distributed from the other information. Hence,
there should be an indication signal within the messgage that carries
the information. This could be achieved through various ways:
o A new message dedicated for distribution. The message itself
means it needs to be distributed, the receiving nodes will
distribute the whole messge.
Liu & Jiang Expires April 21, 2016 [Page 5]
Internet-Draft GRASP Distribution October 2015
o A new option dedicated for distribution. the receiving nodes might
not need to distribute the whole messge, they could distribute the
option in other messages they slected.
o An indicator such as flag in message or option. In this case,
every existing message or option could be extended to indicate
distribution.
[Open discussion] Which one is the best approach?
3.4. Selective distribution indication
When doing selective flooding, the node needs to be aware of which
interfaces should be sent the distributed information and which are
not.
One possible way is that the chosen interfaces match a certain
policy/rule which carried along with the distributed information.
The nodes would parse the policy/rule and decide which interfaces to
be flooded accordingly.
4. Information Distribution over GRASP
This section makes some extension to the signalling protocol to
fulfil the distribution requirement.
4.1. Distribution indication
4.1.1. Candidated solution 1: Overloading current messages
o Initiating Node
a) Assuming there is a distribution module running apon GRASP in
charge of the information distribution.
b) The distribution module calls the GRASP module to encapsulate
the distributed information into an Option (either dedicated
distribution option or other options that extended by a
Distribution flag) in an Unsolicited Response Message (as
discussed in Section 3.3.5 of [I-D.ietf-anima-grasp] ), and
send the message to all the interfaces.
o Receiving Node
a) Assuming there is an distribution module running upon GRASP in
charge of the information distribution.
Liu & Jiang Expires April 21, 2016 [Page 6]
Internet-Draft GRASP Distribution October 2015
b) After recieving the distributed information, The GRASP module
relay the message to other interfaces.
c) However, if the node is the distribution boundary, it MUST NOT
relay the message again.
In this case, the Response Message is overloaded for distribution
indication, when it is an Unsolicited Response Message. This
solution is already covered by current [I-D.ietf-anima-grasp] .
4.1.2. Candidated solution 2: Information Distribution Message
Although the distribution behavior might be achieved by using current
GRASP messages, the message overloading might add unnecessary
complexity to the GRASP stack.
So, a new message dedicated for information distribution might be
better.
4.2. Selective Distribution indication
There needs to be new added mechanism to achieve this goal,
regardless of which distribution indication candidate solution is
chosen.
Specific desigh is TBD.
4.3. Node behavior
4.3.1. Flooding behavior
o Basic behavior
When the node receives a distributed information message/
option, it replicates the information to all the other
interfaces.
o Loop Avoidance
There might be multiple ways to achieve this goal. This
document proposes two of them for discussion.
One is as the following:
a) The node maintains a flooding state table which stores each
interface's record that whether a specific distributed
message (or option) had been received or sent from it. The
Liu & Jiang Expires April 21, 2016 [Page 7]
Internet-Draft GRASP Distribution October 2015
identification could be the combination of the Sequence
Number and Node ID.
b) The node MUST NOT send a flooding message/option to the
interfaces that had received or sent the same distributed
information.
The other is:
flooding with sequence numbers for loop/duplicate avoidance
o Flooding TTL
In case an message/option is occasionally looped around, the
Flooding TTL is to guarantee the packet would not travel in a
infinite loop in the network.
4.3.2. Selective Flooding behavior
TBD.
4.3.3. Point to Point behavior
The point to point distribution has been covered by the GRASP
Synchronization function.
5. Security Considerations
The distribution source authentication could be done at multiple
layers:
o Outer layer authentication: the GRASP communication is within a
protected channel such as ACP (Autonomic Control Plane,
[I-D.behringer-anima-autonomic-control-plane] ).
o Inner layer authentication: the GRASP communication might not be
within a protected channel, then there should be embedded
protection in distribution itself. Public key infrastructure
might be involved in this case.
6. IANA Considerations
TBD.
Liu & Jiang Expires April 21, 2016 [Page 8]
Internet-Draft GRASP Distribution October 2015
7. Acknowledgements
This document is inherited from [I-D.ietf-anima-grasp] and
[I-D.behringer-anima-reference-model]. So thanks all the
contributors of the two work items.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-01 (work in progress), October 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
8.2. Informative References
[I-D.behringer-anima-autonomic-control-plane]
Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", draft-behringer-anima-autonomic-
control-plane-03 (work in progress), June 2015.
[I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-behringer-anima-
reference-model-04 (work in progress), October 2015.
[I-D.du-anima-an-intent]
Du, Z., Jiang, S., Jeff, J., and L. Ciavaglia, "Autonomic
Network Intent and Format", draft-du-anima-an-intent-01
(work in progress), July 2015.
Liu & Jiang Expires April 21, 2016 [Page 9]
Internet-Draft GRASP Distribution October 2015
[I-D.irtf-nmrg-autonomic-network-definitions]
Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking - Definitions and Design Goals", draft-irtf-
nmrg-autonomic-network-definitions-07 (work in progress),
March 2015.
[I-D.pritikin-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S.
Bjarnason, "Bootstrapping Key Infrastructures", draft-
pritikin-anima-bootstrapping-keyinfra-02 (work in
progress), July 2015.
Authors' Addresses
Bing Liu
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Liu & Jiang Expires April 21, 2016 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-22 14:56:11 |