idnits 2.17.1 draft-liu-anima-intent-distribution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2015) is 3235 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.du-anima-an-intent' is mentioned on line 264, but not defined == Unused Reference: 'RFC2119' is defined on line 376, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-carpenter-anima-gdn-protocol-03 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-control-plane-02 == Outdated reference: A later version (-04) exists of draft-behringer-anima-reference-model-01 == Outdated reference: A later version (-02) exists of draft-pritikin-anima-bootstrapping-keyinfra-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Standards Track Huawei Technologies 5 Expires: December 14, 2015 June 12, 2015 7 Intent Distribution for Autonomic Networking 8 draft-liu-anima-intent-distribution-00 10 Abstract 12 This document describes the requirements of distributing intent 13 information in an autonomic network. Ideally, the intent may be 14 generated/injected at an arbitrary autonomic node and be distributed 15 among the whole autonomic domain. Then this document resolves the 16 distribution requirements into protocol design requirements. 17 Specifically, this document introduces a solution which is some 18 extension based on the Anima signalling protocol (GDNP, Generic 19 Discovery and Negotiation Protocol). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 14, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Intent Distribution Requirements . . . . . . . . . . . . . . 2 57 2.1. Distributed to the Whole Domain . . . . . . . . . . . . . 3 58 2.1.1. Autonomic Domain Boundary . . . . . . . . . . . . . . 3 59 2.2. De-coupling of Intent Content and Bearing Protocol . . . 3 60 2.3. Avoiding Signaling Storm . . . . . . . . . . . . . . . . 3 61 2.4. Arbitary Intent Injecting Point (Optional) . . . . . . . 3 62 2.5. Conflict Handling (Optional) . . . . . . . . . . . . . . 3 63 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4 65 3.1.1. Multicast and Unicast Communication . . . . . . . . . 4 66 3.1.2. Messages Interaction . . . . . . . . . . . . . . . . 4 67 3.1.3. Fragmentation Considerations . . . . . . . . . . . . 5 68 3.2. Intent Distribution over Anima Signaling Protocol . . . . 5 69 3.2.1. Intent Option . . . . . . . . . . . . . . . . . . . . 5 70 3.2.2. Node Behavior . . . . . . . . . . . . . . . . . . . . 6 71 3.2.3. Flooding Control . . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 7.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 This document describes the requirements of distributing intent 83 information in an autonomic network. Ideally, the intent may be 84 generated/injected at an arbitrary autonomic node and be distributed 85 among the whole autonomic domain. Then this document resolves the 86 distribution requirements into protocol design requirements. 87 Specifically, this document introduces a solution which is some 88 extension based on the Anima signalling protocol (GDNP, Generic 89 Discovery and Negotiation Protocol). 91 2. Intent Distribution Requirements 92 2.1. Distributed to the Whole Domain 94 When the intent is injected at an arbitrary autonomic node, the node 95 MUST be able to distribute it to the whole nodes in the domain. This 96 requirement does not necessarily mean the node need to send the 97 intent to all nodes through unicast or multicast all by itself; there 98 might be distribution function infrastructure that could be used/ 99 triggered by the node. 101 2.1.1. Autonomic Domain Boundary 103 The domain boundary devices are supposed to know themselves as 104 boundary.When the messages come to the devices, they won't distribute 105 them anymore so that the messages are only distributed with the 106 domain. 108 [Editor's Notes] It is a practical issue that how an autonomic node 109 knows itself is the domain boundary. It is not in the scope of this 110 document. 112 2.2. De-coupling of Intent Content and Bearing Protocol 114 The content of intent SHOULD NOT be coupled with the bearing 115 protocol. 117 2.3. Avoiding Signaling Storm 119 If flooding mechanism is used, then there should be a mechanism to 120 prevent the packets which carrying the intent to travel around the 121 domain again and again. 123 2.4. Arbitary Intent Injecting Point (Optional) 125 The intent SHOULD be injected at any autonomic node, rather than a 126 pre-specified Node. 128 Discuss: may be only within a group of autonomic nodes, it supports 129 input at "any" node. 131 2.5. Conflict Handling (Optional) 133 So long as it supports arbitrary point where to inject an intent, 134 there is possibility that two nodes advertise the same intent but 135 with different contents. Hence, there should be a mechanism to 136 handle the conflicted intent. 138 3. Protocol Design 140 3.1. Protocol Requirements 142 3.1.1. Multicast and Unicast Communication 144 The following communication modes need to be supported to distribute 145 intents. 147 o On Link Multicast 149 This is a basic distribution behavior. The message is 150 multicasted to all the other nodes on the same link. 152 o Off Link Multicast 154 Normally, an autonomic domain is not only limited within a 155 link. Thus, off link multicast is needed to reach the other 156 nodes out of the initiator's link. 158 When there is off-link multicast, there needs to be flooding 159 control mechanisms as described in Section 3.2.3. 161 o Point to Point 163 Besides multicast, the intent might be distributed only between 164 two nodes. Thus, point to point unicast communication is also 165 needed. 167 3.1.2. Messages Interaction 169 The following message interaction modes need to be supported. 171 o Unsolicited advertisement 173 This is the most typical use case of intent distribution. The 174 intent is advertised by one of the autonomic node and flooded 175 to all the others in the same autonomic domain. The process is 176 stateless ,which means there is no need to pre-establish 177 connections between autonomic nodes for intent exchange, hence 178 the autonomic nodes are always monitoring the intent coming. 180 [Editor's Note] This document doesn't achieve unsolicit 181 advertisement for intent as a new explicit message type, 182 instead, it is by the ASA interpreting the Intent Option 183 (defined below) and resolving it into GDNP synchronization 184 behavior at each hop. However, Unsolicit Advertisement might 185 be a generic function that reused by various ASA. So, if the 186 ANIMA signalling is going to provide such function at message 187 level in the future, this document would update accordingly. 189 o Request-Response 191 This is mostly for point-to-point intent exchange. For 192 example, when a new device gets online, it request intent from 193 it's neighbor, then the neighbor will distribute the common 194 intent that shared among all the nodes within the autonomic 195 domain to the new device. 197 3.1.3. Fragmentation Considerations 199 Since the intent distribution runs over GDNP, it does not provide any 200 explicit fragmentation/reassembly support. 202 [Editor's Note] However, there might be concern that when an intent 203 packet needs to be split, it might need to be split into fragments 204 each of which could be interpreted individually, thus there is no 205 need to wait for the assembling of all fragments. However, this is 206 only a hypothetical use case. 208 3.2. Intent Distribution over Anima Signaling Protocol 210 Since there is a signalling protocol under development in Anima 211 working group, it is reasonable to leverage the current protocol to 212 do intent distribution. 214 This section makes some extension to the signalling protocol to 215 fulfil the requirements described above. Specifically, the extension 216 is based on the 03 version of the GDNP protocol 217 [I-D.carpenter-anima-gdn-protocol] . 219 3.2.1. Intent Option 221 The content of intent is encapsulated as a dedicated option, so that 222 it could be carried by various type of messages if needed. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | OPTION_INTENT | option-len | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |F| Flood TTL | Reserved | Sequence Number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Domain ID of the Source Node of the Message | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | TBD | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Intent Content | 236 | (variable length, Supporting arbitrary format) | 237 . . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 OPTION_INTENT: Identifies the Intent Option type. 16-bit. 242 option-len: Length of the whole intent. 16-bit. 244 F bit: Flooding flag bit. When the flag is set, it means the intent 245 needs to be flooded. 247 Flood TTL: Limits the hops that an Intent message could travel. 248 8-bit. 250 Reserved: Set to zero, ignored on receipt. 8-bit. 252 Sequence Number: A sequence number to identify an intent option. 253 16-bit. Each time one node sends an Intent Option, the sequence 254 number MUST be increased. 256 Node ID: Identifies the source of the Intent Option. 32-bit. This 257 documents assumes that each autonomic nodes has a Node ID 258 available after the bootstrapping process described in 259 [I-D.pritikin-anima-bootstrapping-keyinfra] . The Node ID may 260 generated based on the domain certificate issued to the node 261 during bootstrapping. 263 Intent Content: The intent content, such as the intent specified in 264 [I-D.du-anima-an-intent]. 266 3.2.2. Node Behavior 268 o Initiating Node 270 a) Assuming there is an ASA in charge of the intent distribution. 272 b) The ASA generates the Intent Option and calls the GDNP module 273 to send the Intent Option in a Request Message (as defined in 274 Section 3.6.4 of [I-D.carpenter-anima-gdn-protocol] ). 276 c) If this is a flooding intent, the ASA sets the F flag and calls 277 the GDNP module to multicast the message to all it's neighbors 278 in a Discovery Message (as defined in Section 3.6.2 of 279 [I-D.carpenter-anima-gdn-protocol] ). 281 o Receiving Node 283 a) Assuming there is an ASA in charge of the intent distribution. 285 b) The GDNP module extracts the Intent Option and handle it up to 286 the ASA. 288 c) If the F flag is not set, the node calls the GDNP module to 289 response a Negotiation-Ending message with a Accept Option; if 290 set, then no need to response. [Open Question] Does nodes need 291 to response for the flooding intent? 293 d) If it is a flooding intent, the node multicast the option again 294 to all it's neighbors. 296 [Editor's Note] The behavior as described above could also be 297 achieved through Usolicit Synchronization message/function which was 298 briefly discussed in the previous version of GDNP. If the 299 Unsolicited Synchronization is added back to the GDNP, this document 300 should also consider the relevant solution accordingly. 302 3.2.3. Flooding Control 304 o Loop Avoidance 306 When messages are flooded off link, it is highly possible that 307 the message would be flooded back to the initiator again, thus 308 there would be a large amount of duplicated messages circling 309 around the network. So, there needs to be relevant mechanism 310 to avoid/limit the packets loop. 312 To achieve this goal, the nodes need to do the following 313 actions: 315 a) The node maintains a flooding state table which stores each 316 interface's record that whether a specific intent option had 317 been received or sent from it. The option identification 318 could be the combination of the Sequence Number and Node ID 319 in the Intent Option. 321 b) The node MUST NOT send a flooding Intent Option message to 322 the interfaces that had received or sent the same Intent 323 Option. 325 o Flooding TTL 327 In case an Intent is occasionally looped around, the Flooding 328 TTL is to guarantee the packet would not travel in a infinite 329 loop in the network. 331 [Open Question] Is Flooding TTL a redundant field? 333 4. Security Considerations 335 Intents could significantly influence the network nodes' behavior, so 336 authentication is strongly required. 338 However, the authentication could be done at multiple layers: 340 o Outer layer authentication: the ASAs' communication is within a 341 protected channel such as ACP (Autonomic Control Plane, 342 [I-D.behringer-anima-autonomic-control-plane] ). 344 o Inner layer authentication: the ASAs' communication might not be 345 within a protected channel, then there should be embedded 346 protection in intent distribution itself. 348 [Open Question] As described in section 7.3 of 349 [I-D.irtf-nmrg-autonomic-network-definitions], intent distribution is 350 considered as a function of the ACP. Do we consider to remove this 351 limitation? ACP is a good secure channel for distributing intent, 352 but maybe not a mandatory channel. 354 5. IANA Considerations 356 TBD. 358 6. Acknowledgements 360 This document is inherited from [I-D.carpenter-anima-gdn-protocol] 361 and [I-D.behringer-anima-reference-model]. So thanks all the 362 contributors of the two work items. 364 This document was produced using the xml2rfc tool [RFC2629]. 366 7. References 368 7.1. Normative References 370 [I-D.carpenter-anima-gdn-protocol] 371 Carpenter, B. and B. Liu, "A Generic Discovery and 372 Negotiation Protocol for Autonomic Networking", draft- 373 carpenter-anima-gdn-protocol-03 (work in progress), April 374 2015. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 380 June 1999. 382 7.2. Informative References 384 [I-D.behringer-anima-autonomic-control-plane] 385 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 386 Autonomic Control Plane", draft-behringer-anima-autonomic- 387 control-plane-02 (work in progress), March 2015. 389 [I-D.behringer-anima-reference-model] 390 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 391 and B. Liu, "A Reference Model for Autonomic Networking", 392 draft-behringer-anima-reference-model-01 (work in 393 progress), April 2015. 395 [I-D.irtf-nmrg-autonomic-network-definitions] 396 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 397 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 398 Networking - Definitions and Design Goals", draft-irtf- 399 nmrg-autonomic-network-definitions-07 (work in progress), 400 March 2015. 402 [I-D.pritikin-anima-bootstrapping-keyinfra] 403 Pritikin, M., Behringer, M., and S. Bjarnason, 404 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 405 bootstrapping-keyinfra-01 (work in progress), February 406 2015. 408 Authors' Addresses 409 Bing Liu 410 Huawei Technologies 411 Q14, Huawei Campus 412 No.156 Beiqing Road 413 Hai-Dian District, Beijing 100095 414 P.R. China 416 Email: leo.liubing@huawei.com 418 Sheng Jiang 419 Huawei Technologies 420 Q14, Huawei Campus 421 No.156 Beiqing Road 422 Hai-Dian District, Beijing 100095 423 P.R. China 425 Email: jiangsheng@huawei.com