idnits 2.17.1 draft-foglar-ipv6-ull-routing-07.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 411 lines 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 (July 24, 2020) is 1371 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 13, 2021 July 24, 2020 6 IPv6 Source Routing for ultralow Latency 7 draft-foglar-ipv6-ull-routing-07 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 Revision Note for Version 05 64 Section 8 about IANA Considerations added. 66 Revision Note for Version 06 68 Section 8 about IANA Considerations updated. 70 Revision Note for Version 07 72 Section 6 about Security Considerations improved. 74 1. Introduction 76 To achieve minimum latency the forwarding nodes must support 77 cut-through technology as opposed to the commonly used store- 78 and-forward technology. Cut-through means, that the packet 79 header already leaves a node at the egress port while the tail 80 of the packet is still received at the ingress port. This 81 short time does not allow complex routing decisions. 83 Therefore, a very simple routing address field structure is 84 specified below. It should limit the complexity of the 85 forwarding node used in the experiments. Therefore, in this 86 text the term "forwarding node" is used instead of "router", 87 although the device is operating in OSI Layer 3 and accordingly 88 executes router functions such as decrementing the hop limit field. 89 Redundancy issues are not considered. 91 2. IPv6 address prefix structure 93 The following proposal uses the 64-bit IPv6 address prefix. 95 Each forwarding node has up to 16 ports and hence needs 4 bits 96 of the address field to decide to which port a packet should 97 be forwarded. The 64-bit prefix is divided into 16 sub-fields 98 of 4 bit, defining up to 16 hierarchy levels. A forwarding 99 node is configured manually to which of the sub-fields it should 100 evaluate for the forwarding decision. 102 A number n of leading 4-bit fields cannot be used for forwarding 103 decisions, but must have a special value to indicate the 104 'escape prefix' of the experimental forwarding mode. 106 The 64-bit prefix of the IPv6 address has this structure: 108 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 110 The first 4-bit field following the escape prefix has the 111 highest hierarchy level, the last 4-bit field has the lowest 112 hierarchy level. 114 3. Forwarding node behavior 116 The forwarding node has up to 16 downlink ports and at least 117 one uplink port. Typically, the forwarding nodes are arranged 118 in a regular tree structure with one top node, up to 16 nodes 119 in the second hierarchy, up to 256 nodes in the third hierarchy 120 and so on for up to 16-n hierarchies. 122 A forwarding node must be configured to operate at a certain 123 position in the hierarchical network. For example, at third 124 hierarchy level, branch 4 of the first hierarchy and branch 12 125 of the second hierarchy. 127 The behavior of each forwarding node is depending on the 128 position of a node in a hierarchical network. For all 129 positions, the first step is to check the escape prefix. Only 130 packets with matching escape prefix are forwarded. 132 The top forwarding node with the highest hierarchy level 133 evaluates the first 4-bit field following the n x 4-bit escape 134 prefix. The value of the evaluation field determines the 135 output port of the packet. The remaining fields are don't 136 care: 138 | escape prefix | 4-bit | (16-n-1) x 4-bit | 139 < mandatory > < don't care > 141 A forwarding node in a lower hierarchy first checks if the 4- 142 bit fields preceding the evaluation field match the configured 143 value. In case of match the value of the configured evaluation 144 field of the packet is used as downlink port number where the 145 packet is forwarded. The remaining 4-bit fields are ignored. 146 In case of mismatch the packet is forwarded to the uplink 147 port(s). 149 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 150 < mandatory > < match > < don't care > 152 The parameter m indicates the hierarchy level with m=0 153 denoting the highest hierarchy. 155 Hence, when a packet enters a hierarchical network at the 156 lowest layer node it is forwarded in uplink direction until it 157 reaches a node where the m x 4-bit prefix matches the 158 configured value of the node. At latest, the highest-level 159 node will always match and forward the packet in the desired 160 downlink direction. 162 4. Numerical values 164 As mentioned, one pre-requisite of the simple forwarding 165 concept is to keep the complexity of the forwarding nodes low. 166 Also, the configuration of the nodes should be kept simple. In 167 particular industrial networks are operated by persons who are 168 not experts in communication. Configurations should be 169 intuitively understandable by all without long explication. 170 Therefore, for the first experimental forwarding node the 171 number of downlink ports is limited to 10 with numbers 0...9. 16 172 digits at the front panel of the forwarding device show the 173 configuration. Use of classical 7-segment digits make the 174 limits of the configuration obvious. 176 As escape code, the first two digits are fixed to the value 177 "AF" (binary '10101111'). These two characters contrast with 178 the following numerical digits, so that the escape code can be 179 clearly differentiated from the following configuration. The 180 display uses the 'H' character instead of the 'X' the usual 181 term for the variable. 183 The H specifies the digit of the packet prefix which is 184 evaluated for forwarding. When the H is selected all lower 185 digits are automatically set to '-' to indicate the don't care 186 nature. 188 To make the configuration still more obvious it is recommended 189 to configure the local telephone number. With that measure, 190 every local experimentation has unique numbers and can 191 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 192 with other experimental setups. 194 The length of 14 digits allows sufficient in-house 195 hierarchies, even for industrial applications where forwarding 196 nodes interconnect large numbers of sensor controllers. 197 Inhouse installations would be structured for example in 198 building, floor, fabrication unit, machine - with one sensor 199 controller per machine. For the sake of simplicity numbers are 200 deliberately wasted, for example if the building has only 3 201 stories the digits 4...9 are unused. 203 5. Example configuration 205 A small office in Munich with the telephone number +49-89- 206 45241990 configures its local top-level forwarding node to: 208 AF49.8945.2419.90H- 210 Note that for the sake of simplicity this simplified notation 211 is introduced here as alternative to the usual notation 212 AF49:8945:2419:90:0/56. With the new notation, the cabling 213 staff people can immediately check the hierarchy location of 214 the forwarding node and connect the cables to the floors at 215 ports 0...3. 217 The next hierarchy level is related to the floor. In case of a 218 3-story building only three next level forwarding nodes are 219 used with these configured values: 221 AF49.8945.2419.900H at the ground level 222 AF49.8945.2419.901H at the first floor 223 AF49.8945.2419.902H at the second floor 224 AF49.8945.2419.903H at the third floor. 226 In each floor, up to 10 sensor nodes can be connected. 227 Each of the sensor nodes can address several sensors/ 228 actuators addressed via the interface identifier contained in 229 the second part of the 128-bit IPv6 address. 231 In the following a connection between sensors in this office to 232 other IoT equipment located in Essex University is described. The 233 connection is realized with one additional forwarding node 234 installed at Essex University premises with the second level address 236 AF4H.----.----.----. 238 This high level forwarding node can be used although the phone number 239 of the researcher is +44 1206 872413, as long as there is no further 240 node in UK. 242 At downlink port 9 the 13th level forwarding node in Munich is con- 243 nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. 244 The levels in between must not be populated by forwarding nodes as 246 long as no other branch is needed at one of the two sides. 247 If for example another site in Munich center must be connected one 248 additional forwarding node must be installed with the 5th level 249 address 251 AF49.89H-.----.----. 253 The small office mentioned above would be connected to downlink port 254 4 while the new site would be connected at downlink port 1, the 255 prefix for Munich center. The configuration is visualized in the 256 Figure below. 258 Essex (UK) Munich (DE) 260 |---------U-----------| 261 | AF4H.----.----.---- | 262 |-0-1-2-3-4-5-6-7-8-9-| 263 | \ 264 | ------ L2 Link ------ 265 |----------| \ 266 | IoT node | |----------U----------| 267 |----------| | AF49.89H-.----.---- | 268 |-0-1-2-3-4-5-6-7-8-9-| 269 / \ 270 --- ----------- 271 / \ 272 |----------U----------| |----------U----------| 273 | AF49.891H.----.---- | | AF49.8945.2419.90H- | 274 |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| 275 | 276 |----------U----------| 277 | AF49.8945.5419.901H | 278 |-0-1-2-3-4-5-6-7-8-9-| 279 U = Uplink | 280 |----------| 281 | IoT node | 282 |----------| 283 Figure: Example Configuration with Node Addresses 285 6. Security Considerations 287 In a hierarchical network as described above every forwarding node 288 can easily check a part of the source address of the packets. Packets 289 received from lower hierarchy must have a source address from that 290 hierarchy branch. A node checks this by comparing the prefix of the 291 source address with its own node address and in addition checks if 292 the lower hierarchy digit matches the number of the receiving port. In 293 case of mismatch of any comparison a packet is discarded silently. 295 The term 'silently' means that no further action is taken. In other 296 cases, for example when a packet is sent to a non-existing destination 297 the packet could be discarded with a notification of the sender. This 298 issue is for further study. 300 For example, the node AF49.89H-.----.---- in the Figure above expects 301 that packets received from dowlink 1 have source addresses 302 AF49.891x.xxxx.xxxx with x in the range 0...9. To that aim the node 303 checks if the leading digits of the packet source address match with 304 AF49.89 and if the digit at the 'H' position matches with the 305 receiving dowlink port number. 307 The lower the hierarchy level of a node the more digits are checked. 308 In particular, the lowest hierarchy node checkes the complete prefix. 310 For example, the Munich IoT node in the Figure above must send packets 311 with the source address AF49.8945.5419.9014 to the higher level node. 312 It will discard packets with any other source address. 314 Hence in upstream direction every higher level node will check a 315 shorter part of the prefix. At the highest level the node 316 AFH-.----.----.---- will check if the source address digit at the 'H' 317 position matches with the receiving downlink port number. 319 As packets with non-matching source address are discarded a receiver 320 can rely on the correctness of the source adress. This feature 321 provides an orthogonal level of security to existing security measures 322 such as password authentication and encryption. Anonymous hackers are 323 not possible in such hierarchical networks. Receivers may use white- 324 listing for address filtering. 326 To circumvent the source address check a hacker must break into the 327 network and insert packets in downstream direction. At the highest 328 level node the network is most vulnerable, as any address can be rea- 329 ched from there. However, the higher a network node level the more 330 sophisticated are the security means to avoid intrusion. 332 At lower level nodes an additional source address check in downstream 333 direction may be implemented: at the uplink ports packets with source 334 address from the own hierarchy branch are not expected. These packets 335 should have been forwarded within the hierarchy branch. At the uplink 336 ports these packets are discarded silently. 338 For example the node AF49.89H-.----.---- in the Figure above would not 339 expect a packet with the source address AF49.8945.5419.9014 at an 340 uplink port. Hence this packet will be discarded. 342 7. Redundancy 344 The hierarchical structure implied by the addressing leads to the fact 345 that node failures have more implications the higher the hierarchy of 346 a node. Therefore, a node should be equipped with two redundant uplink 347 ports. Each of them is connected to a next higher hierarchy node, each 348 of them having again two redundant uplinks. 350 Hence, with each hierarchy the number of uplinks doubles - and also 351 the number of nodes. In the case of ten downlinks and two uplinks the 352 number of nodes grows with the power of two and the number of 353 terminals grows with the power of ten. 355 A three-dimensional network is constructed with up to n hierarchies 356 and up to 2^n redundancy planes. With 14 hierarchies the number of 357 redundancy planes becomes 16384. This number of top hierarchy nodes 358 sounds very high, but distributed around the world would lead to well- 359 balanced redundancy. 361 With the two uplinks (could also be more) a routing feature emerges in 362 the network. In other words, each node has to take a routing decision 363 in upstream direction, when forwarding packets to one the uplinks. 364 This decision could be based on node-local information (autarkic) or 365 based on routing protocols. This topic is for further study. 367 8. IANA Considerations 369 In Q1/2020 a local field trial with ultra-low latency routing is plan- 370 ned in Germany. A temporary /16 prefix "AF49" will be requested from 371 IANA for that. In Q3/2020 a field trial with several European 372 countries is planned. The other countries will apply for "AF33", 373 "AF44" etc. for France, UK etc., respectively. 375 9. Acknowledgements 377 The authors would like to thank the consortium of the European 378 research project CHARISMA for the possibility to experiment. The 379 description of the final demonstration is available for download: 380 http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst 381 rators-Evaluation-and-Validation-vFinal.pdf 383 10. Authors' Addresses 385 Andreas Foglar 386 InnoRoute GmbH 387 Marsstr. 14a 388 80335 Munich 389 Germany 390 Email: foglar@innoroute.de 392 Mike Parker 393 Wivenhoe Park, Colchester 394 Essex, CO3 4HG 395 United Kingdom 396 Email: mcpark@essex.ac.uk 398 Theodoros Rokkas 399 Incites S.A.R.L. 400 130, Route d' Arlon 401 Strassen L-8008 402 Luxembourg 403 Email: trokkas@incites.eu 405 Foglar, Parker, Rokkas Expires January 13, 2021