Data centers consume, control, and monitor data flow from or to things, either in the cloud or distributed locations. Dedicated applications run over virtualized or traditional operating systems or network edge platforms, communicating with data center servers. System solutions combining physical and data link layers require an architectural approach with a common layer independent from lower (connectivity) and upper (application) layers.
Adoption or Adaptation of the Internet Protocol
IP adoption in data centers, cloud services, and operation centers hosting IoT applications is complex and often makes running IP end-to-end more difficult. Before IPv4, many different protocol stacks overlapped with IP, leading to the need for multi-protocol routers. The use of multiple network layer protocols in addition to IP is a point of contention between computer networking experts.
Typically, one of two models is proposed: adaptation, which requires application layered gateways (ALGs) to ensure the translation between non-IP and IP layers, and adoption, which replaces all non-IP layers with their IP layer counterparts, simplifying the deployment model and operations.
In the industrial and manufacturing sector, there has been a move toward IP adoption, with solutions and product lifecycles spread over 10+ years. Serial communications protocols have evolved, with Ethernet and IPv4 now integrated. Examples of vertical market deployments that operate both the IP adaptation and adoption models include SCADA applications, which use both IP adaptation and adoption models. ZigBee solutions also operate both IP adaptation and adoption models, with a gateway often acting as a translator between the two.
- Bidirectional versus unidirectional data flow is a common issue in IoT systems, with some last-mile technologies offering optimization for unidirectional communication. For instance, devices like fire alarms, electrical switches, and water or gas meters that communicate through LPWA technologies may only need a few bytes of data to an application. Implementing a full IP stack may not be necessary for these cases, but it requires an end-to-end architecture to address potential drawbacks.
- IP adoption involves a layered architecture with varying per-packet overhead, which can be more than device data, especially in LPWA technologies. Therefore, it is crucial to decide whether the IP adoption model is necessary and how it can be optimized. Routing protocol and other verbose network services may also need optimization.
- The data flow model is beneficial for the end-to-end nature of communications, but security, privacy, and other factors may limit this concept. In some IoT solutions, a device's data flow is limited to one or two applications, so the adaptation model can work. Both IP adaptation and adoption models play roles in last-mile connectivity, depending on the network topology and data flow needed.
- Network diversity is a drawback of the adaptation model, as it depends on single PHY and MAC layers, which can impact deployment and operations planning.
The Need for Optimization
Constrained Nodes
In Internet of Things (IoT) solutions, different types of devices coexist, and their characteristics may differ from generic IT devices. The network protocol stack on an IoT node may require communication through an unreliable path, causing issues like limited throughput and low convergence.
Power consumption is a key characteristic of constrained nodes, as many IoT devices are battery-powered, with lifetime battery requirements ranging from a few months to over 10 years.
High-speed technologies like Ethernet, Wi-Fi, and cellular are not yet capable of multi-year battery life. To extend battery life, enable a low-power mode or always off mode. Classifying these nodes helps evaluate IP adoption and adaptation model selection.
IoT constrained nodes can be classified as follows:
- Devices that are very constrained in resources, may communicate infrequently to transmit a few bytes, and may have limited security and management capabilities: This drives the need for the IP adaptation model, where nodes communicate through gateways and proxies.
- Devices with enough power and capacities to implement a stripped-down IP stack or non-IP stack: In this case, you may implement either an optimized IP stack and directly communicate with application servers (adoption model) or go for an IP or non-IP stack and communicate through gateways and proxies (adaptation model).
- Devices that are similar to generic PCs in terms of computing and power resources but have constrained networking capacities, such as bandwidth: These nodes usually implement a full IP stack (adoption model), but network design and application behaviors must cope with the bandwidth constraints.
The definition of constrained nodes is evolving due to decreasing costs of computing power, memory, storage resources, and power consumption, while networking technologies improve bandwidth and reliability. The push to optimize IP for constrained nodes will decrease in the future.
Constrained Networks
In the early days of the Internet, network bandwidth capacity was limited due to technical limitations. Low-speed modems were used for data transfer, demonstrating that IP could run over low-bandwidth networks.
Today, high-speed infrastructures are available, but some IoT devices in the last mile cannot use them due to low bandwidth, limited distance, regulated transmit power, and limited network services.
Constrained networks have unique characteristics and requirements, with low-power, low-bandwidth links (wireless and wired) operating between a few kbps and a few hundred kbps. These networks can have high latency and a high potential for packet loss.
Constrained networks also present challenges in latency and control plane reactivity. One rule is to underreact to failure, as overreaction can lead to network collapse. Control plane traffic must be kept at a minimum to consume bandwidth needed by data traffic. Power consumption in battery-powered nodes is also a concern. Constrained nodes and networks pose significant challenges for IoT connectivity in the last mile.
IP Versions
The Internet Engineering Task Force (IETF) has been working for over 20 years to transition the Internet from IP version 4 to IP version 6. The main reason for this transition is the lack of address space in IPv4, which is still used in most traffic. However, the Internet of Things (IoT) must follow the same path as the Internet, supporting both IPv4 and IPv6 versions concurrently. Techniques like tunneling and translation are needed to ensure interoperability between IPv4 and IPv6. Factors determining the use of IPv4 or IPv6 in IoT solutions include legacy protocols or technologies that only support IPv4, while newer technologies and protocols almost always support both IP versions.
The following are some of the main factors applicable to IPv4 and IPv6 support in an IoT solution:
Application Protocol: IoT devices with Ethernet or Wi-Fi interfaces can communicate over both IPv4 and IPv6, but the choice of IP version depends on the application protocol. SCADA protocols, such as DNP3/IP, Modbus TCP, and IEC 60870-5-104, are specified for IPv4, so there are no known production implementations over IPv6. For IoT devices with IETF-defined application protocols like HTTP/HTTPS, CoAP, MQTT, and XMPP, both IP versions are supported. The choice of IP version depends on the implementation.
Cellular Provider and Technology: IoT devices with cellular modems depend on the cellular technology generation and data service provider. For GPRS, Edge, and 3G, IPv4 is the base protocol for data services. IPv6 must be tunneled over IPv4 for these generations. On 4G/LTE networks, data services can use IPv4 or IPv6 depending on the provider.
Serial Communications: Legacy devices in industries like manufacturing and utilities communicate through serial lines using proprietary or standards-based protocols like DNP3, Modbus, or IEC 60870-5-101. As analog modem connections have declined, local connections have become the solution. This involves connecting the device's serial port to a nearby router, which forwards the traffic over IP to a central server for processing. Encapsulation of serial protocols over IP uses mechanisms like raw socket TCP or UDP, but current implementations are mostly available for IPv4 only. This solution is necessary as analog modem services have declined.
IPv6 Adaptation Layer: Recent standardized IoT protocols support only IPv6-only adaptation layers for some physical and data link layers. Common layers like Ethernet and Wi-Fi require adaptation layers for both versions. Newer technologies like IEEE 802.15.4, IEEE 1901.2, and ITU G.9903 only have an IPv6 adaptation layer specified. This means devices implementing an IPv6 adaptation layer must communicate over an IPv6-only subnetwork. The IETF routing protocol for Long-Long Networks (LLNs) is also IPv6-only.
Optimizing IP for IoT
The Internet Protocol is essential for an effective Internet of Things; nevertheless, limited nodes and networks necessitate optimization across several layers and multiple protocols within the IP architecture. The subsequent sections present various optimizations that are either currently available in the market or under development by the IETF. The following Figure illustrates the TCP/IP layers at which optimization is implemented.
From 6LoWPAN to 6Lo
The IP architecture requires the definition and documentation of the transport of IP packets over Layer 1 (PHY) and Layer 2 (MAC) protocols. An adaptation layer is a model for packaging IP into lower-layer protocols, typically defined by an IETF working group and released as a Request for Comments (RFC). An RFC is a publication from the IETF that officially documents Internet standards, specifications, protocols, procedures, and events. IoT-related protocols follow a similar process, but may include optimizations to deal with constrained nodes and networks.
The main examples of adaptation layers optimized for constrained nodes or "things" are those under the 6LoWPAN working group and its successor, the 6Lo working group. The 6LoWPAN working group initially focused on optimizing the transmission of IPv6 packets over constrained networks, such as IEEE 802.15.4.
Comparison of an IoT Protocol Stack Utilizing 6LoWPAN and an IP Protocol Stack
6LoWPAN Header Stacks
The 6LoWPAN working group has released several RFCs, with RFC 4994 being the foundational one. It defines frame headers for header compression, fragmentation, and mesh addressing. These headers can be stacked in the adaptation layer to separate concepts and enforce a structured method for expressing each capability.
Header Compression
6LoWPAN is a protocol that uses IPv6 header compression, which was first defined in RFC 4944 and updated by RFC 6282. This capability reduces the size of IPv6's 40-byte headers and UDP's 8-byte headers down to 6 bytes combined in some cases. However, 6LoWPAN does not support IPv4 and there is no standardized IPv4 adaptation layer for IEEE 802.15.4. The compression is stateless and not too complicated, but factors like implementation of RFC 4944 versus RFC 6922, UDP inclusion, and various IPv6 addressing scenarios can affect the compression amount.
The above Figure shows a 6LoWPAN frame without header compression, with the full 40-byte IPv6 header and 8-byte UDP header visible. The 6LoWPAN header is a single byte, leaving only 53 bytes of data payload out of the 127-byte maximum frame size in IEEE 802.15.4. In the best-case scenario, header compression is enabled, increasing the 6LoWPAN header to 2 bytes to accommodate the compressed IPv6 header and reducing UDP by half to 4 bytes. This header compression allows the payload to double from 53 bytes to 108 bytes, making it more efficient. However, 2-byte header compression applies only to intra-cell communications.
Fragmentation
The maximum transmission unit (MTU) for an IPv6 network is at least 1280 bytes, which is larger than IEEE 802.15.4's 127 bytes. This is problematic as IPv6 packets are carried within the smaller 802.15.4 frame. To address this, large IPv6 packets must be fragmented across multiple frames at Layer 2.
The fragment header used by 6LoWPAN consists of three primary fields: Datagram Size, Datagram Tag, and Datagram Offset. The Datagram Size field specifies the total size of the unfragmented payload, the Datagram Tag identifies the set of fragments for a payload, and the Datagram Offset field indicates how far into a payload a particular fragment occurs. The 6LoWPAN fragmentation header uses a unique bit value to identify fragment fields, and the first fragment is only 4 bytes long. The remaining fragments have a 5-byte header field for the appropriate offset.
Mesh Addressing
The 6LoWPAN mesh addressing function forwards packets over multiple hops using three fields: Hop Limit, Source Address, and Destination Address. The hop limit provides an upper limit on how many times the frame can be forwarded, decrementing by 1 as it is forwarded. The Source Address and Destination Address fields are IEEE 802.15.4 addresses indicating the endpoints of an IP hop. The mesh addressing header is used in a single IP subnet and is a Layer 2 type of routing known as mesh-under. RFC 4944 only provisions the function in this case, as the definition of Layer 2 mesh routing specifications was outside the scope of the 6LoWPAN working group. An implementation performing Layer 3 IP routing does not need to implement a mesh addressing header unless required by a given technology profile.
Posts
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.