idnits 2.17.1 draft-foglar-ipv6-ull-routing-02.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 4 longer pages, 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. ** 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 (March 2, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 3 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: September 1, 2018 March 2, 2018 6 IPv6 Source Routing for ultralow Latency 7 draft-foglar-ipv6-ull-routing-02 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) 2017 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 1. Introduction 56 To achieve minimum latency the forwarding nodes must support 57 cut-through technology as opposed to the commonly used store- 58 and-forward technology. Cut-through means, that the packet 59 header already leaves a node at the egress port while the tail 60 of the packet is still received at the ingress port. This 61 short time does not allow complex routing decisions. 63 Therefore, a very simple routing address field structure is 64 specified below. It should limit the complexity of the 65 forwarding node used in the experiments. Therefore, in this 66 text the term "forwarding node" is used instead of "router", 67 although the device is operating in OSI Layer 3 and accordingly 68 executes router functions such as decrementing the hop limit field. 69 Redundancy issues are not considered. 71 2. IPv6 address prefix structure 73 The following proposal uses the 64-bit IPv6 address prefix. 75 Each forwarding node has up to 16 ports and hence needs 4 bits 76 of the address field to decide to which port a packet should 77 be forwarded. The 64-bit prefix is divided into 16 sub-fields 78 of 4 bit, defining up to 16 hierarchy levels. A forwarding 79 node is configured manually to which of the sub-fields it should 80 evaluate for the forwarding decision. 82 A number n of leading 4-bit fields cannot be used for forwarding 83 decisions, but must have a special value to indicate the 84 'escape prefix' of the experimental forwarding mode. 86 The 64-bit prefix of the IPv6 address has this structure: 88 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 90 The first 4-bit field following the escape prefix has the 91 highest hierarchy level, the last 4-bit field has the lowest 92 hierarchy level. 94 3. Forwarding node behavior 96 The forwarding node has up to 16 downlink ports and at least 97 one uplink port. Typically, the forwarding nodes are arranged 98 in a regular tree structure with one top node, up to 16 nodes 99 in the second hierarchy, up to 256 nodes in the third hierarchy 100 and so on for up to 16-n hierarchies. 102 A forwarding node must be configured to operate at a certain 103 position in the hierarchical network. For example, at third 104 hierarchy level, branch 4 of the first hierarchy and branch 12 105 of the second hierarchy. 107 The behavior of each forwarding node is depending on the 108 position of a node in a hierarchical network. For all 109 positions, the first step is to check the escape prefix. Only 110 packets with matching escape prefix are forwarded. 112 The top forwarding node with the highest hierarchy level 113 evaluates the first 4-bit field following the n x 4-bit escape 114 prefix. The value of the evaluation field determines the 115 output port of the packet. The remaining fields are don't 116 care: 118 | escape prefix | 4-bit | (16-n-1) x 4-bit | 119 < mandatory > < don't care > 121 A forwarding node in a lower hierarchy first checks if the 4- 122 bit fields preceding the evaluation field match the configured 123 value. In case of match the value of the configured evaluation 124 field of the packet is used as downlink port number where the 125 packet is forwarded. The remaining 4-bit fields are ignored. 126 In case of mismatch the packet is forwarded to the uplink 127 port(s). 129 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 130 < mandatory > < match > < don't care > 132 The parameter m indicates the hierarchy level with m=0 133 denoting the highest hierarchy. 135 Hence, when a packet enters a hierarchical network at the 136 lowest layer node it is forwarded in uplink direction until it 137 reaches a node where the m x 4-bit prefix matches the 138 configured value of the node. At latest, the highest-level 139 node will always match and forward the packet in the desired 140 downlink direction. 142 4. Numerical values 144 As mentioned, one pre-requisite of the simple forwarding 145 concept is to keep the complexity of the forwarding nodes low. 146 Also, the configuration of the nodes should be kept simple. In 147 particular industrial networks are operated by persons who are 148 not experts in communication. Configurations should be 149 intuitively understandable by all without long explication. 150 Therefore, for the first experimental forwarding node the 151 number of downlink ports is limited to 10 with numbers 0...9. 16 152 digits at the front panel of the forwarding device show the 153 configuration. Use of classical 7-segment digits make the 154 limits of the configuration obvious. 156 As escape code, the first two digits are fixed to the value 157 "AF" (binary '10101111'). These two characters contrast with 158 the following numerical digits, so that the escape code can be 159 clearly differentiated from the following configuration. The 160 display uses the 'H' character instead of the 'X' the usual 161 term for the variable. 163 The H specifies the digit of the packet prefix which is 164 evaluated for forwarding. When the H is selected all lower 165 digits are automatically set to '-' to indicate the don't care 166 nature. 168 To make the configuration still more obvious it is recommended 169 to configure the local telephone number. With that measure, 170 every local experimentation has unique numbers and can 171 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 172 with other experimental setups. 174 The length of 14 digits allows sufficient in-house 175 hierarchies, even for industrial applications where forwarding 176 nodes interconnect large numbers of sensor controllers. 177 Inhouse installations would be structured for example in 178 building, floor, fabrication unit, machine - with one sensor 179 controller per machine. For the sake of simplicity numbers are 180 deliberately wasted, for example if the building has only 3 181 stories the digits 4...9 are unused. 183 5. Example configuration 185 A small office in Munich with the telephone number +49-89- 186 45241990 configures its local top-level forwarding node to: 188 AF49.8945.2419.90H- 190 Note that for the sake of simplicity this simplified notation 191 is introduced here as alternative to the usual notation 192 AF49:8945:2419:9000/56. With the new notation, the cabling 193 staff people can immediately check the hierarchy location of 194 the forwarding node and connect the cables to the floors at 195 ports 0...3. 197 The next hierarchy level is related to the floor. In case of a 198 3-story building only three next level forwarding nodes are 199 used with these configured values: 201 AF49.8945.2419.900H at the ground level 202 AF49.8945.2419.901H at the first floor 203 AF49.8945.2419.902H at the second floor 204 AF49.8945.2419.903H at the third floor. 206 In each floor, up to 10 sensor nodes can be connected. 207 Each of the sensor nodes can address several sensors/ 208 actuators addressed via the interface identifier contained in 209 the second part of the 128-bit IPv6 address. 211 In the following a connection between sensors in this office to 212 otherIoT equipment located in Essex University is described. The 213 connection is realized with one additional forwarding node 214 installed at Essex University premises with the second level address 216 AF4H.----.----.----. 218 This high level forwarding node can be used although the phone number 219 of the researcher is +44 1206 872413, as long as there is no further 220 node in UK. 222 At downlink port 9 the 13th level forwarding node in Munich is con- 223 nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. 224 The levels in between must not be populated by forwarding nodes as 225 long as no other branch is needed at one of the two sides. 227 If for example another site in Munich center must be connected one 228 additional forwarding node must be installed with the 5th level 229 address 231 AF49.89H-.----.----. 233 The small office mentioned above would be connected to downlink port 234 4 while the new site would be connected at downlink port 1, the 235 prefix for Munich center. The configuration is visualized in the 236 Figure below. 238 Essex (UK) Munich (DE) 240 |---------U-----------| 241 | AF4H.----.----.---- | 242 |-0-1-2-3-4-5-6-7-8-9-| 243 | \ 244 | ------ L2 Link ------ 245 |----------| \ 246 | IoT node | |----------U----------| 247 |----------| | AF49.89H-.----.---- | 248 |-0-1-2-3-4-5-6-7-8-9-| 249 / \ 250 --- ----------- 251 / \ 252 |----------U----------| |----------U----------| 253 | AF49.89H-.----.---- | | AF49.8945.2419.90H- | 254 |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| 255 | 256 |----------U----------| 257 | AF49.8945.5419.901H | 258 |-0-1-2-3-4-5-6-7-8-9-| 259 U = Uplink | 260 |----------| 261 | IoT node | 262 |----------| 263 Figure: Example Configuration 265 6. Acknowledgements 267 The authors would like to thank the consortium of the European 268 research project CHARISMA for the possibility to experiment. The 269 description of the final demonstration is available for download: 270 http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst 271 rators-Evaluation-and-Validation-vFinal.pdf 273 7. Authors' Addresses 275 Andreas Foglar 276 InnoRoute GmbH 277 Marsstr. 14a 278 80335 Munich 279 Germany 280 Email: foglar@innoroute.de 282 Mike Parker 283 Wivenhoe Park, Colchester 284 Essex, CO3 4HG 285 United Kingdom 286 Email: mcpark@essex.ac.uk 287 Theodoros Rokkas 288 Incites S.A.R.L. 289 130, Route d' Arlon 290 Strassen L-8008 291 Luxembourg 292 Email: trokkas@incites.eu 294 Foglar, Parker, Rokkas Expires September 1, 2018