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