idnits 2.17.1 draft-foglar-ipv6-ull-routing-06.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 date (January 20, 2020) is 1551 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 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: July 18, 2020 January 20, 2020 6 IPv6 Source Routing for ultralow Latency 7 draft-foglar-ipv6-ull-routing-06 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) 2019 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 Revision Note for Version 04 60 Section 7 about Redundancy has been inserted. 62 1. Introduction 64 To achieve minimum latency the forwarding nodes must support 65 cut-through technology as opposed to the commonly used store- 66 and-forward technology. Cut-through means, that the packet 67 header already leaves a node at the egress port while the tail 68 of the packet is still received at the ingress port. This 69 short time does not allow complex routing decisions. 71 Therefore, a very simple routing address field structure is 72 specified below. It should limit the complexity of the 73 forwarding node used in the experiments. Therefore, in this 74 text the term "forwarding node" is used instead of "router", 75 although the device is operating in OSI Layer 3 and accordingly 76 executes router functions such as decrementing the hop limit field. 77 Redundancy issues are not considered. 79 2. IPv6 address prefix structure 81 The following proposal uses the 64-bit IPv6 address prefix. 83 Each forwarding node has up to 16 ports and hence needs 4 bits 84 of the address field to decide to which port a packet should 85 be forwarded. The 64-bit prefix is divided into 16 sub-fields 86 of 4 bit, defining up to 16 hierarchy levels. A forwarding 87 node is configured manually to which of the sub-fields it should 88 evaluate for the forwarding decision. 90 A number n of leading 4-bit fields cannot be used for forwarding 91 decisions, but must have a special value to indicate the 92 'escape prefix' of the experimental forwarding mode. 94 The 64-bit prefix of the IPv6 address has this structure: 96 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 98 The first 4-bit field following the escape prefix has the 99 highest hierarchy level, the last 4-bit field has the lowest 100 hierarchy level. 102 3. Forwarding node behavior 104 The forwarding node has up to 16 downlink ports and at least 105 one uplink port. Typically, the forwarding nodes are arranged 106 in a regular tree structure with one top node, up to 16 nodes 107 in the second hierarchy, up to 256 nodes in the third hierarchy 108 and so on for up to 16-n hierarchies. 110 A forwarding node must be configured to operate at a certain 111 position in the hierarchical network. For example, at third 112 hierarchy level, branch 4 of the first hierarchy and branch 12 113 of the second hierarchy. 115 The behavior of each forwarding node is depending on the 116 position of a node in a hierarchical network. For all 117 positions, the first step is to check the escape prefix. Only 118 packets with matching escape prefix are forwarded. 120 The top forwarding node with the highest hierarchy level 121 evaluates the first 4-bit field following the n x 4-bit escape 122 prefix. The value of the evaluation field determines the 123 output port of the packet. The remaining fields are don't 124 care: 126 | escape prefix | 4-bit | (16-n-1) x 4-bit | 127 < mandatory > < don't care > 129 A forwarding node in a lower hierarchy first checks if the 4- 130 bit fields preceding the evaluation field match the configured 131 value. In case of match the value of the configured evaluation 132 field of the packet is used as downlink port number where the 133 packet is forwarded. The remaining 4-bit fields are ignored. 134 In case of mismatch the packet is forwarded to the uplink 135 port(s). 137 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 138 < mandatory > < match > < don't care > 140 The parameter m indicates the hierarchy level with m=0 141 denoting the highest hierarchy. 143 Hence, when a packet enters a hierarchical network at the 144 lowest layer node it is forwarded in uplink direction until it 145 reaches a node where the m x 4-bit prefix matches the 146 configured value of the node. At latest, the highest-level 147 node will always match and forward the packet in the desired 148 downlink direction. 150 4. Numerical values 152 As mentioned, one pre-requisite of the simple forwarding 153 concept is to keep the complexity of the forwarding nodes low. 154 Also, the configuration of the nodes should be kept simple. In 155 particular industrial networks are operated by persons who are 156 not experts in communication. Configurations should be 157 intuitively understandable by all without long explication. 158 Therefore, for the first experimental forwarding node the 159 number of downlink ports is limited to 10 with numbers 0...9. 16 160 digits at the front panel of the forwarding device show the 161 configuration. Use of classical 7-segment digits make the 162 limits of the configuration obvious. 164 As escape code, the first two digits are fixed to the value 165 "AF" (binary '10101111'). These two characters contrast with 166 the following numerical digits, so that the escape code can be 167 clearly differentiated from the following configuration. The 168 display uses the 'H' character instead of the 'X' the usual 169 term for the variable. 171 The H specifies the digit of the packet prefix which is 172 evaluated for forwarding. When the H is selected all lower 173 digits are automatically set to '-' to indicate the don't care 174 nature. 176 To make the configuration still more obvious it is recommended 177 to configure the local telephone number. With that measure, 178 every local experimentation has unique numbers and can 179 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 180 with other experimental setups. 182 The length of 14 digits allows sufficient in-house 183 hierarchies, even for industrial applications where forwarding 184 nodes interconnect large numbers of sensor controllers. 185 Inhouse installations would be structured for example in 186 building, floor, fabrication unit, machine - with one sensor 187 controller per machine. For the sake of simplicity numbers are 188 deliberately wasted, for example if the building has only 3 189 stories the digits 4...9 are unused. 191 5. Example configuration 193 A small office in Munich with the telephone number +49-89- 194 45241990 configures its local top-level forwarding node to: 196 AF49.8945.2419.90H- 198 Note that for the sake of simplicity this simplified notation 199 is introduced here as alternative to the usual notation 200 AF49:8945:2419:9000/56. With the new notation, the cabling 201 staff people can immediately check the hierarchy location of 202 the forwarding node and connect the cables to the floors at 203 ports 0...3. 205 The next hierarchy level is related to the floor. In case of a 206 3-story building only three next level forwarding nodes are 207 used with these configured values: 209 AF49.8945.2419.900H at the ground level 210 AF49.8945.2419.901H at the first floor 211 AF49.8945.2419.902H at the second floor 212 AF49.8945.2419.903H at the third floor. 214 In each floor, up to 10 sensor nodes can be connected. 215 Each of the sensor nodes can address several sensors/ 216 actuators addressed via the interface identifier contained in 217 the second part of the 128-bit IPv6 address. 219 In the following a connection between sensors in this office to 220 otherIoT equipment located in Essex University is described. The 221 connection is realized with one additional forwarding node 222 installed at Essex University premises with the second level address 224 AF4H.----.----.----. 226 This high level forwarding node can be used although the phone number 227 of the researcher is +44 1206 872413, as long as there is no further 228 node in UK. 230 At downlink port 9 the 13th level forwarding node in Munich is con- 231 nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. 232 The levels in between must not be populated by forwarding nodes as 234 long as no other branch is needed at one of the two sides. 235 If for example another site in Munich center must be connected one 236 additional forwarding node must be installed with the 5th level 237 address 239 AF49.89H-.----.----. 241 The small office mentioned above would be connected to downlink port 242 4 while the new site would be connected at downlink port 1, the 243 prefix for Munich center. The configuration is visualized in the 244 Figure below. 246 Essex (UK) Munich (DE) 248 |---------U-----------| 249 | AF4H.----.----.---- | 250 |-0-1-2-3-4-5-6-7-8-9-| 251 | \ 252 | ------ L2 Link ------ 253 |----------| \ 254 | IoT node | |----------U----------| 255 |----------| | AF49.89H-.----.---- | 256 |-0-1-2-3-4-5-6-7-8-9-| 257 / \ 258 --- ----------- 259 / \ 260 |----------U----------| |----------U----------| 261 | AF49.89H-.----.---- | | AF49.8945.2419.90H- | 262 |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| 263 | 264 |----------U----------| 265 | AF49.8945.5419.901H | 266 |-0-1-2-3-4-5-6-7-8-9-| 267 U = Uplink | 268 |----------| 269 | IoT node | 270 |----------| 271 Figure: Example Configuration 272 6. Security Considerations 274 In a hierarchical network as described above every forwarding node 275 can easily check a part of the source address of the packets. For 276 example, the IoT node in the above Figure will get the following 277 address assigned: AF49.8945.5419.9014. It will use this address as 278 source address when it sends packets in upstream direction. The node 279 above receives the packets at port 4 and expects that the digit at 280 the position of the 'H' will be a 4. 282 Moreover, a node in upstream direction will check if the prefix of 283 the packet's source address. For example the top Munich node in the 284 above figure will check the source address of packets received from 285 downlinks to be AF49.89. 287 Hence, the source addresses of all packets forwarded in upstream 288 direction will be checked repeatedly all the way up in the hierarchy. 289 In case of mismatch, either an error has occurred or an intentional 291 address falsification. Both cases should be avoided and therefore 292 such packets are discarded. 294 In consequence, a receiver in the hierarchical forwarding network can 295 rely on the correctness of the source addresses of the received 296 packets. This feature is ideal for white-listing, which in turn is 297 ideal for IoT applications. Other than in the 'normal' Internet 298 access to IoT devices is not needed for every host. In contrary, IoT 299 devices will have restricted access for authorized hosts only. 301 Note that the verified source address feature is orthogonal to other 302 security measures such as password authentication and encryption. 304 7. Redundancy 306 The hierarchical structure implied by the addressing leads to the fact 307 that node failures have more implications the higher the hierarchy of 308 a node. Therefore, a node should be equipped with two redundant uplink 309 ports. Each of them is connected to a next higher hierarchy node, each 310 of them having again two redundant uplinks. 312 Hence, with each hierarchy the number of uplinks doubles - and also 313 the number of nodes. In the case of ten downlinks and two uplinks the 314 number of nodes grows with the power of two and the number of 315 terminals grows with the power of ten. 317 A three-dimensional network is constructed with up to n hierarchies 318 and up to 2^n redundancy planes. With 14 hierarchies the number of 319 redundancy planes becomes 16384. This number of top hierarchy nodes 320 sounds very high, but distributed around the world would lead to well- 321 balanced redundancy. 323 With the two uplinks (could also be more) a routing feature emerges in 324 the network. In other words, each node has to take a routing decision 325 in upstream direction, when forwarding packets to one the uplinks. 326 This decision could be based on node-local information (autarkic) or 327 based on routing protocols. This topic is for further study. 329 8. IANA Considerations 331 In Q1/2020 a local field trial with ultra-low latency routing is plan- 332 ned in Germany. A temporary /16 prefix "AF49" will be requested from 333 IANA for that. In Q3/2020 a field trial with several European 334 countries is planned. The other countries will apply for "AF33", 335 "AF44" etc. for France, UK etc., respectively. 337 9. Acknowledgements 339 The authors would like to thank the consortium of the European 340 research project CHARISMA for the possibility to experiment. The 341 description of the final demonstration is available for download: 342 http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst 343 rators-Evaluation-and-Validation-vFinal.pdf 345 10. Authors' Addresses 347 Andreas Foglar 348 InnoRoute GmbH 349 Marsstr. 14a 350 80335 Munich 351 Germany 352 Email: foglar@innoroute.de 354 Mike Parker 355 Wivenhoe Park, Colchester 356 Essex, CO3 4HG 357 United Kingdom 358 Email: mcpark@essex.ac.uk 360 Theodoros Rokkas 361 Incites S.A.R.L. 362 130, Route d' Arlon 363 Strassen L-8008 364 Luxembourg 365 Email: trokkas@incites.eu 367 Foglar, Parker, Rokkas Expires July 20, 2020