BASIL_NETWORKS


Designed & Made
in America (DMA)

ABOUTABOUTPRODUCTSSERVICESSUPPORTCONTACTARTICLESBLOG
BASIL Networks BN'B | Internet of Things (IoT) -Security, Privacy, Safety-Platform Development Project Part-5

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-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)

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)


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

 

 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster