idnits 2.17.1 draft-foglar-ipv6-ull-routing-09.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 a Security Considerations section. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 01, 2021) is 1059 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 M. Khokhlov, IP Tek 5 Expires: November 30, 2021 June 01, 2021 7 IPv6 Source Routing for ultralow Latency 8 draft-foglar-ipv6-ull-routing-09 10 Abstract 12 This Internet-Draft describes a hierarchical addressing scheme 13 for IPv6, intentionally very much simplified to allow for ultralow 14 latency source routing experimentation using simple forwarding 15 nodes. Research groups evaluate achievable latency reduction for 16 special applications such as radio access networks, industrial net- 17 works or other networks requiring very low 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 Section 7 about Redundancy has been inserted. 60 Revision Note for Version 05 62 Section 8 about IANA Considerations added. 64 Revision Note for Version 06 66 Section 8 about IANA Considerations updated. 68 Revision Note for Version 07 70 Section 6 about Security Considerations improved. 72 Revision Note for Version 08 74 Soome typos corrected 76 Revision Note for Version 09 78 Improved address generation and ITU-T section added at the end of the 79 document. An additional author is added. 81 1. Introduction 83 To achieve minimum latency the forwarding nodes must support 84 cut-through technology as opposed to the commonly used store- 85 and-forward technology. Cut-through means, that the packet 86 header already leaves a node at the egress port while the tail 87 of the packet is still received at the ingress port. This 88 short time does not allow complex routing decisions. 90 Therefore, a very simple routing address field structure is 91 specified below. It should limit the complexity of the 92 forwarding node used in the experiments. Therefore, in this 93 text the term "forwarding node" is used instead of "router", 94 although the device is operating in OSI Layer 3 and accordingly 95 executes router functions such as decrementing the hop limit field. 97 2. IPv6 address prefix structure 98 The following proposal uses the 64-bit IPv6 address prefix. 100 Each forwarding node has up to 16 ports and hence needs 4 bits 101 of the address field to decide to which port a packet should 102 be forwarded. The 64-bit prefix is divided into 16 sub-fields 103 of 4 bit, defining up to 16 hierarchy levels. A forwarding 104 node is configured manually to which of the sub-fields it should 105 evaluate for the forwarding decision. 107 A number n of leading 4-bit fields cannot be used for forwarding 108 decisions, but must have a special value to indicate the 109 'escape prefix' of the experimental forwarding mode. 111 The 64-bit prefix of the IPv6 address has this structure: 112 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 113 highest hierarchy level, the last 4-bit field has the lowest 114 hierarchy level. 116 3. Forwarding node behavior 118 The forwarding node has up to 16 downlink ports and at least 119 one uplink port. Typically, the forwarding nodes are arranged 120 in a regular tree structure with one top node, up to 16 nodes 121 in the second hierarchy, up to 256 nodes in the third hierarchy 122 and so on for up to 16-n hierarchies. 124 A forwarding node must be configured to operate at a certain 125 position in the hierarchical network. For example, at third 126 hierarchy level, branch 4 of the first hierarchy and branch 12 127 of the second hierarchy. 129 The behavior of each forwarding node is depending on the 130 position of a node in a hierarchical network. For all 131 positions, the first step is to check the escape prefix. Only 132 packets with matching escape prefix are forwarded. 134 The top forwarding node with the highest hierarchy level 135 evaluates the first 4-bit field following the n x 4-bit escape 136 prefix. The value of the evaluation field determines the 137 output port of the packet. The remaining fields are don't 138 care: 140 | escape prefix | 4-bit | (16-n-1) x 4-bit | 141 < mandatory > < don't care > 143 A forwarding node in a lower hierarchy first checks if the 4- 144 bit fields preceding the evaluation field match the configured 145 value. In case of match the value of the configured evaluation 146 field of the packet is used as downlink port number where the 147 packet is forwarded. The remaining 4-bit fields are ignored. 148 In case of mismatch the packet is forwarded to the uplink 149 port(s). 151 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 152 < mandatory > < match > < don't care > 154 The parameter m indicates the hierarchy level with m=0 155 denoting the highest hierarchy. 157 Hence, when a packet enters a hierarchical network at the 158 lowest layer node it is forwarded in uplink direction until it 159 reaches a node where the m x 4-bit prefix matches the 160 configured value of the node. At latest, the highest-level 161 node will always match and forward the packet in the desired 162 downlink direction. 164 4. Numerical values 166 As mentioned, one pre-requisite of the simple forwarding 167 concept is to keep the complexity of the forwarding nodes low. 168 Also, the configuration of the nodes should be kept simple. In 169 not experts in communication. Configurations should be 170 intuitively understandable by all without long explication. 171 Therefore, for the first experimental forwarding node the 172 number of downlink ports is limited to 10 with numbers 0...9. 16 173 digits at the front panel of the forwarding device show the 174 configuration. Use of classical 7-segment digits make the 175 limits of the configuration obvious. 177 As escape code, the first two digits are fixed to the value 178 "AF" (binary '10101111'). These two characters contrast with 179 the following numerical digits, so that the escape code can be 180 clearly differentiated from the following configuration. The 181 display uses the 'H' character instead of the 'X' the usual 182 term for a variable. It can be interpreted as 'hierarchy'. 184 The H specifies the digit of the packet prefix which is 185 evaluated for forwarding. When the H is selected all lower 186 digits are automatically set to '-' to indicate the don't care 187 nature. 189 To make the configuration still more obvious it is recommended 190 to configure the local telephone number. With that measure, 191 every local experimentation has unique numbers and can 192 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 193 with other experimental setups. 195 The length of 14 digits allows sufficient in-house 196 hierarchies, even for industrial applications where forwarding 197 nodes interconnect large numbers of sensor controllers. 198 Inhouse installations would be structured for example in 199 building, floor, fabrication unit, machine - with one sensor 200 controller per machine. For the sake of simplicity numbers are 201 deliberately wasted, for example if the building has only 3 202 stories the digits 4...9 are unused. 204 5. Example configuration 206 A company office in Munich with the telephone number +49-89- 207 45241990 configures its local top-level forwarding node to: 209 AF49.8945.2419.90H- 211 Note that for the sake of simplicity this simplified notation 212 is introduced here as alternative to the usual notation 213 AF49:8945:2419:90:0/56. With the new notation, the cabling 214 staff people can immediately check the hierarchy location of 215 the forwarding node and connect the cables to the floors at 216 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 Each of the sensor nodes can address several sensors/ 227 actuators addressed via the interface identifier contained in 228 the second part of the 128-bit IPv6 address. 230 In the following a connection between sensors in this office to 231 other IoT equipment located in Essex University is described. The 232 connection is realized with one additional forwarding node 233 installed at Essex University premises with the second level address 235 AF4H.----.----.----. 237 This high level forwarding node can be used although the phone number 238 of the researcher is +44 1206 872413, as long as there is no further 239 node in UK. 241 At downlink port 9 the 13th level forwarding node in Munich is con- 242 nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. 243 The levels in between must not be populated by forwarding nodes as 244 long as no other branch is needed at one of the two sides. If for 245 example another site in Munich center must be connected one additio- 246 nal forwarding node must be installed with the 5th level address 248 AF49.89H-.----.----. 250 The small office mentioned above would be connected to downlink port 251 4 while the new site would be connected at downlink port 1, the 252 prefix for Munich center. The configuration is visualized in the 253 Figure below. 255 Essex (UK) Munich (DE) 257 |---------U-----------| 258 | AF4H.----.----.---- | 259 |-0-1-2-3-4-5-6-7-8-9-| 260 | \ 261 | ------ L2 Link ------ 262 |----------| \ 263 | IoT node | |----------U----------| 264 |----------| | AF49.89H-.----.---- | 265 |-0-1-2-3-4-5-6-7-8-9-| 266 / \ 267 --- ----------- 268 / \ 269 |----------U----------| |----------U----------| 270 | AF49.891H.----.---- | | AF49.8945.2419.90H- | 271 |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| 272 | 273 |----------U----------| 274 | AF49.8945.5419.901H | 275 |-0-1-2-3-4-5-6-7-8-9-| 276 U = Uplink | 277 |----------| 278 | IoT node | 279 |----------| 280 Figure: Example Configuration with Node Addresses 281 In a hierarchical network as described above every forwarding node 282 can easily check a part of the source address of the packets. Packets 283 received from lower hierarchy must have a source address from that 284 hierarchy branch. A node checks this by comparing the prefix of the 285 source address with its own node address and in addition checks if 286 the lower hierarchy digit matches the number of the receiving port. In 287 case of mismatch of any comparison a packet is discarded silently. 289 The term 'silently' means that no further action is taken. In other 290 cases, for example when a packet is sent to a non-existing destination 291 the packet could be discarded with a notification of the sender. This 292 issue is for further study. 294 For example, the node AF49.89H-.----.---- in the Figure above expects 295 that packets received from dowlink 1 have source addresses 296 AF49.891x.xxxx.xxxx with x is don't care. To that aim the node checks 297 if the leading digits of the packet source address match with AF49.89 298 and if the digit at the 'H' position matches with the receiving down- 299 link port number. 301 The lower the hierarchy level of a node the more digits are checked. 302 In particular, the lowest hierarchy node checkes the complete prefix. 304 For example, the Munich IoT node in the Figure above must send packets 305 with the source address AF49.8945.5419.9014 to the higher level node. 306 It will discard packets with any other source address. 308 Hence in upstream direction every higher level node will check a 309 shorter part of the prefix. At the highest level the node 310 AFH-.----.----.---- will check if the source address digit at the 'H' 311 position matches with the receiving downlink port number. 313 As packets with non-matching source address are discarded a receiver 314 can rely on the correctness of the source adress. This feature pro- 315 vides an orthogonal level of security to existing security measures 316 such as password authentication and encryption. Anonymous hackers are 317 not possible in such hierarchical networks. Receivers may use white- 318 listing for address filtering. 320 To circumvent the source address check a hacker must break into the 321 network and insert packets in downstream direction. At the highest 322 level node the network is most vulnerable, as any address can be rea- 323 ched from there. However, the higher a network node level the more 324 sophisticated are the security means to avoid intrusion. 326 At lower level nodes an additional source address check in downstream 327 direction may be implemented: at the uplink ports packets with source 328 address from the own hierarchy branch are not expected. These packets 329 should have been forwarded within the hierarchy branch. At the uplink 330 ports these packets are discarded silently. 332 For example the node AF49.89H-.----.---- in the Figure above would not 333 expect a packet with the source address AF49.8945.5419.9014 at an 334 uplink port. Hence this packet will be discarded. 336 The hierarchical structure implied by the addressing leads to the fact 337 that node failures have more implications the higher the hierarchy of 338 a node. Therefore, a node should be equipped with at least two redun- 339 dant uplink ports. Each of them is connected to a next higher hierar- 340 chy node, each of them having again at least two redundant uplinks. 342 In the case of nodes with ten downlinks and two uplinks the number of 343 nodes grows with the power of two and the number of terminals grows 344 with the power of ten. A three-dimensional network is constructed 345 with up to n hierarchies and up to 2^n redundancy planes. With 14 346 hierarchies the number of redundancy planes becomes 16384. This number 347 of top hierarchy nodes sounds very high, but distributed around the 348 world would lead to well-balanced redundancy. 350 With two or more uplinks a routing feature emerges in the network. In 351 other words, each node has to take a routing decision in upstream di- 352 rection, when forwarding packets to one the uplinks. This decision 353 should be based on node-local information (autarkic) to avoid routing 354 protocols. One option is learning prefixes from packets received in 355 downstream direction. 357 8. IANA Considerations 359 In Q2/2021 a local field trial with ultra-low latency routing starts 360 in Germany. A temporary /16 prefix "AF49" will be requested from the 361 national registry or RIR. Later, extension of the field trial to other 362 countries is planned. The other countries will apply for "AF33" for 363 France, "AF44" for UK, "AF43" for Austria and so on. 365 9. Numbering Considerations 367 The international telephone number format and the country prefixes are 368 standardized by Study Group 2 of ITU-T in the Recommendation E.164. 369 This numbering, however, specifies several exceptions such as 800 or 370 900 special calling codes. The numbering used for ultra-low according 371 to this document shall have no exception at all. Hence, in future the 372 Study Group 2 could open a new Recommendation. 374 When mapping a telephone number to IPv6 prefix one problem is the dif- 375 ferent length of numbers. At the one side, telephone numbers according 376 to E.164 can have up to 15 digits and would not fit into the remaining 377 14 digits in case of a 2-digit escape prefix. A future ITU-T numbering 378 recommendation could deal with that problem. At the other side, some 379 private phone numbers are very short. For example, the city of Munich 380 has numbers as short as +49-89-886757. Still, the private subscriber 381 would get a /64 prefix. To solve this problem the solution is to fill 382 the remaining part of the IPv6 prefix with 'F' digits: 384 AF49:8988:6757:FFFF::/64 386 This rule has the advantage that the reverse process of converting an 387 IPv6 prefix back to a telephone number always works. 389 The authors would like to thank the consortium of the European 390 research project CHARISMA for the possibility to experiment. The 391 description of the final demonstration is available for download: 392 http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst 393 rators-Evaluation-and-Validation-vFinal.pdf 394 11. Authors' Addresses 396 Andreas Foglar 397 InnoRoute GmbH 398 Marsstr. 14a 399 80335 Munich 400 Germany 401 Email: foglar@innoroute.de 403 Mike Parker 404 Wivenhoe Park, Colchester 405 Essex, CO3 4HG 406 United Kingdom 407 Email: mcpark@essex.ac.uk 409 Theodoros Rokkas 410 Incites S.A.R.L. 411 130, Route d' Arlon 412 Strassen L-8008 413 Luxembourg 414 Email: trokkas@incites.eu 416 Mikhail Khokhlov 417 IP Tek UG 418 Dircksenstr. 50 419 10178 Berlin 420 Germany 421 Email: info@ip-tek.net 423 Foglar, Parker, Rokkas, Khokhlov Expires November 20, 2021