BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B

BASIL Networks BN'B

The BASIL Networks Public Blog contains information on Product Designs, New Technologies. Manufacturing, Technology Law, Trade Secretes & IP, Cyber Security, LAN Security, Product Development Security

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-6

saltuzzo | 24 September, 2017 12:08

Part 6: IPv4, IPv6, Protocols - Network, Transport & Application: Continued
The Ethernet Protocol(s), Lets Sync Up

"The more extensive a man’s knowledge of what has been done, the greater will be his power of knowing what to do". -Benjamin Disraeli

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform
- IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018) 
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)

 

Quick review to set the atmosphere for Part 6
From the previous Internet of Things Part-1 through Part- 5:

  • The Internet runs on protocols period.  No protocols no Internet!  The Internet is a Point to Point (P2P) topology scheme.
  • The Internet has two network layer categories - A- The Internet Network - router to router category (OSI Layers 2-5),  B- LAN Hardware Router to Physical Layer (OSI Layer 1) category.
  • The physical network Local Area Networks (LAN) may communicate with different LAN topologies using a hardware Medium Translator to convert one topology to another.
  • Local Area Networks (LAN) are run on hardware protocols and have many configurations.  The LAN headers are stripped from the Internet Network Protocols and are not part of the MTU.
  • Packet Switched Networks - The Internet uses data packets to transport information from point A to Point B.  
  • The TCP/IP Internet Suite's four layer "grouped" OSI model still incorporates the seven layers of the OSI model.  The grouping methodology incorporates protocols to easily identify the use of selective layers one through five independently that do not require an IP header or may operate device to device communications.
  • Introduced  a typical router to router and router to Physical Layer protocol formats, Table 5.2 that will provide an understanding of the Internet schemes as well as set a format for the protocol requirements for the IoT Core Platform.

What we want to cover in Part 6:  Connecting To The Ethernet Protocol

  • Separating the Internet Protocols from the Physical Layer protocols and how they interact.
  • The presentation of the Ethernet Physical Layer protocol header that define its operation.
  • The Ethernet protocol versions that exists and the headers that separate their identity.
  • Construction of the Ethernet basic protocol header for device to device communications
  • Capture real Ethernet Protocol data and display incoming and outgoing traffice over the Ethernet bus.

Lets Get Started: Some Serial Communications Basics
Hardware communications protocols are generally refereed to as a BUS Protocol like RS232, RS422, RS485, USB, are all hardware topologies used to transport data serially over a physical medium, each having their own fixed specifications.  Serial communication data hardware has been around for many years and active way back before the first computer system was placed on the market.  There are basically two types of serial communications, Asynchronous and Synchronous.

Asynchronous communication bus is where data is understood to be clocked at the same rate for devices at both ends of the bus, triggered by a detection of the first edge transition defined as the Start Bit and repeated for a defined number of bits then ended with a clock cycle defined as a Stop Bit.  The most common Asynchronous BUS is the RS232 Universal Asynchronous Receiver Transmitter - (UART).

Synchronous communication bus is a bus that sends its clock time interval on a separate wire to identify the time interval the data is valid on the data line, hence the sending of the data is set to a predetermined time interval that is synchronized by the clock interval transferred with the data.  Synchronous hardware protocols are I²C (Inter-IC ) BUS, Serial Peripheral Interface (SPI) and others that have a fixed clock wire transferred with the data wire to identify the data valid time interval.  Figure 6.0 shows the basic block format requirements for hardware protocols for serial data buses.

SerialBlockBasics
Figure 6.0  Serial BUS Basic Structure Block Diagram

The Ethernet BUS Physical Device Hardware:
The Ethernet hardware protocol bus transfers data from a unique source to a unique destination serially.  The Ethernet bus Network Interface Controller (NIC) has to configure the Data Transfer Rate (DTR), configure the Mode(Half/Full Duplex), Specify source device, Specify destination device, Detect corrupt data, resolve collisions and extract the data payload.  The collision part is easy since the Ethernet Switch handles that with only one device per  switch port, we will get to the Ethernet Switch shortly.  The Detect corrupt data issue is rare on a properly installed network however, if the data is corrupted the packet is just dropped and there is no way to know where it came from so the sender has no knowledge of it being corrupted either and just keeps sending data.  For high QoS (Quality of Service) networks there are feedback and data manipulations techniques used to insure data integrity; we will cover that in the software development part of the series.

The Ethernet Physical bus may be configured to operate in half or full duplex mode although half duplex is rarely used today. Half duplex was setup initially setup with coaxial cable mainly to avoid collisions and continued on with the introduction of the Ethernet Hub, since Ethernet Hubs are half duplex devices. The hub introduced the single port, single device concept and made it easier than running coaxial cable from device to device; the Hub has been replaced with the introduction of the Ethernet Switch.  The Ethernet switch is a more flexible device that operates in both half and full duplex mode among other unique features .that we will discuss later.

The Ethernet hardware network is the most common of the physical networks today and is used in the majority of businesses and home Internet connections and has several speeds of 10Meg bps,  100M bps,  1Gig bps and 10/25/40 Gig bps.  There are other Physical Layer protocols also in use today as we discussed in Part-5 Table 5.2, however we will focus on the Ethernet for this part of the series.  We will review the implementation process for other Physical Layer medium topologies when we address integrating different network medium topologies into the IoT Core Platform later in the series.

Moving forward, the Ethernet Physical Layer cable connections does not incorporate a physical clock line in the bus architecture which implies that  the bus in the asynchronous communications bus category.  The standard configuration today for the Ethernet bus is full duplex and the cables eight twisted pairs of the modular connector uses a differential signal twisted pair for the Transmit data and a differential signal twisted pair for the Receive data.  The remaining twisted pairs are used for various integrated features like PoE (Power over Ethernet) and other higher speed configurations.  So how does the controller configure itself to the different transmission speed ?   We will answer that question next.

The Ethernet Protocol Header(s): The Ethernet Physical Hardware Topology
OK, so if the Ethernet connector does not have a separate clock line and is a "Full Duplex" TX/RX differential pair set, how does it configure itself to the different 10/100/1Gps BASE-T etc. data speed being transported over the LAN bus?  The answer is the controller autonegotiates to the serial data stream data in the first eight octets(bytes).  We will show how this is done while we introduce the 802.3 Ethernet Header format.

The structured format of the Ethernet Physical Layer bus follows the basic serial bus format of a Preamble (Start ID) and Inter-Packet Gap (End Idle Time) format with a data payload in the middle.  The controller monitors the data transitions during the Preamble eight Octets(bytes) and if the transitions of the preamble are at stable intervals the configuration will use preamble intervals to set the controllers clock, mode etc. and be ready to receive a Start Frame Delimiter (SFD) byte eight and then begin the receiving of the data payload octets.  This configuration methodology categorizes the Ethernet bus as being an asynchronous autonegotiation bus configuration for half/full duplex mode as well as 10/100/1G BASE-T.  The Ethernet switch is an important device for this since it allows each port to be configured separately and the single port per device allows easy disconnect from the network without any loss of performance.

The details of the Preamble is a fixed pattern of alternating 1's and 0's for the first eight octets of the Ethernet header as shown in Figure 6.2a as 10101010-10101010-10101010-10101010-10101010-10101010-10101010- 10101011.   The last byte of the Preamble is the SFD (Start Frame Delimiter that ends with two 1's identifying the start of the data payload being transferred.  From this point the controller is expected to be asynchronously clocked, (destination data rate is auto-adjusted to the senders data rate) to start collecting octets from the frame.  If the controller is not configured it drops the entire frame and waits for the next frame after the Inter-Packet gap idle period of 12 octets.  The data is collected and stored starting at first octet after the SFD and ends when there is no more data after the checksum or for the maximum frame size and the bus becomes idle for 12 octets at which time the controller resets and is ready for the next header.  The 12 octet idle time is defined as no data transitions on both Transmit and Receiver pairs which signals the end of the frame.  The octet count is given as the first octet after the SFD plus the last octet of the Checksum and retained in the transfer data buffer to inform the connected API the number of octets it has to processes.

There are three unique structures for the Ethernet frame and they are shown in figures 6.1a, 6.1b and 6.1c.  The three frames have the same fields up to octet 21, then the frames in figure 6.1b and 6.1c incorporate new fields.  The field differences are the addition of the 802.2 protocol to identify pointers and inter-layer communications and is processed uniquely by the source/destination layers.  Remember back in the series the statement was made that the user data can be anything as long as the transfer point to point follow the available protocols and the user data encoder/decoder are a matched at both ends.  We will get into the inter-layer communications later in the series, for now the decoding after octet 21 is up to the Application Program Interface connected to the transfer to decode/encode the payload.  

Ethernet_Header_Frame
Figure 6.1a  802.3 Standard Ethernet Physical Protocol Header Format

EthernetFrameBlockHeader1
Figure 6.1b  802.3 + 802.2 Ethernet Physical Protocol Header Format
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)

EthernetFrameBlockHeader2
Figure 6.1c  802.3 + 802.2 + SNAP  Ethernet Physical Protocol Header Format
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)
SubNetwork Access Protocol (SNAP) Control

Figure 6.1a shows the standard Ethernet II frame commonly used for the Three Way Handshake and other payloads where the entire MTU fits into a single Ethernet frame.  Figure 6.1b is the extended Ethernet Frame that is used for inter-layer status or network information protocols like as ICMP and others.  The extended control fields are the Source Service Access Point (SSAP) Destination Service Access Point (DSAP) for inter-layer communications.  Figure 6.1c is the extended Ethernet frame generally used for larger segmented payloads such as HTML, FTP and others.  The extended control fields are the Source Service Access Point (SSAP) Destination Service Access Point (DSAP) plus the Subnet Access Protocol (SNAP) control to keep track of the segmentation of the data transferred.  The headers shown in Figures 6.2a, 6.2b have a fixed format up to Octet 21, the variations in header structures are defined by octets 20 and 21 and determine the remaining structure, hence: the data/payload section.  Table 6.2 is a list of the variations for the Type/Length field to determine the full maximum length of the header.  The extended fields will be covered later in the series with the inter-layer communications and data segmentation, for this part of the series we are presenting the Ethernet format structure and device to device data transfer.

The Ethernet Cable Length Defined
There are many variations and opinions of what the maximum physical length of the Ethernet over twisted pair cable should be, however the variations are set by the cables category ID from Cat3 through Cat8 which all incorporate the same modular connector defined as an 8 Position 8 Contact (8P8C) connector.   The physical length of the cable is dependent on the category ID and drive capabilities of the hardware it is connected to.  The standard length of the cables for Cat3-Cat6  for their assigned speed is 100 meters, Cat8 is 30 meters for its 25-40Gbps BASE-T speeds and only operates in full-duplex mode.  Technically the full analytical derivation for cable length is beyond the scope of this series however, cable length parameters are derived from several physical characteristics that include, twisted pair capacitance per foot, shielding separate pairs or if only one shield, cross talk capacitance between pairs, cable resistance ohms per foot, number of strands in the standard topology or diameter for solid wire,  signal voltage swing peak to peak, and the source power available for driving the signal, the switching frequency of the signal-10Mbps, 100Mbps, 1Gbps etc. are the main parameters taken into consideration to determine the length.  The industries standard length of 100 meters (328 feet) between device to a switch port and down link switch port to an up link switch port  are confirmed by all equipment manufacturers at this time.  There exists custom equipment that allow much longer lengths however it would be easier, cheaper and better QoS to just add a switch or RJ45 active cable extender to obtain longer lengths.

Some Computer History: How The Bit Assignments Nomenclature Changed
Back in Part-4 IP Header Formats we mentioned the Bit assignment nomenclature being reversed so to put this in perspective we will take a trip down memory lane for us seniors and ancient history for the younger.  To start the Binary Base2 system has not changed and goes back to the 1600 if not further, however it was introduced to the digital world with a relay-based computer in the 1940's along with the nomenclature weighting of the base2 number system,  2n + 2n-1 +.....+ 21 + 20  where 20=1, 21=2, etc  as 1, 2, 4, 8, 16 etc. Left to Right Most Significant Bit(MSB 2n) to the LeastSignificant Bit (LSB 20) so the original nomenclature was weighted similar to the decimal number system right to left increasing number,  the bigger n is the larger the number is.  OK, now the change, when the major minicomputer was introduced in the late 1950's by Digital Equipment Corporation (1950-1990) known as DEC or Digital the bit assignment nomenclature "only" was reversed as  20 = highest bit number number and 2n = 1 the lowest bit number on the computer switch panel, however the binary base-2 number system did not charge it was just the way DEC's nomenclature was introduced.  In 1968 this changed again with the introduction of the 16 bit computer from one of DEC's digital engineers that left and started Data General Corporation (1968-2002).  The bit assignments nomenclature was changed back to the original base2 nomenclature for 15-00 where 15 = MSB ( 215) and 00=LSB (20 ) with the weighted decimal system where  20=1.  To add a bit to the confusion the computer word was segmented into three bit blocks  for an base8 (octal) notation.

Remember that the bit assignment nomenclature is only a nomenclature and may or may not represent the true form of the bits being transmitted.  For the Ethernet Frame Bits are placed on the bus the Least Significant Bit (Bit7) first.  This does not change the actual number it just brings it back into the standard serial methodology.  So to sum this role reversal, in the real digital world serial data is placed on the bus MSB first and shifted left so the bit notation is MSB(27)-LSB(20) left to right where bit 7 is the real MSB and the binary data is read and weighted the same way the decimal system is weighted.  In the Internet world because of the bit reversal the data is placed on the bus Least Significant Bit  (bit 7) first and the bit notation is LSB(20)-MSB(27) left to right.  Sort of a long way around for the bits to be read into the device and ends up in the real digital world weighted format the way it should.  This will have more meaning when we are in the hardware design section of the series which will show that many chip devices that support serial protocols have different MSB/LSB transfer formats.  Therefore the actual Ethernet Preamble + SFD real world data read by another device will be 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5 hex format or 85 85 85 85 85 85 85 213 in decimal format.   The SFD 0xD5 byte signals the start of the octet data to be read.  This will all fall into place when we setup the header structure shown in Figure 6.2a and Figure 6.2b for programming the Ethernet Frame in the software section of the series.

EthernetFrameBlockHeader
Figure 6.2a  802.3 Standard Ethernet Header Frame Structure

EthernetFrameBlockHeader_SNAP
Figure 6.2b  802.3 + 802.2  Ethernet Header Frame Structure
Source Service Access Point (SSAP)
Destination Service Access Point (DSAP)
SubNetwork Access Protocol (SNAP) Control

The Ethernet network topology changed the way we connect devices on the Local Area Network.  The old coaxial cable we just paralleled each computer to the same cable it was cumbersome to work with and the cable loading factors were difficult to troubleshoot among other difficulties.  With the RJ45 Cat5[6] twisted pair cables we use a multi-port Network Switch to connect devices single port - single device.  The variations in speed and mode hence, 10/100/1Gbps Base-T, full/half duplex NIC's are handled by the Network Switch where each device is connected to a single RJ45 port on the switch.  For each device the switch allows it to run in half or full duplex depending on the NIC and only sends the data to the destination port by keeping track of the MAC address for each device connected to the same LAN; half duplex is rarely used today in Local Area Networks.  We will cover switches in more detail later in the series.  For now the basics are, switches maximum speed defines network speed regardless of the NICs in the devices connected to the switch ports;  the devices maximum speed is set by the NIC regardless of the maximum speed of the switch.  On a multi-speed switch each port may run at the negotiated speed of the NIC on that port.

Will The Ethernet Physical Layer Protocol Please Stand Up:
As shown below in Table 6.0 the IEEE 802.xx Hardware protocol has been around for some time and have been updated to address new transmission demands.  For this part we will focus on the IEEE 802.3 Ethernet specification.  The light green background protocols are the ones we would like implemented into the IoT  Core Platform.  The IEEE 802.3 specifications have been upgraded over the years (1983 - 2017) and expectations up to 2019 to handle the variations in connectivity and speeds up to 40G bps.  The design methodology of the IoT Platform will incorporate the flexibility for the implimentation of additional hardware protocols as they are required for the application.

Active Working Groups

Name

Description Note
IEEE 802.1 Higher Layer LAN Protocols (Bridging) active
IEEE 802.3 Ethernet  Original Specification 1980 - Standard in 1983 active
IEEE 802.11 Wireless LAN (WLAN) & Mesh (Wi-Fi certification) active
IEEE 802.13

Unused[2]  for Fast Ethernet development[3]

Reserved
IEEE 802.15 Wireless PAN active
IEEE 802.15.1 Bluetooth certification active
IEEE 802.15.2 IEEE 802.15 and IEEE 802.11 coexistence  
IEEE 802.15.3 High-Rate wireless PAN (e.g., UWB, etc.)  
IEEE 802.15.4 Low-Rate wireless PAN (e.g., ZigBee, WirelessHART, MiWi, etc.)  
IEEE 802.15.5 Mesh networking for WPAN  
IEEE 802.15.6 Body area network  
IEEE 802.15.7 Visible light communications  
IEEE 802.16 Broadband Wireless Access (WiMAX certification)  
IEEE 802.16.1 Local Multipoint Distribution Service  
IEEE 802.16.2 Coexistence wireless access  
IEEE 802.17 Resilient packet ring hibernating
IEEE 802.18 Radio Regulatory TAG  
IEEE 802.19 Coexistence TAG  
IEEE 802.20 Mobile Broadband Wireless Access hibernating
IEEE 802.21 Media Independent Handoff  
IEEE 802.22 Wireless Regional Area Network  
IEEE 802.23 Emergency Services Working Group  
IEEE 802.24

Smart Grid TAG   - New (November, 2012)

 
IEEE 802.25 Omni-Range Area Network  

Inactive / Old Working Groups

IEEE 802.2 LLC disbanded
IEEE 802.4 Token bus disbanded
IEEE 802.5 Token ring MAC layer disbanded
IEEE 802.6 MANs (DQDB disbanded
IEEE 802.7 Broadband LAN using Coaxial Cable disbanded
IEEE 802.8 Fiber Optic TAG disbanded
IEEE 802.9 Integrated Services LAN (ISLAN or iso Ethernet) disbanded
IEEE 802.10 Interoperable LAN Security disbanded
IEEE 802.12 100BaseVG disbanded
IEEE 802.14 Cable modems disbanded
     

Table 6.0  The variations of the IEEE 802.xx Protocol Specifications

Ethernet Frame Fields Description
The Ethernet Frame Fields are listed in Table  6.1 below showing the standard 802.3 field definitions.  There exists an extension of 802.3 that adds an additional four octets that attaches some Subnet identifiers 802.1Q tags that support Virtual LANs (VLANs) over an Ethernet Network. We will address this during the software protocol implementation part of the series.  For now lets focus on the standard Ethernet 802.3 to set the ground floor of our understanding to grow on.  The two main fields that require some thought are the Type/Length and the Payload fields.   The Type/Length field (16 bits) 2 Octets has gone through many updates and additions over time as the list of field parameter values show in Table 6.1 below.

Octet [Fixed Fields] Size Name Description
00-06 56 bits
7 Octets
Preamble 10101010 10101010 10101010 10101010 10101010 10101010 10101010 Binary
0x55 0x55 0x55 0x55 0x55 0x55 0x55 hex
07 1 Octet Start Frame Delimiter SFD 10101011 Binary 0xD5 hex
08 - 13 6 Octets Destination MAC Address NIC MAC Address of Destination
14 - 19 6 Octets Source MAC Address NIC MAC Address of Source
20-21 Octets   Ethernet II type - This is for this series [+4] - 802.1Q if implemented + 802.2
22 1 Octet SSAP - Source Service Access Points LLC- Logic Link Control 802.2 Figure 6.1a
23 1 Octet DSAP - Destination Service Access Points LLC- Logic Link Control 802.2 Figure 6.1a
24 - 25 1 or 2 Octet Control LLC- Logic Link Control 802.2 Figure 6.1a
26 5 Octets SNAP - SubNetwork Access Protocol SNAP - Subnetwork Access Protocol  Figure 6.1b DSAP-SSAP
22-1521 or [27-1528] 46-1500 Octets Payload Data Variable Payload must be 46 bytes minimum up to 1500 Bytes Maximum
1522-1525 or [1529 -1532] 4 Octets Checksum Checksum of all bytes in the header
  12 Octets Inter-Packet Gap  - Idle Time  (End of Transfer ID) Not part of checksum - This is just Idle inter-Packet Idle Time to separate packets.

Table 6.1  Ethernet Structure Field Assignments IEEE 802.3

The parameter values listed in Table 6.2 only reflect the parameters we are currently interested in for the IoT Core Platform development.  Presently there are about 50 different Ethernet Type parameter ID that have been defined and available for implementation into the 802.3 protocol.  Depending on the IoT Core Platform applications we leave this open for future implementation.

Ethernet Type Protocol Description Ethernet Type Protocol Description
0x0800

Internet Protocol version 4 (IPv4)

0x8844

EtherCAT Protocol for Automation

0x8006

Address Resolution Protocol (ARP)

0x88B9

GSE (Generic Substation Events) Management Services

0x0842

Wake-on-LAN

0x8892

PROFINET Protocol

0x22F3

IETF TRILL Protocol

0x88A8

Provider Bridging (IEEE 802.1ad)

0x22EA

Stream Reservation Protocol

0x88E5

MAC security (IEEE 802.1AE)

0x8035

Reverse Address Resolution Protocol

0x88F7

Precision Time Protocol (PTP) over Ethernet (IEEE 1588)

0x8100

VLAN-tagged frame (IEEE 802.1Q)

0x891D

TTEthernet Protocol Control Frame (TTE)

0x8204

QNX Qnet

   
0x86DD

Internet Protocol Version 6 (IPv6)

0x8863

PPPoE Discovery Stage

0x8808

Ethernet flow control

0x8864

PPPoE Session Stage

0x8809

Ethernet Slow Protocols

   
0x8847

MPLS unicast

   
0x8848

MPLS multicast

0x9100

VLAN-tagged (IEEE 802.1Q) frame with double tagging

Table 6.2  Ethernet Structure Type/Length Field Assignments IEEE 802.3

If  DSAP and SSAP are both 0xAA then SNAP is active which incorporates an IEEE 802.2 attachment protocol which we will cover during the software protocol part of the series since it involves other layers of the OSI model.  The typical IPv4 Ethernet-II from Table 6.1 above uses 0x800 for the standard protocol header and 0x806 for ARP discussed in Part-3 and 4 of the series.  For this section lets just focus on the standard IPv4 802.3 and use 0x800 as the Type/Length to construct the Ethernet Header to talk to other devices on the network.  On the issue of MAC addresses which is how the Ethernet LAN communicates to devices the MAC is assigned

MAC address assignments for manufacturers desiring to incorporate Ethernet controllers in to their products should obtain a manufacturer ID from the IEEE Registration Authority.   Ethernet controller chip ICs purchased from chip manufacturers generally require the user to supply a MAC address in order to use them.  MAC addresses are unique on a network just as IP addresses are unique for the Internet as we discussed earlier in the series.  IPv4 as we discussed only require a MAC to talk to the LAN, however IPv6 uses the MAC address as part of the unique IP address.  The data/payload is the only area that decerns the IPv4 - IPv6 schemes and any additional protocols.

IoT Core Platform Network Switch Connection: The Ethernet RJ45 10/100/1Gbps BASE-T
The structure for the Ethernet header is constructed depending on the protocol format being used.  Since there are separations for IPv4 and IPv6 as well as SNAP we would be implementing these separately and will cover these in the protocol software section of the series.  At this time we would like to bring up how the IoT Core Platform is intended to be connected to the LAN for both IPv4 and IPv6.  The connection methodology is intended to be wired RJ45 twisted pair cable, Wireless WiFi and Bluetooth. through a multi-port switch.   This brings up the Switch technology today that has improved to the point that the LAN does not require a separate HUB or run in half duplex for an effective LAN.  Switches have several basic features that help control traffic throughout the network.  Since a single device is connected to a single port each switch port maintains a MAC address buffer and is able to connect only to the destination device without interfering with other ports.  This allows better control over collisions as well as less interaction with the router which increases throughput when accessing the Global Internet..  Figure 6.3 is a typical IoT Platform connected to a multi-port switch, each platform device has its own port on the LAN.  Switches have two categories, managed and unmanaged where the majority of home Internet networks use unmanaged switches.  The main difference is managed switches allows user control of network traffic ports configuration and the unmanaged is a predetermined fixed configuration for traffic flow.  Figure 6.3 shows a typical eight port switch connected to several devices.  We identified each of these devices MAC address to show how the typical switch handles traffic device to device.  We setup a source and destination MAC address and filled in a Ethernet Header as it would be extracted from a TCP header and sent to OSI Layer 2 Data Link.  The captured data shown in Figure 6.4a is the sender(outbound ) traffic data to the switch port 6 and Figure 6b is the destination( inbound) traffic data.  Since one of the features of the switch is to strore the IP and MAC addresses for eachj of the switches port, these will be listed with the captured data.  The switch actually decodes the destination MAC address and it opens on;y the destination port to send the data to.  Since this was from a TCP handshake protocol sequence the IP are listed as part of the capture however, only the MAC addresses are used in the actual device to device on a Ethernet LAN.

IoTPlatform_Switch
Figure 6.3  Physical Cat6e Cable Connection 8 Port Switch

Ethernet Communications Device to Device Captured on LAN
The LAN connected devices in IPv4 & IPv6 communicate via the MAC addresses, there are no IP addresses in the Ethernet Physical Header.  This means one can easily talk device to device just using the Ethernet Physical Layer Header and supply unique data for each device.  We will look at this in more detail when we cover LAN based Industrial Control Networks as the series moves forward.  Figure 6.4a and 6.4b are the captured Ethernet Frame outbound at Source to Inbound at Destination through the switch using a typical packet capture program.   As we see there are no IP addresses required to setup the Ethernet Frame and transfer data to other devices on the LAN.  The network used to collect this data was a 1Gbps BASE-T using an unmanaged switch.  The MAC addresses are assigned to Intel Corporation as are the Network Interface Controllers on two different systems.  The two devices send data and confirm the same data to insure a link.  The Type/Size is x800 which is Internet Protocol version 4 from the above table.  The captured Ethernet packets shown below Figures 6.4a abd 6.4b will not show the first 8 bytes or the IPG 12 bytes since they are the Identifiers for synchronize and end data collection and are not part of the frames device data. The size of the data payload is also tracked and displayed, the firewall on the system allowed this data to be collected from Source to Destination.

EthernetCaptureFrameOut
Figure 6.4a  Captured Ethernet Header Frame Outbound

For MTU's less than the 1500 octets/bytes the data fits into the Ethernet Frame and only requires a single transport cycle.  Notice that the Inbound and Outbound traffice the MAC addresses have been reversed.  This communications was a ping test for the server and workstation confirmation of connection.  The system use for this series series was assembled specifically for the development of this IoT Core Platform series for continuity.  The system configuration consists of an Intel Server dual Xeon 64 bit processors with Hyperthread running Redhat Enterprise Linux connected to two workstations two Windows XP-Pro x32 bit and a Windows 10 x64 bit system.  The IoT Platform series network is a stand alone Client / Server configuration that is not connected to the Internet.

EthernetCaptureFrameInbound
Figure 6.4b  Captured Ethernet Header Frame Inbound


Summary for Part 6:

  • All serial hardware protocols have to have some methodology to identify a starting point for the data transfer and the end of the data transfer, as well as when each bit is valid to be sensed.  

The Ethernet Protocol hardware characteristics incorporates the following capabilities and features:

  • a differential twisted pair configuration for Transmit and Receive lines.
  • a variable length protocol - the payload varies from 46 bytes minimum to 1500 bytes maximum with an added eight bytres (802.2, 803.1Q) for inter layer links if incorporated.
  • an internally hardware controlled asynchronous autonegotiation protocol - uses 8 bytes to determine configuration and 12 idle bytes to end data transfer.
  • auto-configuration to run Full or Half duplex  for the 10/100 BASE-T,  1Gbps BASE-T and above run in full duplex only.
  • Ethernet switches internally maintain the devices IP and MAC address of devices connected to each port.
  • a mechanism through Ethernet switches allowing device to device communication without router intervention.
  • MAC addresses must be unique to the connected LAN devices.
  • Manufacturers must be assigned a block of MAC addresses along with a manufacturer ID.
  • The Ethernet Controller requires eight octets, a  block of 31 sets of state changes 1's and 0's to configure the controller for the start of the data
  • The Ethernet Controller requires a block 12 idle states to identify the end of data transfer.

Part 7 overview will cover a continuation of the Ethernet Frame
Now that the core structure of the Ethernet Physical protocol has been presented as a data transfer protocol we will present the following to finish up the Ethernet Physical protocol presentation.

  • CRC - Cyclic Reduncancy Check basics
  • Why do we use CRC's
  • Basic polynomial multiply/divide and XOR algorithms for the Internet.
  • The CRC-32 for the Ethernet Protocol Frame
  • The Checksums for the TCP, UDP, & ICMP Protocols
  • Another look at checking the integrity of data, IP, TCP, UDP, ICMP protocols
  • A look at other protocols checksums, CRCs and data integrity mechanisms
  • A brief introduction to the embedded processor market and the process of selection.
  • A brief introduction to Ethernet controller IC's
  • A brief introduction of other peripherals for the IoT Core Platform.

Reference Links for Part 6:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main_Page


Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 5 Network Protocols - Network, Transport & Application -Continued (Aug 17, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -The CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform
- IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018) 
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-6 The Ethernet Protocol (s): Lets Sync Up- (Sept 22, 2017)

For Website Link: cut and past this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=11&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-6 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Sept 242017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-5

saltuzzo | 21 August, 2017 12:30

Part 5: IPv4, IPv6, Network Protocols - Network, Transport & Application: Continued
Protocol, Protocol, Protocol, Lets Sync Up

When a Man's knowledge is not in order, the more of it he has the greater will be his confusion - Herbert Spencer

Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core Platform - IoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)

Quick review to set the atmosphere for Part 5
From the previous Internet of Things Part-1 through Part- 4:

  • We have presented the basics of the Internet and established that the Internet is just a transport agent of the "Information Highway" and the IP address is just a single point on that highway.
  • Internet Protocols are a methodology or a road map for the transport agent to carry the information payload from point A to point B for IPv4 or IPv6.
  • The IP scheme identity is defined by the first 4 bits of the IP header, of the 16 available network identities 14 are available for networks, Identities 0x0 and 0xF are reserved.  IPv4 identity is 0x4 and IPv6 identity is 0x6. The remaining schemes are ST (State Datagram Model) = 0x5, defined in RFC1819 as an attempt to stream data and control QoS (Quality of Service). The ST protocol is not used much at this time.  PIP (Private Internet Protocol) = 0x8, defined in RFC1621 - RFC1622,  TUBA  (TCP+UDP+Big Address) = 0x9 defined in RFC1561  as a CLNP(ConnectionLess Network Protocol) and TP/IPC (TP/IX)  (Transmit Protocol / Inter-Communications Protocol) = 0x7, Next Version Internet defined in  RFC1475.
  • We presented the IPv6 dual-stack or tunnel that connects IPv6↔IPv4 Point-2-Point assignment in order for IPv4 only networks to coincide with IPv6 networks using a block of IPv6 addresses assigned as ::FFFF:[IPv4 address], the long form being represented as 0000:0000:0000:0000:0000:FFFF:xxx.xxx.xxx.xxx.  IANA assigned ::FFFF:hhhh:hhhh to uniquely identify the IPv4 only addresses that are not IPv6 aware. This is one of the few times both hex and decimal notation are used in the same number.
  • We presented the throughput and bandwidth issues that, unfortunately will always be an active issue within the Internet environment for either IPv4 or IPv6 schemes or any other scheme implemented that requires an ISP to use. The bandwidth issue is due to the fact that bandwidth is an "income producing product" for Internet Service Providers, the more bandwidth the faster throughput, the higher monthly charge for the connection.
  • We presented an overview of  the list of protocols that IPv4 and IPv6 are able to handle as well as an overview of the list of protocols we wish to initially implement into our IoT Core Platform.

What we want to cover in Part 5:  Still More Protocols
 The Internet runs on "Protocols", yes, the slogan was a well known commercial and acknowledged for the creators innovation.   The statement for the Internet is absolutely true, the Internet IPv4 or IPv6 in this series runs on protocols period.

  • First we will cover an important documentation feature of the Internet schemes, the "Request For Comment" (RFC)
  • Packet Switched Networks - The Internet uses data packets to transport information from point A to Point B.
  • The TCP/IP Internet Suite's four layer grouped OSI model and the main protocols associated with each layer for this series.
  • Briefly investigate the physical network layer's serial data stream that is placed on the network to communicate with other computers, devices and different network topologies. A detailed presentation on the physical layer will be presented during the hardware design stage of the IoT Core Platform.
  • Present more about protocols, how they differ and how they are incorporated into the data flow for the TCP/IP Internet Suite four layer model.
  • Present two protocol categories one that uses the IP header and one that does not use the IP header and the implementation stimulus/response with the TCP/IP OSI  Model.  
  • Present a typical protocol format of the categories that will provide an understanding of the Internet schemes as well as set a format for the protocol requirements for the IoT Core Platform.

Lets Get Started: Request For Comment (RFC)
One of the most important guides to understanding and implementing Internet protocols are the associated RFC's (Request for Comment) documents.  These plain text documents can be read with any simple text editor like Windows Notebook or Linux Kedit.  RFC's are not the Internet's Standards however, when a standard is agreed on by the Internet standards committee groups and validated it usually has an RFC associated with it.  RFC's are works in progress in order to establish guidelines for testing, implementing headers and data structures of a protocol or function of the Internet.  RFC's are the most scrutinized documents associated with the Internet's operations and go through a series of changes, testing, and processes before being submitted as a possible standard.  There are also propriety RFCs that have been established by manufacturers of custom and advanced routers like Cisco® and require permission to be used by other manufacturers.  So we will be careful as not to create any new RFC's during this series.  A complete listing of RFC documents may be found on the IETF website linking the RFC index  or a categorized index at the http://www.networksorcery.com/enp/rfcs.htm There are many RFC documents and are categorized as Internet StandardsBest Current Practices and FYI For Your Information., browse these at your convenience.

Four Layers Of The Shared OSI Model: The TCP/IP Internet Suite
There are many experimental networks being developed internally on a closed network that are not publicly released.  Anyone with detailed network knowledge can develop there own internal network with customized routers for experimenting however, if you want to use the Global Internet you have to use one of the active schemes in order for the routers to transport the packets.  The developer may also request a new protocol to be added to the Protocol ID table in one of the 200+ unassigned ID's by submitting the details to the IETF for review.  The concept to keep in mind when sending data over the Internet is, if a router in the Source to Destination path does not understand the data being presented due to errors in format setup or a protocol the router will dump the entire packet at the impasse into the "black hole" of the Internet and terminate the transfer, at which point the router may or may not send a flag that the process failed back to the sender. The termination is different from the the initial connection synchronization from Source-Destination.  Figure 5.0 is a typical Point-to-Point connection showing that routers are the bridge trolls between Point A and Point B and are required to interpret all commands and functions to complete the process.

    Point2Point.jpg
    Figure 5.0  Typical Point-to-Point Connection Through Routers

Before we dive into the OSI model structure we should look at how the information flows between the nodes connected to it.  Figure 5.1 Point to Point OSI Model Data Flow review shows the Encoded side and the Decoded side of the data path.  All information that flows through each end of the model has some sort of data attached.

InternetDataPathFlow
Figure 5.1  Protocol Headers Typical Format

Of the seven layers of the TCP/IP Suite OSI model there is only one hardware layer, the Physical Layer -1. This Physical layer -1 does incorporate protocols however, the protocol is a hardware specification that identifies how the serial 1's and 0's are transferred from device to other devices connected to the same network  The remaining layers 2-7 are software layers that consists of various protocols.  The software controlled layers are the Applications, Transport and Inter-Network layers, the hardware controlled layer is the Data-Link that drives the Physical layer.  Data flow is dependent on the protocol(s) used and encoded as it passes through each layer based on the required protocols used in each layer.  Some protocols are kept on the LAN (Local Area Network) side of the network and not passed through the networks router, while others are passed through the router to the Global Internet ISP router to reach a destination that is outside the LAN connections and should or will return a status and/or other network information to complete the request. OK, that is a bit general, we will break it down shortly.

The Internet protocols are application evoked and are setup for many different network applications; by the end of this series we will understand the handling of protocol processes through the most common used TCP/IP Model.   Protocols are no different that any other software application transferring data, be it the Internet or some internally developed proprietary topology except for the fact that the Internet Protocol Suite is a fixed standard format that once set may be used throughout the millions of routers connected to the Internet.

To show how the TCP/IP OSI Model functions in the real world, a presentation of the four layers with selected protocols we will construct a data flow example through each layer.  Each of the software controlled layers have many protocols assigned to it for many applications.  As we discuss each of the four layers we will present a link that will contain all the protocols and data applied to each layer.  During the presentation we will only list the protocols we will be concerned with in this series.

Keep in mind protocols are just a fixed header format used to identify the data block attached being transported between a source and destination and is given the label name the Protocol Data Unit (PDU).  Protocol headers are the first bits of information being translated as it enters the layer and identifies how each layer is required to handle the attached  "Data / Payload or Datagram" for the next layer in the model.  Figure 5.2 shows the protocol headers typical format and the relationship to the Protocol Data Unit (PDU).

Protocol_Data_Format
Figure 5.2  Typical Protocol Header Format
 PDU (Protocol Data Unit)

Internetwork Link Layer: Shared Data-Link Layer and Physical Layer
This Internetwork layer is where the full frame of the data packet is encoded/decoded, transmitted/received over the physical network (the 1's and 0's serial data stream), be it CatDx cable, FDDI, SONET, Coaxial cable or other types.  Each physical network topology has a fixed hardware protocol specification in order to maintain synchronized communications with minimum collisions from other devices connected on the same network.  

The Data Link layer conditions the packet data to conform to the physical layer data transfer specification.  Keep in mind that there are many different physical layer network topologies and there exists a hardware protocol specification identifying how data is to be processed through it.  Some different network topologies are, WiFi b/g/n, Ethernet, Token Ring, Bluetooth, SONET and others.  All physical layer topologies require some type of synchronous or asynchronous handshake in order to connect to other devices on the network.  

The IoT Core Platform will incorporate an Ethernet network medium interconnect through an RJ45 connector using a Cat6e cable to support a 1Gig bps data transfer.  The Ethernet Packet Frame for the Physical Layer Header Format is shown in Figure 5.3A  how data flows on to the network medium to establish communications over the attached network.

Ethernet_Frame.jpg
Figure 5.3a  Physical Ethernet Layer Frame

Hardware selections and communications for the network interface topologies will be covered in the Hardware, Software and Firmware sections of the series.  For now we will look at the Data-Link / Physical Layer as a simple bi-directional data block that transports data over the Internet as shown in Figure 5.3b Physical/Link Layer Block Diagram below. The complexities of the hardware for the physical layer primarily resides in the hardware category while the protocols being presented reside in the software category and have different process handling.

LinkLayerBlk.jpg
Figure 5.3b  Physical / Link Layer Block Diagram

Due to the fact that hardware protocols are in a fixed medium specification category for transferring data allows network topologies to be connected together with a series of hardware/firmware interfaces that convert one transmission medium to another as required by the environment at hand.  This flexibility allows the "Information Highway" to be a global network converting many types of  network hardware topologies to interact reliably.  Since the physical network topology is only used at the physical hardware level for transporting information the medium headers are stripped from the frame and only the Internet packet information is what is passed through the remaining layers.  As stated we will cover the physical medium in detail during the hardware design part of the series.

Internet Layer: Shared Networks Layer 3 and Data-Link Layer 2
The Internet layer is a group layer that overlaps the input section of the Data Link Layer since the data output of the Network Layer must provide the proper data stream for the physical connection.  For our series we will concentrate on the PPPoE (Point to Point Protocol over Ethernet).  The importance of this protocol is that it allows a connection and authentication between two routers without any host or other layers protocols or data.  In our previous part we stated that the Internet is a Point-to-Point scheme, it requires Source and Destination addresses in order to complete the transaction.  The overlap of the Network and the Data Link layers allow the use of other TCP/IP Internet Suite protocols like OSPF (Open Shortest Path First), RIP ( Routing Information Protocol) and IS-IS (Immediate System to Immediate System).  This layer has also incorporated a protocol to allow end to end notifications of network status such as network traffic congestion without dropping packets.  ECN (Explicit Congestion Notification) must be router enabled at both ends in the router in order to function.  There are more protocols for the Internet Layer depending on the Internet scheme version selected. A link for a full list refer to Internetwork Layer Protocols.  There are also propriety protocols that are owned by router manufacturer companies that reside in this layer as well and may not be available in other manufacturer's routers,  we will cover some of those propriety protocols later.  

ICMPv4 and ICMPv6 Protocol Header
The ICMP (Inter Control Message Protocol) is a support protocol used for network information and status for routers and hosts to inform the sender that the destination could not be reached and other status information.  Generally it does not exchange data from host to host just from network routers to host.  Figure 5.4 shows the ICMP header fields that are the same layout for both ICMPv4 and ICMPv6 and each have their own field notation.

ICMP_Header.jpg
Figure 5.4  ICMPv4, ICMPv6  Packet Format Field Assignments

What makes this layer interesting is it shares part of the Data-Link layer, interesting because the Data-Link layer also is shared with the Physical layer and the interaction allows specific protocols like Multi-cast, Broadcast and Unicast and Anycast without the OSI's strict header requirements as with other network schemes.  Communications for these types of protocols are handled router to router and device to router and back to device without host intervention.  The router in many of these cases handle network scanning of devices connected and returns requested network status information to the sender.  Some protocols require the host keep track of devices connected for inter-communications over a LAN as is with IPv4 that keeps the network users IP and associated MAC addresses in a buffer within each networks connection Operating System.  The field parameters are available several places on the Internet and may be viewed through the links,  ICMPv4  RFC 702  for IPv4 and ICMPv6  RFC 4443 for IPv6.  Field assignment parameters cover the full capability of the protocol, we will cover a simple implementation to understand the flow of the protocol at this time in the series.

End to End Layer:  Shared Session Layer 5 Protocols and Transport Layer  4 Protocols
There are a few protocols that are mostly used within this layer, they are shown in Table 5.0 End-to-End Layer Protocols.  Our intent is to show how protocols are implemented in order to have a flexible IoT Core Platform that is capable of incorporating protocols as needed for any specific application.  We will cover only the Transmission Control Protocol and User Datagram Protocol for this part of the series to understand the typical protocol implementation process.

Protocol

Full Name

Description Summary

TCP

Transmission Control Protocol

TCP is the dominant protocol that provides reliable, ordered packets with error checking and congestion control delivery between hosts over an IP network.

UDP

User Datagram Protocol

Used to send message(datagrams) to other hosts point to point IP network. Direct point to point data paths.

SCTP

Stream Control Transmission Protocol

A message based protocol for multihoming multiple IP to maintain connection for multiple streams of data end-to-end.

DCCP

Datagram Congestion Control Protocol

Provides a way to get congestion control without going through the Application Layer.

RSVP

Resource Reservation Protocol

Used to reserve setup reservations for multicast or unicast data flows- No data transport just setup routes.

Table 5.0  End-to-End Layer Protocols

TCP Protocol Header
The Transmission Control Protocol  RFC 675 December 1974 is without doubt the dominant protocol used throughout the Internet.   The field assignments are found in this link, TCP Field Assignments, of which we will break down and cover the categories of how this protocol functions through the End-to-End Layers as the series continues.  The TCP is the key synchronization protocol for creating a connection Source to Destination hosts on the Internet and uses the Internet's "Three-Way-Handshake"  that we will cover in the next part of the series.  The TCP incorporates ordered octets as well as error checking on hosts running applications through the IP network.  Web (HTML) applications, E-Mail(SMTP, POP), File Transfer(FTP) are only a few that rely on the TCP for accurate data transfer.  TCP also incorporates a congestion control methodology called Additive Increase / Multiplicative Decrease (AIMD) algorithm.  We will cover AIMD as well as  ECN (Explicit Congestion Notification) as we proceed through the series.  TCP has gone through many RFC revisions from its original 1974  IEEE publication A Protocol for Packet Network Communications, later renamed Transmission Control Protocol, the latest RFC-7414  Feb 2015.  The TCP header is shown in Figure 5.5 below.

TCP_Header.jpg
Figure 5.5  TCP Format Field Assignments

UDP Protocol Header
The User Datagram Protocol  RFC 768  is a quick non-critical, reduced latency data transfer protocol that is a connectionless datagram service that  is less reliable than TCP.  There is no handshaking communications between source-destination.  UDP does provide source- destination ports to handle several applications type protocols. The UDP header is shown in Figure 5.6 below.

UDP_Header.jpg
Figure 5.6  UDP Header Format Field Assignments

Application Host Device Layer:
Shared Application Layer 7 Protocols, Presentation Layer  6 Protocols and Session Layer 5 Protocols

The Applications layer handles a lot of the grouping of the users application data to be transported.  The TCP header is the same TCP header in Layer 4 and at this level the data is segmented or fragmented into smaller packets which the TCP keeps track of the data flow.  Streaming of the data flow is handled by a different set of protocols.  This is probably the most flexible area of the model since the user has more control of the data types as well as data manipulation to be transported as long as source encoding and destination decoding are a matched pair.  The initial protocols for this area to be incorporated into the IoT Core Platform are  BGP (Border Gateway Protocol) , SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), NPT (Network Time Protocol), PTPv2 (Precision Time Protocol Version 2) all having their own headers and application requirements, from a list of 100 plus protocols and there is still over 150 unassigned protocol IDs available for future development; protocols can easily become a career education in itself.  We will address the detail requirements to implement the above mentioned protocols during the Software/Firmware parts of this series as we design the code for the protocols.  Refer to the links provided for an outline of each of the protocols.  All of these protocols along with their organized header and field requirements may also be found at http://www.networksorcery.com except for the Precision Time Protocol that is an IEEE standard and may be found at IEEE-1588.  

For the IoT Core Platform as presented earlier to be used with multiple IoT devices in a range of applications for control we would require a precise time synchronization mechanism for multiple devices.  The NTP (Network Time Protocol) standard is a relative low resolution time synchronization and will synchronize many servers, desktops and devices to the second efficiently however, the Precision Time Protocol has accuracy capability in the sub-microsecond resolution for Local Area Networks.  The Application Layer is considered the User Data Segment (UDS) and contains the user data to be transported and does require an IP header associated with the Internet scheme being used.

Packet Switched Networks:
Application Layer, Transport Layer,  Network Layer , Physical Layer  = Protocol Data Units

Now that we presented the TCP/IP Suite grouped Four Layer OSI model we will present how the data is transported through the layers.  Since each layer is required to process the data that is attached to it independently of the remaining layers the IP scheme encodes/decodes a block or packet of data at a time. This packet has been given the name PDU (Protocol Data Unit).  The PDU allows each layer to attach routing, network and other information the protocol used on the current layer before sending the PDU to the next layer in the model.  The Source encodes each PDU and recombines them for transport to the Physical Layer (1's and 0's) and decodes each of the layers PDU in reverse order at the Destination as shown in Figure 5.1 above.  Table 5.1 shows the typical Protocol Data Units. PDUs are just a way of organizing each layer.

Layer Name

Data Block Name

Reference Info

Application Layer 7

User Data
FTP, HTTP, POPS

For HTTP it is a web html file, for POP it is a SMTP and Data PDU

Transport Layer 4

TCP = Segment,
UDP= Datagram

For TCP it is the TCP Header and Data, For UDP it is the UDP header and Datagram

Network Layer 3

Packets

The Network - IP header + Segment = Packet

Ethernet Layer Physical

Frame

Combined it is the Frame that is 1's & 0's

Table 5.1  PDU - Protocol Data Unit Each Layer

The processing of all the layers PDU's form a new network entity called the Switched Packet. The switched packet follows the physical layers requirements to transfer data on to the network and is givien a parameter called the MTU (Maximum Transmission Unit) which are all part of the Packet Switched Network block.  The MTU is the total bytes(octets) in a single Switched Packet that is transported over the network.  In order for the MTU to be transported it has to conform to the network topology it is connected to(the Physical Layer), this means it must be attached to a medium hardware and conform to the hardware protocol specifications in order to be put on the network.  Figure 5.7 below shows the relationships of the PDU, MTU and Frame.  Keep in mind that for very large data transports the Protocol Segment or PDU may be fragmented in which the Protocol Header will maintain the fragmentation counter and data pointers.  The local network medium will normally have some sort of start sequence to synchronize the beginning of the MTU data then have some sort of stop/end transmission medium synchronization usually with a checksum or some type of MTU data checking methodology to insure the frame was sent with no errors.

PDU_MTU.jpg
Table 5.7  PDU - MTU - FRAME  Relationships

Maximum Transmission Unit (MTU):  Protocols and the MTU
Since we covered the TCP/IP Internet Suite model and a few protocol formats it would make sense to have an ordered packet delivery mechanism regardless of the protocol header size.  The way that data is transported on a switched packet network is obviously by (wait for it) "packets", so now enters the Maximum Transmission Unit (MTU) which is the physical packet size in bytes.  Every network topology has an MTU and the size varies with the network topology.  Since protocol headers are a fixed size, then the size of the data has to be adjusted to the MTU size, hence, packing the packet.  For those packets that are less than the MTU the packet is zero filled, for the data size greater than the networks MTU fragmentation is required to transport the data.  The standard MTU size for the Ethernet topology switched packet network is 1500 bytes for the payload.  We would like to transmit packets that fit nicely into the MTU without fragmentation, however with today's data that is very rare.  MTU size is a function of the Physical Layer protocol as well as the network it is on.  

Table 5.2 below shows a few variations of MTU's with different network topologies.  The issues with MTU sizing is, if it is too small some protocols like IPSEC may not work well and if it is too large it slows the network due to long data transfer periods.  We will discuss this in detail when we enter the hardware section of this series.

Network Topology

MTU
Bytes

Reference Notes

Maximum MTU

65535

RFC1191 Maximum MTU bytes defined

IBM Token Ring -16Mbps

17914

RFC1191  variations are outlined in the RFC link

IEEE 802.4 Token BUS Network

8188

RFC-1042   variations are outlined in the RFC link

IEEE 802.11xxx (Wireless LAN)

2304

Media Access Control (MAC) and Physical Layer (PHY) spec IEEE-802.11 (2048 bytes data + 256 bytes layer protocol)

IEEE 802.5 (4Mbps) Token Ring LAN

17792

IEEE 802.5 - 17800-8bytes for LLC header

SONET

4474

4470 bytes Data, 4 bytes Header

Ethernet

1500

1508 bytes - 2 bytes for CRC and 6 Bytes for overhead = 1500

Point-to-Point PPoE Standard

1492

Total is 1500 - 8 bytes, 2 bytes for CRC and 6 Bytes for overhead

Point-to-Point PPoE Non-Standard

1500

RFC4638 non-standard frame of 1508 bytes - 2 bytes for CRC and 6 Bytes for overhead

IEEE 802.3 xxx

9000

Jumbo Frames - reference IEEE-802.3

SLIP / PPP

1500

Varies on Speed - Default 1500-8 = 1492 RFC-1055

Internet IPv4

 

Varies on Network Configuration  Min 68

Internet IPv6

 

Varies on Network Configuration Min 1280 RFC2460

Minimum MTU

68

RFC1191

Table 5.2  MTU Size For Various Network Topologies

 

Putting It All Together For The Next Part Of The Series:

  • The Internet Protocol is a "Packet Switched Network" Scheme as we see from above that the packet size varies for different network topologies.
  •  In order for different network topologies to be connected together an interface that converts one topology to another is required to insure that data transport integrity is maintained.  Many of these interface conversions are already in place today such as DSL, Cable, WiFi etc.
  • There are unique hardware protocols to synchronize data flow over the selected network topologies.
  • Each Layer of the TCP/IP OSI Model incorporates its own Protocol Data Unit (PDU) which is encoded by the Source (sender) and decoded by the Destination (receiver).
  • Each PDU has a protocol header to identify the protocol data attached to be processed.
  • Each layer of the TCP/IP OSI model determines if the data flow is completed and will end the connection or proceed to the next layer and handle the data for that layer.
  • There are many field assignments for the protocol suite that will take a fair amount of time to present them.  We will present the main protocols and their implementation into the IoT Core Platform, then as the series progresses we will add protocols by request of the readers.
  • As long as you follow the rules of the packet switched network and want to experiment with the different schemes you are free to use any of the available protocols, test the limitations and evaluate the performance.

Part 6 overview will cover a continuation of protocols
How the user data is synchronized and transferred through the OSI model layers.  The source/destination handshake connection process. How message protocols interact with the Internet routers and hosts for network status and information.  Selected protocol details, the TCP from point to point, The Unicast, Multicast protocols assigned IP addresses and expected responses from them. Once we cover the standard protocols and set the core process of how protocols communicate through different layers we will then begin the design process of the IoT Core Platform Hardware/Firmware and Software requirements.


Part 1 Introduction - Setting the Atmosphere for the Series (September 26, 2016) 
Part 2 IPv4  IPv6 - The Ins and Outs of IP Internet Addressing (November 11, 2016) 
Part 3 IPv4, IPv6 DHCP, SLAAC and Private Networks - The Automatic Assignment of IP Addressing (November 24, 2016)
Part 4 Network Protocols - Network, Transport & Application (January 10, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 2017)
Part 7 Network Protocols - Network, Transport & Application -Continued -CRC-32 and Checksums (Nov 23, 2017)
Part 8 IoT Core Platform - SoC Core Processor of Embedded Systems (Jan 12, 2018)
Part 9 IoT Core Platform - SoC Core Processor of Embedded Systems -Vulnerabilities (Mar 16, 2018)
Part 10 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management (Apr 5, 2018)
Part 11 IoT Core Platform - SoC Core Processor of Embedded Systems -Documentation Management Processes (June 27, 2018)
Part 12 IoT Core PlatformIoT Core Platform - Product Design -Creating Conceptual Design Documentation (July 29, 2018)
Part 13 IoT Core Platform - Peripheral Interface Devices - Peripheral Design From the Beginning (Oct 7, 2018)
Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)
Part 15 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Dec 7, 2018)
Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)
Part 17 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Mar 15, 2019)
Part 18 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing -Continued(Apr 25, 2019)


Reference Links for Part 5:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet  and the Network Sorcery web site. The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.  Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:  http://www.networksorcery.com
The Internet Engineering task Force:  IETF - RFC references
Wikipedia  https://en.wikipedia.org/wiki/Main Page


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.

BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-5 IPv4, IPv6 Protocols, Network Transport & Applications:  Continued

For Website Link: cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=10&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-5 IPv4, IPv6 Protocols, Network Transport & Applications: <i>Continued (Aug 21,2017)</i></a></p>

 

Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn

 

«Previous   1 2 3 4 5 6 7 8 9  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster