Internet DRAFT - draft-liu-anima-intent-distribution
draft-liu-anima-intent-distribution
Network Working Group B. Liu
Internet-Draft S. Jiang
Intended status: Standards Track Huawei Technologies
Expires: December 14, 2015 June 12, 2015
Intent Distribution for Autonomic Networking
draft-liu-anima-intent-distribution-00
Abstract
This document describes the requirements of distributing intent
information in an autonomic network. Ideally, the intent may be
generated/injected at an arbitrary autonomic node and be distributed
among the whole autonomic domain. Then this document resolves the
distribution requirements into protocol design requirements.
Specifically, this document introduces a solution which is some
extension based on the Anima signalling protocol (GDNP, Generic
Discovery and Negotiation Protocol).
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 December 14, 2015.
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
Liu & Jiang Expires December 14, 2015 [Page 1]
Internet-Draft Intent distribution June 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Intent Distribution Requirements . . . . . . . . . . . . . . 2
2.1. Distributed to the Whole Domain . . . . . . . . . . . . . 3
2.1.1. Autonomic Domain Boundary . . . . . . . . . . . . . . 3
2.2. De-coupling of Intent Content and Bearing Protocol . . . 3
2.3. Avoiding Signaling Storm . . . . . . . . . . . . . . . . 3
2.4. Arbitary Intent Injecting Point (Optional) . . . . . . . 3
2.5. Conflict Handling (Optional) . . . . . . . . . . . . . . 3
3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
3.1.1. Multicast and Unicast Communication . . . . . . . . . 4
3.1.2. Messages Interaction . . . . . . . . . . . . . . . . 4
3.1.3. Fragmentation Considerations . . . . . . . . . . . . 5
3.2. Intent Distribution over Anima Signaling Protocol . . . . 5
3.2.1. Intent Option . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Node Behavior . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Flooding Control . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document describes the requirements of distributing intent
information in an autonomic network. Ideally, the intent may be
generated/injected at an arbitrary autonomic node and be distributed
among the whole autonomic domain. Then this document resolves the
distribution requirements into protocol design requirements.
Specifically, this document introduces a solution which is some
extension based on the Anima signalling protocol (GDNP, Generic
Discovery and Negotiation Protocol).
2. Intent Distribution Requirements
Liu & Jiang Expires December 14, 2015 [Page 2]
Internet-Draft Intent distribution June 2015
2.1. Distributed to the Whole Domain
When the intent is injected at an arbitrary autonomic node, the node
MUST be able to distribute it to the whole nodes in the domain. This
requirement does not necessarily mean the node need to send the
intent to all nodes through unicast or multicast all by itself; there
might be distribution function infrastructure that could be used/
triggered by the node.
2.1.1. Autonomic Domain Boundary
The domain boundary devices are supposed to know themselves as
boundary.When the messages come to the devices, they won't distribute
them anymore so that the messages are only distributed with the
domain.
[Editor's Notes] It is a practical issue that how an autonomic node
knows itself is the domain boundary. It is not in the scope of this
document.
2.2. De-coupling of Intent Content and Bearing Protocol
The content of intent SHOULD NOT be coupled with the bearing
protocol.
2.3. Avoiding Signaling Storm
If flooding mechanism is used, then there should be a mechanism to
prevent the packets which carrying the intent to travel around the
domain again and again.
2.4. Arbitary Intent Injecting Point (Optional)
The intent SHOULD be injected at any autonomic node, rather than a
pre-specified Node.
Discuss: may be only within a group of autonomic nodes, it supports
input at "any" node.
2.5. Conflict Handling (Optional)
So long as it supports arbitrary point where to inject an intent,
there is possibility that two nodes advertise the same intent but
with different contents. Hence, there should be a mechanism to
handle the conflicted intent.
Liu & Jiang Expires December 14, 2015 [Page 3]
Internet-Draft Intent distribution June 2015
3. Protocol Design
3.1. Protocol Requirements
3.1.1. Multicast and Unicast Communication
The following communication modes need to be supported to distribute
intents.
o On Link Multicast
This is a basic distribution behavior. The message is
multicasted to all the other nodes on the same link.
o Off Link Multicast
Normally, an autonomic domain is not only limited within a
link. Thus, off link multicast is needed to reach the other
nodes out of the initiator's link.
When there is off-link multicast, there needs to be flooding
control mechanisms as described in Section 3.2.3.
o Point to Point
Besides multicast, the intent might be distributed only between
two nodes. Thus, point to point unicast communication is also
needed.
3.1.2. Messages Interaction
The following message interaction modes need to be supported.
o Unsolicited advertisement
This is the most typical use case of intent distribution. The
intent is advertised by one of the autonomic node and flooded
to all the others in the same autonomic domain. The process is
stateless ,which means there is no need to pre-establish
connections between autonomic nodes for intent exchange, hence
the autonomic nodes are always monitoring the intent coming.
[Editor's Note] This document doesn't achieve unsolicit
advertisement for intent as a new explicit message type,
instead, it is by the ASA interpreting the Intent Option
(defined below) and resolving it into GDNP synchronization
behavior at each hop. However, Unsolicit Advertisement might
be a generic function that reused by various ASA. So, if the
Liu & Jiang Expires December 14, 2015 [Page 4]
Internet-Draft Intent distribution June 2015
ANIMA signalling is going to provide such function at message
level in the future, this document would update accordingly.
o Request-Response
This is mostly for point-to-point intent exchange. For
example, when a new device gets online, it request intent from
it's neighbor, then the neighbor will distribute the common
intent that shared among all the nodes within the autonomic
domain to the new device.
3.1.3. Fragmentation Considerations
Since the intent distribution runs over GDNP, it does not provide any
explicit fragmentation/reassembly support.
[Editor's Note] However, there might be concern that when an intent
packet needs to be split, it might need to be split into fragments
each of which could be interpreted individually, thus there is no
need to wait for the assembling of all fragments. However, this is
only a hypothetical use case.
3.2. Intent Distribution over Anima Signaling Protocol
Since there is a signalling protocol under development in Anima
working group, it is reasonable to leverage the current protocol to
do intent distribution.
This section makes some extension to the signalling protocol to
fulfil the requirements described above. Specifically, the extension
is based on the 03 version of the GDNP protocol
[I-D.carpenter-anima-gdn-protocol] .
3.2.1. Intent Option
The content of intent is encapsulated as a dedicated option, so that
it could be carried by various type of messages if needed.
Liu & Jiang Expires December 14, 2015 [Page 5]
Internet-Draft Intent distribution June 2015
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Flood TTL | Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID of the Source Node of the Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Intent Content |
| (variable length, Supporting arbitrary format) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_INTENT: Identifies the Intent Option type. 16-bit.
option-len: Length of the whole intent. 16-bit.
F bit: Flooding flag bit. When the flag is set, it means the intent
needs to be flooded.
Flood TTL: Limits the hops that an Intent message could travel.
8-bit.
Reserved: Set to zero, ignored on receipt. 8-bit.
Sequence Number: A sequence number to identify an intent option.
16-bit. Each time one node sends an Intent Option, the sequence
number MUST be increased.
Node ID: Identifies the source of the Intent Option. 32-bit. This
documents assumes that each autonomic nodes has a Node ID
available after the bootstrapping process described in
[I-D.pritikin-anima-bootstrapping-keyinfra] . The Node ID may
generated based on the domain certificate issued to the node
during bootstrapping.
Intent Content: The intent content, such as the intent specified in
[I-D.du-anima-an-intent].
3.2.2. Node Behavior
o Initiating Node
a) Assuming there is an ASA in charge of the intent distribution.
Liu & Jiang Expires December 14, 2015 [Page 6]
Internet-Draft Intent distribution June 2015
b) The ASA generates the Intent Option and calls the GDNP module
to send the Intent Option in a Request Message (as defined in
Section 3.6.4 of [I-D.carpenter-anima-gdn-protocol] ).
c) If this is a flooding intent, the ASA sets the F flag and calls
the GDNP module to multicast the message to all it's neighbors
in a Discovery Message (as defined in Section 3.6.2 of
[I-D.carpenter-anima-gdn-protocol] ).
o Receiving Node
a) Assuming there is an ASA in charge of the intent distribution.
b) The GDNP module extracts the Intent Option and handle it up to
the ASA.
c) If the F flag is not set, the node calls the GDNP module to
response a Negotiation-Ending message with a Accept Option; if
set, then no need to response. [Open Question] Does nodes need
to response for the flooding intent?
d) If it is a flooding intent, the node multicast the option again
to all it's neighbors.
[Editor's Note] The behavior as described above could also be
achieved through Usolicit Synchronization message/function which was
briefly discussed in the previous version of GDNP. If the
Unsolicited Synchronization is added back to the GDNP, this document
should also consider the relevant solution accordingly.
3.2.3. Flooding Control
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.
To achieve this goal, the nodes need to do the following
actions:
a) The node maintains a flooding state table which stores each
interface's record that whether a specific intent option had
been received or sent from it. The option identification
could be the combination of the Sequence Number and Node ID
in the Intent Option.
Liu & Jiang Expires December 14, 2015 [Page 7]
Internet-Draft Intent distribution June 2015
b) The node MUST NOT send a flooding Intent Option message to
the interfaces that had received or sent the same Intent
Option.
o Flooding TTL
In case an Intent is occasionally looped around, the Flooding
TTL is to guarantee the packet would not travel in a infinite
loop in the network.
[Open Question] Is Flooding TTL a redundant field?
4. Security Considerations
Intents could significantly influence the network nodes' behavior, so
authentication is strongly required.
However, the authentication could be done at multiple layers:
o Outer layer authentication: the ASAs' communication is within a
protected channel such as ACP (Autonomic Control Plane,
[I-D.behringer-anima-autonomic-control-plane] ).
o Inner layer authentication: the ASAs' communication might not be
within a protected channel, then there should be embedded
protection in intent distribution itself.
[Open Question] As described in section 7.3 of
[I-D.irtf-nmrg-autonomic-network-definitions], intent distribution is
considered as a function of the ACP. Do we consider to remove this
limitation? ACP is a good secure channel for distributing intent,
but maybe not a mandatory channel.
5. IANA Considerations
TBD.
6. Acknowledgements
This document is inherited from [I-D.carpenter-anima-gdn-protocol]
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].
Liu & Jiang Expires December 14, 2015 [Page 8]
Internet-Draft Intent distribution June 2015
7. References
7.1. Normative References
[I-D.carpenter-anima-gdn-protocol]
Carpenter, B. and B. Liu, "A Generic Discovery and
Negotiation Protocol for Autonomic Networking", draft-
carpenter-anima-gdn-protocol-03 (work in progress), April
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
7.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-02 (work in progress), March 2015.
[I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and B. Liu, "A Reference Model for Autonomic Networking",
draft-behringer-anima-reference-model-01 (work in
progress), April 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., Behringer, M., and S. Bjarnason,
"Bootstrapping Key Infrastructures", draft-pritikin-anima-
bootstrapping-keyinfra-01 (work in progress), February
2015.
Authors' Addresses
Liu & Jiang Expires December 14, 2015 [Page 9]
Internet-Draft Intent distribution June 2015
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 December 14, 2015 [Page 10]
