idnits 2.17.1 draft-foglar-ipv6-ull-routing-00.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 240 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 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 September 12, 2017 6 IPv6 Source Routing for ultralow Latency 7 draft-foglar-ipv6-ull-routing-00 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. 57 Therefore, a very simple routing address field structure is 58 specified below. It should limit the complexity of the 59 forwarding node used in the experiments. Therefore, in this 60 text the term "forwarding node" is used instead of "router", 61 although the device is operating in OSI Layer 3 and accordingly 62 executes router functions such as decrementing the hop limit field. 63 Redundancy issues are not considered. 65 2. IPv6 address prefix structure 67 One of the goals of IPv6 was to have a sufficiently long address 68 to allow grouping in fields to simplify routing decisions. In 69 this proposal, this goal is exploited to allow for very low 70 complexity in the forwarding nodes. 72 Each forwarding node has up to 16 ports and hence needs 4 bits 73 of the address field to decide to which port a packet should 74 be forwarded. The 64-bit prefix is divided into 16 sub-fields 75 of 4 bit, defining up to 16 hierarchy levels. A forwarding 76 node is configured manually to which of the sub-fields it should 77 evaluate for the forwarding decision. 79 A number n of leading 4-bit fields cannot be used for forwarding 80 decisions, but must have a special value to indicate the 81 'escape prefix' of the experimental forwarding mode. 83 The 64-bit prefix of the IPv6 address has this structure: 85 | n x 4-bit escape prefix |(16-n) x 4-bit address fields | 87 The first 4-bit field following the escape prefix has the 88 highest hierarchy level, the last 4-bit field has the lowest 89 hierarchy level. 91 3. Forwarding node behavior 93 The forwarding node has up to 16 downlink ports and at least 94 one uplink port. Typically, the forwarding nodes are arranged 95 in a regular tree structure with one top node, up to 16 nodes 96 in the second hierarchy, up to 256 nodes in the third hierarchy 97 and so on for up to 16-n hierarchies. 99 A forwarding node must be configured to operate at a certain 100 position in the hierarchical network. For example, at third 101 hierarchy level, branch 4 of the first hierarchy and branch 12 102 of the second hierarchy. 104 The behavior of each forwarding node is depending on the 105 position of a node in a hierarchical network. For all 106 positions, the first step is to check the escape prefix. Only 107 packets with matching escape prefix are forwarded. 109 The top forwarding node with the highest hierarchy level 110 evaluates the first 4-bit field following the n x 4-bit escape 111 prefix. The value of the evaluation field determines the 112 output port of the packet. The remaining fields are don't 113 care: 115 | escape prefix | 4-bit | (16-n-1) x 4-bit | 116 < mandatory > < don't care > 118 A forwarding node in a lower hierarchy first checks if the 4- 119 bit fields preceding the evaluation field match the configured 120 value. In case of match the value of the configured evaluation 121 field of the packet is used as downlink port number where the 122 packet is forwarded. The remaining 4-bit fields are ignored. 123 In case of mismatch the packet is forwarded to the uplink 124 port(s). 126 | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | 127 < mandatory > < match > < don't care > 129 The parameter m indicates the hierarchy level with m=0 130 denoting the highest hierarchy. 132 Hence, when a packet enters a hierarchical network at the 133 lowest layer node it is forwarded in uplink direction until it 134 reaches a node where the m x 4-bit prefix matches the 135 configured value of the node. At latest, the highest-level 136 node will always match and forward the packet in the desired 137 downlink direction. 139 4. Numerical values 141 As mentioned, one pre-requisite of the simple forwarding 142 concept is to keep the complexity of the forwarding nodes low. 143 Also, the configuration of the nodes should be kept simple. In 144 particular industrial networks are operated by persons who are 145 not experts in communication. Configurations should be 146 intuitively understandable by all without long explication. 147 Therefore, for the first experimental forwarding node the 148 number of downlink ports is limited to 10 with numbers 0...9. 16 149 digits at the front panel of the forwarding device show the 150 configuration. Use of classical 7-segment digits make the 151 limits of the configuration obvious. 153 As escape code, the first two digits are fixed to the value 154 "AF" (binary '10101111'). These two characters contrast with 155 the following numerical digits, so that the escape code can be 156 clearly differentiated from the following configuration. The 157 display uses the 'H' character instead of the 'X' the usual 158 term for the variable. 160 The H specifies the digit of the packet prefix which is 161 evaluated for forwarding. When the H is selected all lower 162 digits are automatically set to '-' to indicate the don't care 163 nature. 165 To make the configuration still more obvious it is recommended 166 to configure the local telephone number. With that measure, 167 every local experimentation has unique numbers and can 168 potentially be interconnected via tunnels (IP, MPLS, VPN etc.) 169 with other experimental setups. 171 The length of 14 digits allows sufficient in-house 172 hierarchies, even for industrial applications where forwarding 173 nodes interconnect large numbers of sensor controllers. 174 Inhouse installations would be structured for example in 175 building, floor, fabrication unit, machine - with one sensor 176 controller per machine. For the sake of simplicity numbers are 177 deliberately wasted, for example if the building has only 3 178 stories the digits 4...9 are unused. 180 5. Example configuration 182 A small office in Munich with the telephone number +49-89- 183 45241990 configures its local top-level forwarding node to: 185 AF49.8945.2419.90H- 187 Note that for the sake of simplicity this simplified notation 188 is introduced here as alternative to the usual notation 189 AF49:8945:2419:9000/56. With the new notation, the cabling 190 staff people can immediately check the hierarchy location of 191 the forwarding node and connect the cables to the floors at 192 ports 0...3. 194 The next hierarchy level is related to the floor. In case of a 195 3-story building only three next level forwarding node are 196 used with these configured values: 198 AF49.8945.2419.900H at the ground level 199 AF49.8945.2419.901H at the first floor 200 AF49.8945.2419.902H at the second floor 201 AF49.8945.2419.903H at the third floor. 203 In each floor, up to 10 sensor nodes can be connected. 204 Each of the sensor nodes can address several sensors/ 205 actuators addressed via the interface identifier contained in 206 the second part of the 128-bit IPv6 address. 208 6. Acknowledgements 210 The authors would like to thank the consortium of the European 211 research project CHARISMA for the possibility to experiment. 213 7. Authors' Addresses 215 Andreas Foglar 216 InnoRoute GmbH 217 Marsstr. 14a 218 80335 Munich 219 Germany 220 Email: foglar@innoroute.de 222 Mike Parker 223 Wivenhoe Park, Colchester 224 Essex, CO3 4HG 225 United Kingdom 226 Email: mcpark@essex.ac.uk 228 Theodoros Rokkas 229 Incites S.A.R.L. 230 130, Route d' Arlon 231 Strassen L-8008 232 Luxembourg 233 Email: trokkas@incites.eu 235 Foglar, Parker, Rokkas Expires March 11, 2018