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

 

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

saltuzzo | 10 January, 2017 09:27

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

An Investment in knowledge pays the best interest. - Benjamin Franklin

Personal note to the readers:
The Internet is an information playground for some and for others it is more than just a playground, it is a learning area for all types of knowledge to be applied and experimented with.  My experience over many years was the honor to be mentored by some of the most knowledgeable individuals in the industry. This series is dedicated in there honor, some of my mentors are not with us and are dearly missed however, the knowledge they shared with many is now the foundation for others to grow.

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 5 Network Protocols
- Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 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)

Lets Get Started:  Quick Review to Set the Atmosphere for Part 4
This educational series involves several disciplines and concepts that should be kept in mind while occasionally branching off in order to tie all the disciplines, concepts and strategies together; incorporating them into our main objective of creating a core IoT hardware/software platform that gives the user full control of security, privacy and configuration.  This part will be a reference section to the series since we will be returning to cover the set of selected protocols during the design and development process.

From the previous Internet of  Things Part-2 & Part-3 we have established that the Internet is just an "Information Highway" a transport agent, the IP address is just a single point on that highway and that the Internet Protocols are a methodology or road map for the transport agent to carry the application information from point A to point B.

We presented the fact that IPv4 is coming to the end of its addressing capacity and IPv6 will be replacing IPv4 eventually; holding your breath waiting is not advisable.  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 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 just a neglitable block of addresses to the overall address range of the IPv6 scheme.  To clarify this, the IP address 0000:0000:0000:0000:0000:0000:64.139.76.51 is a true IPv6 address and would be represented as ::408B:4C33 which is an IPv4 address and will function only if the connected devices are IPv6 aware.  BASIL Networks is an IPv4 only network and if you enter http://[0000:0000:0000:0000:0000:0000:408B:4C33] you would get a "Server Not Found" message from your browser, however if you enter http://[0000:0000:0000:0000:0000:FFFF:408B:4C33] the BASIL Networks web page will appear.  This is the IPv6↔IPv4 dual stack address translation block to handle all IPv4 addresses seamlessly.

We presented the throughput and bandwidth issues that, unfortunately will always be an issue within the Internet environment for both IPv4 and IPv6, also any other scheme that is implemented. The bandwidth issue is due to the fact that bandwidth is an "income producing product" for service providers.  The more bandwidth the faster throughput, the higher monthly charge for the connection.

Protocols: They're Everywhere, They're Everywhere! 
Protocol - Computer Science Definition - A specific set of rules defining a procedure for data transmission between computers (should be changed to devices to be more applicable today).  Protocols are one of the more challenging aspects of any communication process; some simple, some complex, confusing at times and they will without doubt challenge your mind and develop critical thinking with continuous probing and questioning subject matter; welcome to the world of communication protocols.

To narrow the protocol objectives for this series we will be focusing on the TCP/IP Internet Protocols Suite.  This is a unique group of TCP/IP protocols that are used throughout the Internet and required by every device that is "connected".  Protocols are part of the P2P pathways that allow communications though a series of connected routers, just like exits off highways, and are the backbone of the Internet.  Routers connect countries (Global ID), Internet Service Providers (ISP), SOHO, large companies etc. to a local user network down to the end point node, desktop, laptop or smartphone.

Routers that cross boarders into other countries, states and so on are all part of the "Information Highway" roadmap and are considered border crossings and are given the name Border Gateway Protocols (BGP) just like driving across borders where you have to pass through customs and if you break protocol while at the border you are detained.  When we discuss protocols for the Internet they are 99% software in origin, the remaining 1% are the hardware protocols which are fixed and relate to hardware interconnect methodologies at the data bit by data bit serial level such as RJ45 copper wired connector, Fiber Link optical connection, WiFi, Bluetooth, wireless connection and others.  Protocols, routers and devices inter communications are all interwoven throughout the Internet in various states and used to maintain the stability and uniqueness of every device on the Internet.  

In IPv4 devices on the LAN were configured on the LAN and communications data was Translated through NAT to the Internet Point to Point and the devices physical signatures were kept local to the connected LAN that the IPv4 routers controlled.  In IPv6 the device signatures now play an important roll in the communications throughout the Internet and are used to creates a unique IP address.

Before we get into the complex world of protocol details lets look at a high level overview of the Internet data flow.  Figure 4.0 shows the data flow of the "Hello World" phrase that is used in just about every compiler and assembler as a test case.  Our core IoT Platform requires an interfacing flexibility to be able to attach to any application, format the data from the application and transport it over the Internet to a specified destination.  This reduces down to two major components, the application interface for the sensors that generate the application information, and the network interface that the application information is attached to for transportation over the "Information Highway" the Internet.  The network interface we will be presenting is the TCP/IP OSI (Open System Interconnection) model as shown in Figure 4.1 by layers 1 through 7.  No data is transported without the use of protocols that are layered and grouped in the TCP/IP OSI model.   OK, now that we understand that the "Information Highway", Internet is a point to point transport agent or scheme lets inhale slowly and exhale slowly and get started.

Internet_Data_Flow
Figure 4.0  Internet Data Flow - TCP/IP OSI Model - Point to Point

Protocol Classifications: The TCP/IP OSI (Open System Interconnection) model
There are basically two classification types of protocols, hardware and software, wow just two? Yes, just two, Well then! guess it can't be that difficult to understand protocols.  Protocols are not difficult to understand, there are just a lot of them and sometimes grouped in the same block of data being transported.  The hardware protocols used may transport any type of network information on any type of scheme. What makes the hardware unique is the interaction of the network scheme being used, in our series this is the Internet IPv4 and IPv6 schemes.  The most common hardware protocol schemes are shown in Table 4.0 which are fixed hardware topologies that must have a fixed software interface to receive and decode the data.  There are NAD (Network Access Devices) such as switches, HUBs, Wireless Access Points (WAP); there are Inter-networking devices such as routers used to transport datagrams point to point. These Network Interface Controllers (NIC) rely on a stable crystal controlled reference to decode the serial bit stream for the communications.  There is no separate clock line to synchronize the data stream being transmitted or received, therefore the hardware decoding is defined as asynchronous communications, relying only on a start and end of a fixed bit stream length.  If the controller breaks the timing a network collision happens and the NIC sends a sync handshake stream back to the sending address to resend the packet/datagram.

Hardware Protocol Name Hardware Physical Interface Tx/Rx Range Interconnect Topology General Throughput Rate
Ethernet Twisted Pair RJ45
(Cat XX Cable)
200 Feet, 60 Meters+ Full Duplex 1, 2, to100 to 1000 Megabits/sec
FDDI (Fiber Distributed Data Interface)

Token Ring Dual Ring Tree  X3T12

200 KM, 120 Miles All RX / One TX - Half Duplex 32 to 100 Mbps
ATM (Async Transfer Mode)

SONET/SDH

200 KM, 120 Miles SONET Connector 155.520 Mbit/s OC3  to 38.48 Gbits/s OC768

Table 4.0  Common Hardware Interconnect Schemes

The TCP/IP OSI Model:
The OSI (Open System Interconnection) model is a general network model that is used throughout the industry to represent many types of networks.  Figure 4.1 shows how the OSI model layers are grouped and applied to TCP/IP Internet Protocol Suite showing their assignment to each layer which is commonly called the TCP/IP OSI model.  The design of protocols for the TCP/IP network OSI mode is a lot more flexible than the strict structure of other categories of  OSI model networks.  The IP addressing scheme is used primarily as a transport mechanism or agent and concerns itself first with the end to end encoding-decoding of the data, hence P2P.  The TCP/IP OSI model is grouped into four areas that overlap some of the seven OSI model layers when used with the TCP/IP Internet protocol scheme.  The Internet Link Layers,1 and 2 are a major concern since they deal with how the device(s) connected will coincide with other devices traffic, collisions and interactions.  Too many collisions or conflicting traffic yields poor QoS (Quality of Service) and degrades the overall network performance.  Poor QoS may also be due to many other areas such as poor wireless connection as too many walls between the wireless devices, poor cable quality for direct wired devices such as the wrong type of cable CAT5, 6 etc, or just poorly designed devices which is what we will assure will not happen with out core platform design.  The remaining three groups are used to encode-decode the data range and manage sessions on the network.  

For the TCP/IP OSI model there are four groups, one hardware group(physical layers) and three software protocol groups, the software groups are the NP (Network Protocols) which handles all inter router communications like the ICMP messaging that control and manage the network, the TP (Transport  Protocol) like TCP, UDP, which is used as a container to inform the router the type of protocol is being used to transport the user data information in the container, the AP (Application Protocol) like HTTP, SMPT, FTP, which is the actual data protocol the user data is formatted to that is inside the TP container.  Network protocols are fixed by IANA and ICANN groups and any new network protocols must be approved by those groups and registered with an RFC number before it may be used on the Global Internet. Private networks that are not connected in any way to the global Internet are open to experiment with different Application Protocols.  The Applications protocols are also IANA registered protocols however how the user formats the data within these application protocols is completely flexible and do not have to be registered.  This allows the user to transport raw, encrypted and/or formatted data P2P and process it accordingly.  All that is required is that the user follow the network rules for the NP, TP and AP groups.  Simple, just as you are reading this block with your browser, the maim port ID is 80 which is assigned the HTTP protocol and is in the application layer.

TCP_IP_OSI_Model
 Figure 4.1  OSI Model Layers with Associated Protocols

This brings us to the next step in understanding protocols, reviewing Figure 4.0 Internet Data Flow lets take a look at what actually flows over the "Information Highway" once it leaves the physical layer-1.  Since IPv6 is not fully implemented globally we have to take into consideration both IP schemes.  In order for these two different schemes to be recognized over the same transport agent lets take a look at the transmission format that is traveling over the network.

IP Header Formats: How the data is transmitted
All Internet network traffic is encapsulated in a network protocol block as shown in Figures 4.2, 4.2A & 4.2B, so lets take a closer look to see how this header identifies both IPv4 and IPv6 to seamlessly share the same network.  Keep in mind that Internet traffic is controlled or activated by addresses, so all we have to do is isolate a the control address block and give it a unique address like FFFF:[IPv4 Address] and it looks like an IPv6 address, then send it down the Internet for the routers to determine the type of scheme and the shortest path a different path for the block of ::FFFF: IPv4 addresses.

Figure 4.2 and Figure 4.2A shows the functional block diagram for all IPv4 Internet traffic and Figure 4.2B shows the functional block diagram for all IPv6 Internet traffic.  These control blocks allow many different protocols and data formats to be transported across the Internet, Figure 4.2 shows the IPv4 Network Protocols (NP) for communicating with other routers and servers.  Figure 4.2A shows the IPv4 P2P user information control block, TP and AP.  Figure 4.2B shows the new IPv6 header block.  Notice that both Network Protocols (router intercommunications) and Transport Protocols encapsulating the Application Protocols are now part of the IPv6 Data Block placed just after the IPv6 Header.

IPv4_NP_Block
Figure 4.2  IPv4 Network Router Request

IPv4_TP_AP_Block
Figure 4.2A  IPv4 Datagram Transport Block

IPv6_Transport_Block
 Figure 4.2B  IPv6 Header Block

An IP header is required for any network scheme, what makes them unique is the information or fields within the headers.  Both IPv4 and IPv6 schemes, the IP Address Header identifies the source and destination addresses, where they become different is that IPv4 header identifies the NP (Network Protocol ), TP (Transport Protocol) and AP (Application Protocol).  For IPv6 the NP, TP and AP blocks are now located in the data block following the header and are identified within that block through out the network path.  Remember that regardless of the scheme they all must contain the protocols to carry user data P2P.

The Transport Protocol selected is the container that the Application Protocol will be placed in for transport. Tranport Protocols must also be recognized by the network routers transporting the data, else the data is just dumped and transmision is terminated.  Many of the NP communications are transparent to the end users and are primarily used to insure the QoS (Quality of Service) for the overall  network.  These NP's handle many transparent functions such as DNS (Domain Name Service) servers that have the ICANN domain names to IP addresses, ISP (Internet Service Provider) routers to your local router at the end users connection.  The Internet (Information Highway) is just the transport agent as any transportation highway and require some fixed rules.  What makes this transport agent work are the interconnecting routers and servers specific communications with fixed Network Protocols, hence, "protocols are the heart of the Internet".

Figure 4.3 shows the IPv4 header, RFC791 and Figure 4.4 show IPv6 header, RFC2460, as we see they are displayed in 32 bit format, grouped in Octet (8 bit) format.  The reason for this format is based more on the 8 bit octet for NIC (Network Interface Controller) hardware to guarantee a fixed byte protocol compatibility standard.  Reading a block of data in byte form at high speeds allows for better data integrity and less skewing. Every desktop, Laptop, Smartphone, Tablet etc incorporates a NIC of some sort that complies with the software protocol formats.  This is what allows the Internet to function as efficiently as it does.  There is no magic in any of this, just pure logic and technical book keeping of the different protocol processes.  

IPv4 has more information in the header that identifies the attached data packet.  The type of IP header and block NP or TP depends on the type of payload, a network protocol or an application protocol.  Again all that is required to transport data P2P is to follow the Network Protocols and the Transport Protocols, both are required by the Internet routers to insure the transport of the Application Protocol P2P is completed.  The end nodes require that the Application Protocols are matched in order to encode/decode the data being transported.

There is only one difference between the Internet header bit assignments and the standard computer technology bit assignments, that is the identification of the LSB (Least Significant Bit); in the computer world the LSB is bit 0 is weighted right to left MSB…LSB to coincide with the 20 =1 weighting binary representation of the decimal numbering system.  In the Internet headers and serial bit streaming digital world most serial communications send the MSB (Most Significant Bit) first and the LSB last which is why the nomenclature is reversed.  When we get into the core hardware design this MSB-LSB difference will be continued.

IPv4_Header
Figure 4.3  IPv4 Header Block

IPv6_Header
 Figure 4.4  IPv6 Header Block

IPv4 Header Fields:
Table 4.2 below shows the header fields for IPv4 and 4.3 shows the header fields for IPv6.  The smallest IPv4 header is 20 octets (00-19) with options upto 36 octets.  The IPv6 header is fixed at 40 octets and any further information is attached to the data area following the header.  Like all designs that evolve IPv4 was the first of its kind and as an engineer and designer the first thoughts of what it should to is "Everything" that a network should do!  OK, and what is "Everything"?  The answer for IPv4 is all those different fields in the header, the answer for IPv6 is the same but with less fields and a different organizational methodology for the protocols that allow for the experiment of different schemes since the header is fixed.  Remember all that has to occur to run a different scheme is to add additional firmware to the Network Protocol part of the routers on the Internet.  There are provisions to select the path through some customized routers that experiment with the next generation of Internet schemes.  Keep in mind that IPv6 has all the functionality of IPv4 with some improvements and added functionality for controlled communications.  With IPv6 the data after the header is identified in the "Payload Length" field parameter of the data attached.  All protocols incorporated are in the data attached this includes inter router Network Protocol communications.  The three protocol areas still must hold in order to be compliant with the OSI model, the only difference is where they are defined in the data block.  The P2P IP addresses are always placed in the IP header regardless of the scheme.  This is to insure that the P2P addresses are expected to have the same protocols used for encoding/decoding.  Which enforces the fact that IPv4 and IPv6 are just schemes to transport data and the Network Protocols inter router communications are the highway signs to direct the data to the destination node.

Decoding The Header Fields:
The first 4 bits (Version) of the header are used to identify the IP scheme version, this is how the Internet separates the type of  Internet Protocol schemes.  These 4 bits allow room for up to 15 different IP schemes as shown below.  This is how the schemes are separated and redirected to the software protocol decoding that applies to the scheme. A different scheme would require the update of the routers and servers on the Internet to accommodate the new scheme, for this series we will focus on IPv4 and IPv6.  As we see IPv4 and IPv6 headers are very different in how they are processed and to date there are many more IPv4 devices being used than IPv6 devices at the users level.  We will present both schemes in order to effectively develop our core IoT platform to function on both systems seamlessly.

The Version field in the header Bits 0-3 of Octet 00, (00-15 decimal), 0000-1111 binary, MSB…LSB identifies the IP scheme version.  There are other experimental protocol version being developed, the RFC (Request For Comments) numbers are associated with these protocols in the table, the Version table is defined in RFC1700.  By putting the IP version type in the first Octet bits 0-3 many different schemes may be used for the same transport mechanism.  The main requirement is that any protocols used for the scheme are expected to be identified and capable of encoding/decoding the data at each node.  The streamlining of the IPv6 header easily allows for new schemes to be developed as long as the inter router communications are able to identify and apply the new protocol schemes, if not the data is just dropped and the transmission ends at that point.

Many of the IPv4 fields are moved to the data area in IPv6, the requirements are still there just move for convenience and efficiency.  The largest section in the table is the protocol field of the IPv4 header which is set at the end and is also is the one we will be concerned with mostly for out core IoT platform.  The IPv4 Header is generally part of the TCP/IP Internet Suite and there are many third party libraries available to implement into a custom device development.  The TCP/IP Internet Suite is also designed into many operating system platforms like Linux®, BSD® Unix, Windows®, MAC OSx® and others.

Name Bits (Size) Octet # RFC Number Description
Version 0-3
(4 bits)
0

RFC1700

Internet Protocol header Version 4 bits, IPv4 = 4

Version Description Version Description
0
(0000)

Reserved

8
(1000)

PIP  P Internet Protocol  RFC1621 - RFC1622

1
(0001)

Unassigned

9
(1001)

TUBA  TCP+UDP+Big Address RFC1561

2
(0010)

Unassigned

10
(1010)

Unassigned

3
(0011)

Unassigned

11
(1011)

Unassigned

4
(0100)

IPv4 Internet Protocol RFC791

12
(1100)

Unassigned

5
(0101)

ST  ST Datagram Model RFC1819

13
(1101)

Unassigned

6
(0110)

IPv6 Simple Internet Protocol  RFC2460

14
(1110)

Unassigned

7
(0111)

TP/IPC  Next Version Internet  RFC1475

15
(1111)

Reserved

Name Bits (Size) Octet # RFC Number Description
IHL 4-7
(4 Bits)
0  

Internet header Length 4 bits. This is the IP Packet header word in 32 bit format. The minimum value for this is 5. The Option Octets 20-31 will add to this number.

ECN 14-15
(2 Bits)
1

RFC3168

Explicit Congestion Notification - Used for point to point packet loss, used with VPN tunnels.  All points along the way have to include this feature in order to function.   ECN=00-Not ECT, 01-ECT(1), 10-(ECT(0), 11-CE

Total Length 16-31
(16 Bits)
2-3  

This is the total length of the payload/packet size - The header size in not part of this number.  The max length is 65535 (16 bits)

Identification 32-47
(16 Bits)
4-5 RFC6864

The 16 bit IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol.

Fragment Offset 19-31
(13 Bits)
6-7

RFC791
RFC815

In the routing of messages from one Internet module to another, datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram.  To overcome this difficulty, a fragmentation mechanism is provided in the Internet protocol.  RFC791 explains fragmentation and RFC815 explains the recombining of the fragments process.

Time To Live 0-7
(8 Bits)
8  

An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on an Internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1.   In practice, the field has become a hop count - when the datagram arrives at a router, the router decrements the TTL field by one. When the TTL field hits zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the sender. The program trace route uses these ICMPvX Time Exceeded messages to print the routers used by packets to go from the source to the destination.

Header Checksum 16-31
(16 Bits)
10-11 RFC1071

The Header Checksum has several updates RFC1141  to RFC1624  It is the checksum of the header only that is calculated by the router during transmission. The payload checksum is not calculated in order to reduce the time to transport.

Source IP Address 0-31
(32 Bits)
12-15  

This is the full 32 bit source IP address - the sender

Destination IP Address 0-31
(32 Bits)
16-19  

This is the full 32 bit IP address of the destination - the receiver

Options (IHL>5) 0-31
(128 Bits)
20-35  

 

ECN 14-15
(2 Bits)
1

RFC3168

Explicit Congestion Notification - Used for point to point packet loss, used with VPN tunnels.  All points along the way has to include this feature in order to function used for point to point packet loss, used with VPN tunnels.  All points along the way have to include this feature in order to function.  ECN = 00-Not ECT, 01-ECT(1), 10-(ECT(0), 11-CE

DSCP 8-13
(6 Bits)
1

RFC2474 
RFC2597

Differential Services Code Point - This is used for protocols like VoIP, Media etc -   RFC3265 Session Initiation Protocol.  Other RFC that apply   RFC5865   RFC2598   RFC3246
The RECOMMENDED values of the CS (Class Selector)  and AF (Assured Forwarding) codepoints are as follows.

DS CodePoint Description DS CodePoint Description DS CodePoint Description
0   (000000) Class Selector 0 - RFC2474 10 (001010) Assured Forwarding 11 - RFC2597 10 (001010) Assured Forwarding 33 - RFC2597
8   (001000)

Class Selector 1 - RFC2474

12 (001100) Assured Forwarding 12 - RFC2597

34 (100010)

Assured Forwarding 41 - RFC2597
16 (010000)

Class Selector 2 - RFC2474

14 (001110) Assured Forwarding 13 - RFC2597

36 (100100)

Assured Forwarding 42 - RFC2597
24 (011000)

Class Selector 3 - RFC2474

18 (010010)

Assured Forwarding 21 - RFC2597

38 (100110)

Assured Forwarding 43 - RFC2597
32 (100000)

Class Selector 4 - RFC2474

20 (010100)

Assured Forwarding 22 - RFC2597

44 (101100)

Capacity Admit'd Traffic - RFC5865
40 (101000)

Class Selector 5 - RFC2474

24 (010110)

Assured Forwarding 23 - RFC2597

46 101110

Expedited Forwarding PHB - RFC3246
48 (110000)

Class Selector 6 - RFC2474

26 (011010)

Assured Forwarding 31 - RFC2597    
64 (111000)

Class Selector 7 - RFC2474

38 (011100)

Assured Forwarding 32 - RFC2597    
Flags 16-18
(3 Bits)
6  

Fragment Identification Status    
Bit-18 MF  =1  Do Not Fragment - used with PMTUD (Path MTU Discovery) RFC191
Bit-17 DF = 1 More Fragments in route - in the last packet this bit is set to 0
Bit-16 R =Reserved=0

R-16 DF-17 MF-18 Description
0 1   Fragmentation required to route the packet the packet is dropped
0 0   Do Not Fragment - used with PMTUD (Path MTU Discovery) RFC191
0   1 More Fragments in route - in the last packet this bit is set to 0
0   0 No More Fragments in route   R=Reserved=0

The protocol field identifies the different Transport Protocols (TP) available.
The protocols highlighted are the ones we will be addressing for the core IoT platform development.

Protocol 8-15
(8 Bits)
9  

The following is the latest Internet Protocol IANA assigned numbers, RFC1700, along with the latest reference RFC# document.  Each RFC will have a back trace to the original RFC from the original release.  There are a lot of protocols that have evolved over the years and I am sure this list will be upgraded many more times. The IPv4 only allows for 254 protocols however IPv6 the protocol is defined in the following header.  A full list of the IANA protocol registry from A to Z.  These Protocol Number ID's are not the same as the Port Protocol ID's.  These are the transport protocols that encapsulate the application protocol and data and used to direct the datagram/packet to its destination IP address.

Protocol ID

Acronym

  8 Bits, [ Bits 8-15, Octet 9 ]  Protocol Description  -  RFC References

0

 

Reserved

1

ICMP

Internet Control Message Protocol  - RFC792

2

IGMP

Internet Group Management Protocol  RFC3376

3

GGP

DARPA Internet Gateway-to-Gateway  -  RFC823

4

IP

IP in IP (encapsulation)  RFC2003   

5

ST

Stream - RFC1819, IEN119

6

TCP

Transmission Control - RFC793 Update RFC3168, RFC6093, RFC6528

7

UCL

UCL

8

EGP

Exterior Gateway Protocol - RFC904

9

IGP

Any private interior gateway

10

BBN-RCC-MON

BBN RCC Monitoring

11

NVP-II

Network Voice Protocol - RFC741

12

PUP

PUP - PUP,XEROX

13

ARGUS

ARGUS

14

EMCON

EMCON

15

XNET

Cross Net Debugger

16

CHAOS

Chaos

17

UDP

User Datagram - RFC768

18

MUX

Multiplexing

19

DCN-MEAS

DCN Measurement Subsystems

20

HMP

Host Monitoring - RFC869

21

PRM

Packet Radio Measurement

22

XNS-IDP

XEROX NS

23

TRUNK-1

Trunk-1

24

TRUNK-2

Trunk-2

25

LEAF-1

Leaf-1

26

LEAF-2

Leaf-2

27

RDP

Reliable Data Protocol - RFC1151

28

IRTP

Internet Reliable Transaction - RFC938

29

ISO-TP4

ISO Transport Protocol Class 4 - RFC905

30

NETBLT

Bulk Data Transfer Protocol - RFC998

32

MFE-NSP

MFE Network Services Protocol

32

MERIT-INP

MERIT Internodal Protocol

33

SEP

Sequential Exchange Protocol

34

3PC

Third Party Connect Protocol

35

IDPR

Inter-Domain Policy Routing Protocol

36

XTP

XTP

37

DDP

Datagram Delivery Protocol

38

IDPR-CMTP

IDPR Control Message Transport Protocol

39

TP++

TP++ Transport Protocol

40

IL

IL Transport Protocol

41

SIP

Simple Internet Protocol

42

SDRP

Source Demand Routing Protocol

43

SIP-SR

SIP Source Route

44

SIP-FRAG

SIP Fragment

45

IDRP

Inter-Domain Routing Protocol

46

RSVP

Reservation Protocol

47

GRE

General Routing Encapsulation

48

MHRP

Mobile Host Routing Protocol

49

BNA

BNA

50

SIPP-ESP

SIPP Encap Security Payload

51

SIPP-AH

SIPP Authentication Header

52

I-NLSP

Integrated Net Layer Security TUBA

53

SWIPE

IP with Encryption

54

NHRP

NBMA Next Hop Resolution Protocol

55-60

 

Unassigned

61

 

Any host internal protocol

62

CFTP

CFTP

63

 

Any local network

64

SAT-EXPAK

SATNET and Backroom EXPAK

65

KRYPTOLAN

Kryptolan

66

RVD

MIT Remote Virtual Disk Protocol

67

IPPC

Internet Pluribus Packet Core

68

 

Any distributed file system

69

SAT-MON

SATNET Monitoring

70

VISA

VISA Protocol

71

IPCV

Internet Packet Core Utility

72

CPNX

Computer Protocol Network Executive

73

CPHB

Computer Protocol Heart Beat

74

WSN

Wang Span Network

75

PVP

Packet Video Protocol

76

BR-SAT-MON

Backroom SATNET Monitoring

77

SUN-ND

SUN ND PROTOCOL-Temporary

78

WB-MON

WIDEBAND Monitoring

79

WB-EXPAK

WIDEBAND EXPAK

80

ISO-IP

ISO Internet Protocol

81

VMTP

VMTP

82

SECURE-VMTP

SECURE-VMTP

83

VINES

VINES

84

TTP

TTP

85

NSFNET-IGP

NSFNET-IGP

86

DGP

Dissimilar Gateway Protocol

87

TCF

TCF

88

IGRP

IGRP - [CISCO]

89

OSPFIGP

OSPFIGP - RFC1583

90

Sprite-RPC

Sprite RPC Protocol - [SPRITE]

91

LARP

Locus Address Resolution Protocol

92

MTP

Multicast Transport Protocol

93

AX.25

AX.25 Frames

94

IPIP

IP-within-IP Encapsulation Protocol

95

MICP

Mobile Internetworking Control Protocol

96

SCC-SP

Semaphore Communications Sec. Protocol

97

ETHERIP

Ethernet-within-IP Encapsulation

98

ENCAP

Encapsulation Header - RFC1241

99

 

Any private encryption scheme

100

GMTP

GMTP

101-254

 

Unassigned

255

 

RESERVED

Table 4.2  IPv4 Header - Field Names and Description

IPv6 Header Fields:
The IPv6 transport block is just rearranged with a few added protocols and functions.  The Network Protocols, Transport Protocols and the Application Protocols are attached to the IPv6 header and called the data area.

References:
Network Sorcery:  http://www.networksorcery.com/enp/topic/ipsuite.htm
The Internet Engineering task Force:  IETF - RFC references

Name Bits (Size) Octet # RFC Number Description
Version 00-03
(4 bits)
0

 

Internet Protocol header Version 4 bits, IPv6 = 6

Traffic Class 04-11
(8 bits)
0, 1 RFC2460

Traffic Class - Same as DSCP+ECN in IPv4 - The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.  At the point in time at which this specification is being written, there are a number of experiments underway in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of "differentiated service" for IP packets, other than through the use of explicit flow set-up.  The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6.

Flow Label 12-31
(20 bits)
1,2,3 RFC3593

Several standards-track MIB modules have defined objects to represent an IPv6 Flow Label (sometimes referred to as Flow ID) [RFC2460] and IPv6 Flow Label filters.  Unfortunately the result is a set of different definitions for the same piece of management information.  This may lead to confusion and unnecessary complexity.  This document defines a set of textual conventions (TCs) that can and should be (re-)used in MIB modules, so that they all represent an IPv6 Flow Label in the same way.  In fact, PIB modules can and should also use these TCs when they need to represent an IPv6 Flow label.

Payload Length 00-15
(16 bits)
4, 5 RFC2675

This is the total length of the payload/packet size - The header size in not part of this number for payloads under 16 bits. For payloads over 16 bits it is a Jumbo payload and the header is added to the full payload size.  The max length is 65535 (16 bits)

Next Header

16-23
(8 bits)

6  

This field is similar to the Protocol field in IPv4 and defines the next header type. The two most common are TCP(6) and UPD(17). The next header starts at the end of the IPv6 header at octet 40.  The protocol requirements for the transport and applications are now moved to the end of the IPv6 header.

Hop Limit 24-31
(8 bits)
7  

This is a Time To Live limit to the number of hops to get to the next or final destination address.  At each router this number is decreased by 1 until the hop limit reaches zero, at which time the transport block is deleted if it is not the destination.

Source Address 00-31
(128 bits)
8-23  

This is the full 128 bit source IP address - the sender

Destination Address 00-31
(128 bits)
24-39  

This is the full 128 bit IP address of the destination - the receiver

Table 4.3  IPv6 Header - Field Names and Description

Protocols and Ports Classification: Single IP Address Many Ports and Protocols
There are many Application Layer protocols, a full list of the IANA protocol registry from A to Z, that may be applied to the core IoT platform device, however we will pick the main ones we want to control the device with at this time with the intention of easily adding AP's at a later date.  Each layer in the OSI model's four groups have a set of assigned protocols that configure/format the data  that is presented to the TCP/IP OSI model.

Back in Part 3, Figure 3.0 we presented the fact that each IP address has 65,535 ports that the data may pass through, well this is where we use those ports.  Only one IP address is handled at a time and is sent through the TCP/IP OSI layers, it just happens so fast it looks like many IP addresses pass through all at once.  What happens is that one IP address may service many functions serially in a time shared/sliced methodology.  This is like when you download a file from the Internet using FTP (File Transfer Protocol) in one browser window and open another browser window and start browsing the Internet while you are downloading the file, you are connected using only one IP address and browsing and downloading from many, however, it is time shared and only one source/destination pair of addresses happen at a time slice.  The OSI Layers Identified the application as HTTP and FTP protocols and separate the two specific sessions that keep the source-destination IP addresses along with other session parameters and routes the data accordingly, one to the display and the other to a file on the disk.  The Internet "Information Highway" is only the transport mechanism, while the TCP/IP OSI layers identify the data characteristics to be transferred, source-destination, I know I said that many times before, a bit of a nag? well, repetitiveness is the mother of retention.  At this point we consider the protocols to be IP address port application protocols and are defined in the IANA port assignments.  Socratic methodology applied to product design allows us to question the final results desired, then question each preceding stage working back to the initial stimulus in order that each stage will have the stimulus capability for the following stage and so on until we obtain the final results we desire as shown in Figure 4.0 Internet Data Flow P2P.

To start we will list the IP address port protocols with there description and decide if this protocol should be added to the core IoT Platform.  Once we decide the application port protocols we will discuss these protocols, their format and configuration and how it will flow through the core IoT Platform end to end.  Table 4.4 lists the Application Layer group IP address port protocols along with the core features of our IoT Platform.

Protocol Communication Protocols Description Port ID

Core IoT Platform   Feature Description

IoT Platform
HTTP

HyperText Transfer Protocol - A markup language used for Web communications

80

Allows the IoT Platform to communicate through a web browser - Configure and setup the IoT device through a web browser

YES
Telnet

A text oriented bi-directional data communications using virtual terminal connection, 8 bit, byte connection

23

Allow simple text  communications over the Internet.  Use for debugging and troubleshooting - requires security policies.

YES
SMTP

Simple Mail Transfer Protocol  - Standard for E-Mail transmission over the Internet

25

Allow E-mail to be transmitter from the IoT Device - E-mail controller on status or errors - requires security policies.

YES
FTP

File Transfer Protocol - A client-Server based protocol to transfer data files over the Internet.

21

Allows the IoT platform to transfer datafiles - - requires security policies.

YES
NTP

Network Time Protocol - Networking protocol to synchronize time between computer systems

123

Allow the synchronization of timed events of multiple IoT devices

YES

Table 4.4  TCP/IP OSI Model
Communication Protocols for Core IoT Platform

From the above table of protocols the features incorporated into the core IoT platform will allow communications over the Internet using a standard web browser, transfer data files through FTP, synchronize the time for many IoT platform devices to act together in a synchronous manor, send emails to a server on the status of the IoT platform devices and connect with a basic text terminal to IoT Platform devices through the Telnet protocol.

Now that we have this list created lets put it in a safe place for now, we will get back to this when we are in the platform design section of the series.  Lets get back to the Internet Protocols presentation.  There are other protocols that are unique in which IANA assigned a specific IP Address and fall into a Network Protocol information class.   These protocols have a specific datagram/payload or packet header formats.  Table 4.5 lists the device communications class of protocols and Table 4.6 list the special multicast protocol that also are assigned specific IP address port assignments.

Protocol Communication Protocols  Description Port ID Feature Description IoT Platform
Unicast

Single end to end data packet transfer - Address = Point to Point  IP addresses

 

IPv4 IPv6

 
Broadcast

Single to Many data packet transfer - Address = Block of Subnet LAN Addresses

 

IPv4 LAN

 
Anycast

Single to Many within Subnet Group - Address = Block of Routers Subnet Addresses

 

IPv6

 

Table 4.5  Internet Protocols
Global Protocols for Status, Configuration & Payloads

A little bit of history on why these protocols were created. In the beginning release of  IPv4 the two of the main communication class protocols were Unicast and Broadcast; these were fine until streaming video came along and started to bottleneck the Internet bandwidth, we will show this next.  The solution that emerged was a new protocol class labeled Multicast which incorporated a series of new IP address port assigned protocols.  The Multicast protocol did change for IPv6 by transfering of some of the IPv4 Broadcast protocol functions into IPv6 Multicast protocol.  With the changeover to IPv6 a new protocol called Anycast was introduced to handle the remaining IPv4 Broadcast protocols to eliminate Broadcast altogether in IPv6.  This now brings us to the dual mode core IoT platform that will seamlessly handle IPv4 and IPv6 schemes.  The protocols in Tables 4.5 and 4.6 are a special class because they have pre-assigned IP Address by IANA and are masked to act on a block of IP addresses assigned to devices.  These protocols have unique IP headers assigned to them which we will cover in another part of the series.   Ok, lets look at some pictures to explain the overall data flow of these new protocols. Figure 4.5 through 4.8 show overviews of how each of these protocols handle the data transfer.  The detailed presentation of these protocols will follow in the next part of the series, for now it is important to keep in mind the high level concept of these protocols.  Once again, every protocol must have a source-starting point or command execute point and a destination -response, configure, control point.

Multicast Communication Protocols  Description Port ID Feature Description IoT Platform
MSDP

Multicast Source Discovery Protocol RFC3618

639

IPv6

 
MADCAP

Multicast Address Dynamic Client Allocation Protocol

2535

IPv4

 
mDNS

Multicast Domain Name System

5353

IPv4

 
LLMNR

Link-Local Multicast Name Resolution

5355

IPv6

 

Table 4.6  Internet Protocols
Multicast Protocol Port Assignments

 

IPv6, IPv4 Unicast: high level Overview
The Unicast is the easiest to understand since it is a single point to point data transport - single source - single destination. The 5 Megabits per second connection is just a standard cable connection, DSL would be 1 Megabits per second typical.

Unicast_on
Figure 4.5 Unicast Single Source, Single Transmission to Single Destinations

IPv6, IPv4 Multicast: High Level Overview
A bit confusing without a picture, Consider this scenario, you are the software protocol, very flexible, able to perform unlimited sequences and connect globally to transfer information, easy, use your smart phone as a resource.  Oh, what?, you don't know the phone number but you do have a name and state, no problem, just search the Internet for the names in the state, you are now acting as the host and you send out a Multicast request to Search the Internet (Google® it); the response is a block of phone numbers that match the name and state, wow, too many names. OK you want to narrow the search, so you do another Multicast request with a narrower field like state and city, still the same multicast protocol with just more bits set to 1 in the Multicast IP address.  OK the response is the actual phone number you are looking for. So what we did was send out A Multicast Request to everyone to give us the phone number that fits a certain criteria and we received a single phone number.   Next is to call the number, then the destination phone rings, you are sending a Unicast datagram to ring the phone, this requires that the sending protocol is able to be received by the destination hardware and be aware of the actual phone number being sent, this is the first part of the physical (synchronous) handshake.  Now the destination phone is answered and this completes the physical (synchronous) handshake.  OK the phone at the destination is answered and you send the data hence, the header and protocol information along with the information data, remember that from part 3?.  Keep this simple process in mind that all protocols must have a source-destination, (stimulus-response) and we will be able to build on this concept with clarity as we present the protocols we need to design our IoT core platform hardware.

To review history, just a little, IPv4 was in a continuous state of review and upgrades since it was the first scheme of its class to come along that had a standard global future.  It went from a few hundred in 1978 to over 1.5 Billion in less than 25 years.  IPv6 is 20 years old in January,2016 and since its' release it has addressed and eliminated many of the IPv4 limitations, however, there is a cost for this change.  The change came in the protocol classes and how they function, since we now have to contend with both IPv4 and IPv6 schemes.  IPv4 relied on the Broadcast protocol to handle many of the broad device requests on the LAN.  IPv6 has eliminated the Broadcast protocol and replaced it with Anycast also took some of the Broadcast protocols and carried them over to the Multicast protocol in order to organize its scope to the current IPv6 subnet it is executed on.  Remember there is nothing magical about any of the class protocols, they may originate from routers, Operating Systems, or Devices, it still has a stimulus-response methodology.  Figure 4.6 shows the sender sending the same information five times to five separate users which takes a longer time to send.  This is similar to the bottleneck in the routers using only one IP to send/receive to many users, this is always a time-slice process where the time is shared by the number of users so the bandwidth decreases is defined by, Throughput = Total Bandwidth ÷ Number of users.

Multicast_off
Figure 4.6  Single Source, Single Transmission to each destination separately

Figure 4.7 shows the same data stream but under a multicast send process.  The sender only sends the transmission to the server once and the server only sends it to the each one of the multiple users at the same time only once. It is easy to see why Multicast is used for streaming data, Multicast conserves on bandwidth by masking a block of IP addresses in multiple subnets and only has to send the data stream once.  The Multicast protocol handles the global Internet Subnet to Subnet.  This is just like texting or e-mailing multiple users one way anywhere in the world.  Without Multicast the server would be sending out the same data to each individual as fast as it could, this requires N times the bandwidth since it is sending out multiple P2P streams which consumes server bandwidth.  Other type of IPv6 Multicast functions are also available to locate who is on the network,  MLD (Multicast Listener Device) mask, this woudl work both on the ULA private network or the subnet global as well.  For IPv4 LAN you would perform and ARP request, returned would be a list of devices with their MAC address that are on the LAN.  

The Multicast protocol is used for web broadcasts (webinars) and is sent out to each user registered to the subnet.  If the users misses the webinar that router just dumps the data while the remaining connections view the webinar.  This does not fix all the streaming issues however it is a great start.

Multicast_on
Figure 4.7   Multicast Single Source, Single Transmission to Multiple Destinations

IPv6 Anycast: high level Overview
This is a new class type protocol and it is used very similar to Multicast except that the destination IP addresses are in a single Subnet.  Anycast address protocol is still in its experimental mode and I would guess that until there is a better understanding of Internet Protocols and the time and path responses for the protocol it will be seldom used.  Anycast addressing would be difficult and burden routers if sending to multiple subnets globally, Anycast attempts to find the shortest path to the destination. Anycast would be more efficient kept on the same IPv6 subnet.

Anycast_on
Figure 4.8 Anycast Single Source, Single Transmission to Local Subnet Multiple Destinations


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 5 Network Protocols
- Network, Transport & Application -Continued (Aug 17, 2017)
Part 6 Network Protocols - Network, Transport & Application -Continued -Ethernet Protocol (Sept 21, 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 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:
The majority of Internet scheme and protocol information are from a few open public information sources on the net, the 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) series presentations and follows 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 5 will cover - How protocols interact with the Internet, Selected protocol details, the Transport block from point to point, The Unicast, Multicast protocols assigned IP addresses and expected responses from them, Typical TCP point to point.


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 Plaground Part 4: IPv4, IPv6, Protocols, Network, Transport & Application: (January 10, 2017)

For Website Link: cut and paste this code:

<p><a href="https://www.basilnetworks.com/Blog/index.php?op=ViewArticle&articleId=9&blogId=1" target="_blank"> BASIL Networks, PLLC - Internet of Things (IoT) - Security, Privacy, Safety - Platform Development Project  Part-4  IPv4, IPv6, Protocols, Network, Transport & Application (January 10, 2017)</p>

 

Sal_Tuzzo

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  Next»
 
Powered by LifeType - Design by BalearWeb
Copyright© 1990-2018 BASIL Networks, PLLC. All rights reserved
webmaster