Designed & Made
in America (DMA)

BASIL Networks Blog BN'B | September 2017

24 Sep, 2017

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

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


Quick review to set the atmosphere for Part 6

From the previous Internet of Things Part-1 through Part- 5:

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

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.

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.  

Figure 6.1a  802.3 Standard Ethernet Physical Protocol Header Format

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

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.

Figure 6.2a  802.3 Standard Ethernet Header Frame Structure

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


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]

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

Internet Protocol version 4 (IPv4)


EtherCAT Protocol for Automation


Address Resolution Protocol (ARP)


GSE (Generic Substation Events) Management Services








Provider Bridging (IEEE 802.1ad)


Stream Reservation Protocol


MAC security (IEEE 802.1AE)


Reverse Address Resolution Protocol


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


VLAN-tagged frame (IEEE 802.1Q)


TTEthernet Protocol Control Frame (TTE)


QNX Qnet


Internet Protocol Version 6 (IPv6)


PPPoE Discovery Stage


Ethernet flow control


PPPoE Session Stage


Ethernet Slow Protocols


MPLS unicast


MPLS multicast


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.

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.

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.

Figure 6.4b  Captured Ethernet Header Frame Inbound

Summary for Part 6:

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

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.

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:
The Internet Engineering task Force:  IETF - RFC references

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)


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="" 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

Copyright© 1990-2019 BASIL Networks, PLLC. All rights reserved