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