IPv6 Source Routing for ultralow Latency
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Active".
|Authors||Andreas Foglar , Mike Parker , Theodoros Rokkas|
|Last updated||2018-03-02 (Latest revision 2017-11-12)|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Routing Area Working Group A. Foglar, InnoRoute INTERNET-DRAFT M. Parker, Uni Essex Intended status: EXPERIMENTAL T. Rokkas, Incites Expires: September 1, 2018 March 2, 2018 IPv6 Source Routing for ultralow Latency draft-foglar-ipv6-ull-routing-02 Abstract This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Revision Note for Version 02 Reference to experimental verification of the concept is added in the section "Acknowledgements". 1. Introduction To achieve minimum latency the forwarding nodes must support cut-through technology as opposed to the commonly used store- and-forward technology. Cut-through means, that the packet header already leaves a node at the egress port while the tail of the packet is still received at the ingress port. This short time does not allow complex routing decisions. Therefore, a very simple routing address field structure is specified below. It should limit the complexity of the forwarding node used in the experiments. Therefore, in this text the term "forwarding node" is used instead of "router", although the device is operating in OSI Layer 3 and accordingly executes router functions such as decrementing the hop limit field. Redundancy issues are not considered. 2. IPv6 address prefix structure The following proposal uses the 64-bit IPv6 address prefix. Each forwarding node has up to 16 ports and hence needs 4 bits of the address field to decide to which port a packet should be forwarded. The 64-bit prefix is divided into 16 sub-fields of 4 bit, defining up to 16 hierarchy levels. A forwarding node is configured manually to which of the sub-fields it should evaluate for the forwarding decision. A number n of leading 4-bit fields cannot be used for forwarding decisions, but must have a special value to indicate the 'escape prefix' of the experimental forwarding mode. The 64-bit prefix of the IPv6 address has this structure: | n x 4-bit escape prefix |(16-n) x 4-bit address fields | The first 4-bit field following the escape prefix has the highest hierarchy level, the last 4-bit field has the lowest hierarchy level. 3. Forwarding node behavior The forwarding node has up to 16 downlink ports and at least one uplink port. Typically, the forwarding nodes are arranged in a regular tree structure with one top node, up to 16 nodes in the second hierarchy, up to 256 nodes in the third hierarchy and so on for up to 16-n hierarchies. A forwarding node must be configured to operate at a certain position in the hierarchical network. For example, at third hierarchy level, branch 4 of the first hierarchy and branch 12 of the second hierarchy. The behavior of each forwarding node is depending on the position of a node in a hierarchical network. For all positions, the first step is to check the escape prefix. Only packets with matching escape prefix are forwarded. The top forwarding node with the highest hierarchy level evaluates the first 4-bit field following the n x 4-bit escape prefix. The value of the evaluation field determines the output port of the packet. The remaining fields are don't care: | escape prefix | 4-bit | (16-n-1) x 4-bit | < mandatory > <eval.> < don't care > A forwarding node in a lower hierarchy first checks if the 4- bit fields preceding the evaluation field match the configured value. In case of match the value of the configured evaluation field of the packet is used as downlink port number where the packet is forwarded. The remaining 4-bit fields are ignored. In case of mismatch the packet is forwarded to the uplink port(s). | escape prefix | m x 4-bit | 4-bit | (16-n-m-1) x 4-bit | < mandatory > < match > <eval.> < don't care > The parameter m indicates the hierarchy level with m=0 denoting the highest hierarchy. Hence, when a packet enters a hierarchical network at the lowest layer node it is forwarded in uplink direction until it reaches a node where the m x 4-bit prefix matches the configured value of the node. At latest, the highest-level node will always match and forward the packet in the desired downlink direction. 4. Numerical values As mentioned, one pre-requisite of the simple forwarding concept is to keep the complexity of the forwarding nodes low. Also, the configuration of the nodes should be kept simple. In particular industrial networks are operated by persons who are not experts in communication. Configurations should be intuitively understandable by all without long explication. Therefore, for the first experimental forwarding node the number of downlink ports is limited to 10 with numbers 0...9. 16 digits at the front panel of the forwarding device show the configuration. Use of classical 7-segment digits make the limits of the configuration obvious. As escape code, the first two digits are fixed to the value "AF" (binary '10101111'). These two characters contrast with the following numerical digits, so that the escape code can be clearly differentiated from the following configuration. The display uses the 'H' character instead of the 'X' the usual term for the variable. The H specifies the digit of the packet prefix which is evaluated for forwarding. When the H is selected all lower digits are automatically set to '-' to indicate the don't care nature. To make the configuration still more obvious it is recommended to configure the local telephone number. With that measure, every local experimentation has unique numbers and can potentially be interconnected via tunnels (IP, MPLS, VPN etc.) with other experimental setups. The length of 14 digits allows sufficient in-house hierarchies, even for industrial applications where forwarding nodes interconnect large numbers of sensor controllers. Inhouse installations would be structured for example in building, floor, fabrication unit, machine - with one sensor controller per machine. For the sake of simplicity numbers are deliberately wasted, for example if the building has only 3 stories the digits 4...9 are unused. 5. Example configuration A small office in Munich with the telephone number +49-89- 45241990 configures its local top-level forwarding node to: AF49.8945.2419.90H- Note that for the sake of simplicity this simplified notation is introduced here as alternative to the usual notation AF49:8945:2419:9000/56. With the new notation, the cabling staff people can immediately check the hierarchy location of the forwarding node and connect the cables to the floors at ports 0...3. The next hierarchy level is related to the floor. In case of a 3-story building only three next level forwarding nodes are used with these configured values: AF49.8945.2419.900H at the ground level AF49.8945.2419.901H at the first floor AF49.8945.2419.902H at the second floor AF49.8945.2419.903H at the third floor. In each floor, up to 10 sensor nodes can be connected. Each of the sensor nodes can address several sensors/ actuators addressed via the interface identifier contained in the second part of the 128-bit IPv6 address. In the following a connection between sensors in this office to otherIoT equipment located in Essex University is described. The connection is realized with one additional forwarding node installed at Essex University premises with the second level address AF4H.----.----.----. This high level forwarding node can be used although the phone number of the researcher is +44 1206 872413, as long as there is no further node in UK. At downlink port 9 the 13th level forwarding node in Munich is con- nected via a Layer 2 link such as VLAN or SDH pipe or MPLS tunnel. The levels in between must not be populated by forwarding nodes as long as no other branch is needed at one of the two sides. If for example another site in Munich center must be connected one additional forwarding node must be installed with the 5th level address AF49.89H-.----.----. The small office mentioned above would be connected to downlink port 4 while the new site would be connected at downlink port 1, the prefix for Munich center. The configuration is visualized in the Figure below. Essex (UK) Munich (DE) |---------U-----------| | AF4H.----.----.---- | |-0-1-2-3-4-5-6-7-8-9-| | \ | ------ L2 Link ------ |----------| \ | IoT node | |----------U----------| |----------| | AF49.89H-.----.---- | |-0-1-2-3-4-5-6-7-8-9-| / \ --- ----------- / \ |----------U----------| |----------U----------| | AF49.89H-.----.---- | | AF49.8945.2419.90H- | |-0-1-2-3-4-5-6-7-8-9-| |-0-1-2-3-4-5-6-7-8-9-| | |----------U----------| | AF49.8945.5419.901H | |-0-1-2-3-4-5-6-7-8-9-| U = Uplink | |----------| | IoT node | |----------| Figure: Example Configuration 6. Acknowledgements The authors would like to thank the consortium of the European research project CHARISMA for the possibility to experiment. The description of the final demonstration is available for download: http://www.charisma5g.eu/wp-content/uploads/2015/08/D4.3-Demonst rators-Evaluation-and-Validation-vFinal.pdf 7. Authors' Addresses Andreas Foglar InnoRoute GmbH Marsstr. 14a 80335 Munich Germany Email: email@example.com Mike Parker Wivenhoe Park, Colchester Essex, CO3 4HG United Kingdom Email: firstname.lastname@example.org Theodoros Rokkas Incites S.A.R.L. 130, Route d' Arlon Strassen L-8008 Luxembourg Email: email@example.com Foglar, Parker, Rokkas Expires September 1, 2018