idnits 2.17.1 draft-foglar-ipv6-ull-routing-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2018) is 2060 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing Area Working Group A. Foglar, InnoRoute 2 INTERNET-DRAFT M. Parker, Uni Essex 3 Intended status: EXPERIMENTAL T. Rokkas, Incites 4 Expires: January 31, 2019 August 30, 2018 6 IPv6 Source Routing for ultralow Latency 7 draft-foglar-ipv6-ull-routing-03 9 Abstract 11 This Internet-Draft describes a hierarchical addressing scheme 12 for IPv6, intentionally very much simplified to allow for very 13 fast source routing experimentation using simple forwarding 14 nodes. Research groups evaluate achievable latency reduction 15 for special applications such as radio access networks, 16 industrial networks or other networks requiring very low 17 latency. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as 37 the document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Revision Note for Version 02 51 Reference to experimental verification of the concept is added in the 52 section "Acknowledgements". 54 Revision Note for Version 03 56 Section 6 about Security Considerations has been inserted. 58 1. Introduction 60 To achieve minimum latency the forwarding nodes must support 61 cut-through technology as opposed to the commonly used store- 62 and-forward technology. Cut-through means, that the packet 63 header already leaves a node at the egress port while the tail 64 of the packet is still received at the ingress port. This 65 short time does not allow complex routing decisions. 67 Therefore, a very simple routing address field structure is 68 specified below. It should limit the complexity of the 69 forwarding node used in the experiments. Therefore, in this 70 text the term "forwarding node" is used instead of "router", 71 although the device is operating in OSI Layer 3 and accordingly 72 executes router functions such as decrementing the hop limit field. 73 Redundancy issues are not considered. 75 2. IPv6 address prefix structure 77 The following proposal uses the 64-bit IPv6 address prefix. 79 Each forwarding node has up to 16 ports and hence needs 4 bits 80 of the address field to decide to which port a packet should 81 be forwarded. The 64-bit prefix is divided into 16 sub-fields 82 of 4 bit, defining up to 16 hierarchy levels. A forwarding 83 node is configured manually to which of the sub-fields it should 84 evaluate for the forwarding decision. 86 A number n of leading 4-bit fields cannot be used for forwarding 87 decisions, but must have a special value to indicate the 88 'escape prefix' of the experimental forwarding mode. 90 The 64-bit prefix of the IPv6 address has this structure: 92 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 94 The first 4-bit field following the escape prefix has the 95 highest hierarchy level, the last 4-bit field has the lowest 96 hierarchy level. 98 3. Forwarding node behavior 100 The forwarding node has up to 16 downlink ports and at least 101 one uplink port. Typically, the forwarding nodes are arranged 102 in a regular tree structure with one top node, up to 16 nodes 103 in the second hierarchy, up to 256 nodes in the third hierarchy 104 and so on for up to 16-n hierarchies. 106 A forwarding node must be configured to operate at a certain 107 position in the hierarchical network. For example, at third 108 hierarchy level, branch 4 of the first hierarchy and branch 12 109 of the second hierarchy. 111 The behavior of each forwarding node is depending on the 112 position of a node in a hierarchical network. For all 113 positions, the first step is to check the escape prefix. Only 114 packets with matching escape prefix are forwarded. 116 The top forwarding node with the highest hierarchy level 117 evaluates the first 4-bit field following the n x 4-bit escape 118 prefix. The value of the evaluation field determines the 119 output port of the packet. The remaining fields are don't 120 care: 122 | escape prefix | 4-bit | (16-n-1) x 4-bit | 123 < mandatory > < don't care > 125 A forwarding node in a lower hierarchy first checks if the 4- 126 bit fields preceding the evaluation field match the configured 127 value. In case of match the value of the configured evaluation 128 field of the packet is used as downlink port number where the 129 packet is forwarded. The remaining 4-bit fields are ignored. 130 In case of mismatch the packet is forwarded to the uplink 131 port(s). 133 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 134 < mandatory > < match > < don't care > 136 The parameter m indicates the hierarchy level with m=0 137 denoting the highest hierarchy. 139 Hence, when a packet enters a hierarchical network at the 140 lowest layer node it is forwarded in uplink direction until it 141 reaches a node where the m x 4-bit prefix matches the 142 configured value of the node. At latest, the highest-level 143 node will always match and forward the packet in the desired 144 downlink direction. 146 4. Numerical values 148 As mentioned, one pre-requisite of the simple forwarding 149 concept is to keep the complexity of the forwarding nodes low. 150 Also, the configuration of the nodes should be kept simple. In 151 particular industrial networks are operated by persons who are 152 not experts in communication. Configurations should be 153 intuitively understandable by all without long explication. 154 Therefore, for the first experimental forwarding node the 155 number of downlink ports is limited to 10 with numbers 0...9. 16 156 digits at the front panel of the forwarding device show the 157 configuration. Use of classical 7-segment digits make the 158 limits of the configuration obvious. 160 As escape code, the first two digits are fixed to the value 161 "AF" (binary '10101111'). These two characters contrast with 162 the following numerical digits, so that the escape code can be 163 clearly differentiated from the following configuration. The 164 display uses the 'H' character instead of the 'X' the usual 165 term for the variable. 167 The H specifies the digit of the packet prefix which is 168 evaluated for forwarding. When the H is selected all lower 169 digits are automatically set to '-' to indicate the don't care 170 nature. 172 To make the configuration still more obvious it is recommended 173 to configure the local telephone number. With that measure, 174 every local experimentation has unique numbers and can 175 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 176 with other experimental setups. 178 The length of 14 digits allows sufficient in-house 179 hierarchies, even for industrial applications where forwarding 180 nodes interconnect large numbers of sensor controllers. 181 Inhouse installations would be structured for example in 182 building, floor, fabrication unit, machine - with one sensor 183 controller per machine. For the sake of simplicity numbers are 184 deliberately wasted, for example if the building has only 3 185 stories the digits 4...9 are unused. 187 5. Example configuration 189 A small office in Munich with the telephone number +49-89- 190 45241990 configures its local top-level forwarding node to: 192 AF49.8945.2419.90H- 194 Note that for the sake of simplicity this simplified notation 195 is introduced here as alternative to the usual notation 196 AF49:8945:2419:9000/56. With the new notation, the cabling 197 staff people can immediately check the hierarchy location of 198 the forwarding node and connect the cables to the floors at 199 ports 0...3. 201 The next hierarchy level is related to the floor. In case of a 202 3-story building only three next level forwarding nodes are 203 used with these configured values: 205 AF49.8945.2419.900H at the ground level 206 AF49.8945.2419.901H at the first floor 207 AF49.8945.2419.902H at the second floor 208 AF49.8945.2419.903H at the third floor. 210 In each floor, up to 10 sensor nodes can be connected. 211 Each of the sensor nodes can address several sensors/ 212 actuators addressed via the interface identifier contained in 213 the second part of the 128-bit IPv6 address. 215 In the following a connection between sensors in this office to 216 otherIoT equipment located in Essex University is described. The 217 connection is realized with one additional forwarding node 218 installed at Essex University premises with the second level address 220 AF4H.----.----.----. 222 This high level forwarding node can be used although the phone number 223 of the researcher is +44 1206 872413, as long as there is no further 224 node in UK. 226 At downlink port 9 the 13th level forwarding node in Munich is con- 227 nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. 228 The levels in between must not be populated by forwarding nodes as 229 long as no other branch is needed at one of the two sides. 230 If for example another site in Munich center must be connected one 231 additional forwarding node must be installed with the 5th level 232 address 234 AF49.89H-.----.----. 236 The small office mentioned above would be connected to downlink port 237 4 while the new site would be connected at downlink port 1, the 238 prefix for Munich center. The configuration is visualized in the 239 Figure below. 241 Essex (UK) Munich (DE) 243 |---------U-----------| 244 | AF4H.----.----.---- | 245 |-0-1-2-3-4-5-6-7-8-9-| 246 | \ 247 | ------ L2 Link ------ 248 |----------| \ 249 | IoT node | |----------U----------| 250 |----------| | AF49.89H-.----.---- | 251 |-0-1-2-3-4-5-6-7-8-9-| 252 / \ 253 --- ----------- 254 / \ 255 |----------U----------| |----------U----------| 256 | AF49.89H-.----.---- | | AF49.8945.2419.90H- | 257 |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| 258 | 259 |----------U----------| 260 | AF49.8945.5419.901H | 261 |-0-1-2-3-4-5-6-7-8-9-| 262 U = Uplink | 263 |----------| 264 | IoT node | 265 |----------| 266 Figure: Example Configuration 268 6. Security Considerations 270 In a hierarchical network as described above every forwarding node 271 can easily check a part of the source address of the packets. For 272 example, the IoT node in the above Figure will get the following 273 address assigned: AF49.8945.5419.9014. It will use this address as 274 source address when it sends packets in upstream direction. The node 275 above receives the packets at port 4 and expects that the digit at 276 the position of the 'H' will be a 4. 278 Moreover, a node in upstream direction will check if the prefix of 279 the packet's source address. For example the top Munich node in the 280 above figure will check the source address of packets received from 281 downlinks to be AF49.89. 283 Hence, the source addresses of all packets forwarded in upstream 284 direction will be checked repeatedly all the way up in the hierarchy. 285 In case of mismatch, either an error has occurred or an intentional 286 address falsification. Both cases should be avoided and therefore 287 such packets are discarded. 289 In consequence, a receiver in the hierarchical forwarding network can 290 rely on the correctness of the source addresses of the received 291 packets. This feature is ideal for white-listing, which in turn is 292 ideal for IoT applications. Other than in the 'normal' Internet 293 access to IoT devices is not needed for every host. In contrary, IoT 294 devices will have restricted access for authorized hosts only. 296 Note that the verified source address feature is orthogonal to other 297 security measures such as password authentication and encryption. 299 7. Acknowledgements 301 The authors would like to thank the consortium of the European 302 research project CHARISMA for the possibility to experiment. The 303 description of the final demonstration is available for download: 304 http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst 305 rators-Evaluation-and-Validation-vFinal.pdf 307 8. Authors' Addresses 309 Andreas Foglar 310 InnoRoute GmbH 311 Marsstr. 14a 312 80335 Munich 313 Germany 314 Email: foglar@innoroute.de 316 Mike Parker 317 Wivenhoe Park, Colchester 318 Essex, CO3 4HG 319 United Kingdom 320 Email: mcpark@essex.ac.uk 322 Theodoros Rokkas 323 Incites S.A.R.L. 324 130, Route d' Arlon 325 Strassen L-8008 326 Luxembourg 327 Email: trokkas@incites.eu 329 Foglar, Parker, Rokkas Expires January 31, 2019