What is Ethernet/IP? Acromag Whitepaper
Getting Started with Ethernet/IP
The following information describes the operation of Ethernet/IP™ (Ethernet Industrial Protocol) as it relates to Acromag Series 900EN-60xx and XTxxx2-xxx I/O modules. You can download a copy of the Ethernet/IP Standard, from the Open DeviceNet Vendor Association (ODVA) web site for Ethernet/IP.
Acromag also manufactures a line of I/O modules that support Modbus TCP/IP and EtherNet/IP. You can obtain the latest information about these and other Acromag products on our website or by calling our Inside Sales Department at (248) 295-0880.
Table of Contents
- About Ethernet/IP
- The Open Systems Interconnect (OSI) Network Model
- Application Layer
- Transport Layer
- Network Layer
- Data Link Layer
- Electronic Data Sheet (EDS) File
- More Ethernet Application Notes
EtherNet/IP is the result of a joint effort between ODVA, ControlNet International (CI), and the Industrial Ethernet Association (IEA). Their goal was producing a network protocol to address the high demand for using the widely popular Ethernet network in control applications. They first presented it in March of 2000.
In short; Ethernet/IP (Ethernet Industrial Protocol) is traditional Ethernet, combined with an industrial application layer protocol, targeted to industrial automation. This application layer protocol is the Control and Information Protocol (CIP™).
IEEE 802.3 Ethernet is traditionally an office networking protocol that has gained universal acceptance world-wide. It’s an open standard supported by many manufacturers and its infrastructure equipment is widely available and largely installed. The Ethernet TCP/IP protocol suite is also found everywhere and it’s the foundation for access to the World Wide Web. Since many devices already support Ethernet I/O, it is only natural to augment it for use in industrial applications. Ethernet/IP was created to overcome the shortcomings of traditional IEEE 802.3 Ethernet. (As applied to the industrial automation world.)
Widely used in industrial environments for decades, the CIP provides both real-time and informational message structures. It’s designed to be “wire-independent,” in that it can work with any data-link and physical layer. CIP is freely available to anyone, easy to understand, and widely supported by many manufacturers of industrial equipment. As a result, it is a natural candidate for use in building other industrial communication standards. CIP was adopted after being merged with the popular CAN protocol in 1994; forming DeviceNet. ControlNet was the next protocol to adopt CIP in 1997. ControlNet has higher speeds (up to 5MB). Consequently, ControlNet is considered more deterministic than DeviceNet. Additionally, it extends the range of the bus, up to several kilometers, with the use of repeaters.
EtherNet/IP Merged IEEE 802.3 Ethernet with the CIP
Next, EtherNet/IP merged traditional IEEE 802.3 Ethernet with the CIP as its application layer to build an even more powerful industrial communication standard. Ethernet/IP shares the same physical and data link layers of traditional IEEE 802.3 Ethernet and uses the same TCP/IP suite of protocols. This makes it fully compatible with existing Ethernet hardware, such as cables, connectors, network interface cards, hubs, and switches. Further, EtherNet/IP uses the same application layer protocol used by both DeviceNet and ControlNet. Thus allowing these protocols to share common device profiles and object libraries. Additionally, it helps to make these types of devices interoperable on the same network.
There are four reasons why EtherNet/IP is considered an open network standard:
- The physical and data link layers use standard IEEE 802.3 Ethernet
- The network layer uses the TCP/IP suite of protocols
- Support by the following independent networking organizations:
- ControlNet International (CI)
- Industrial Ethernet Organization (IEA)
- Open DeviceNet Vendor Association (ODVA)
- Industrial Automation Open Network Alliance (IAONA)
- Ethernet/IP technology is also available free of charge to developers and vendors.
Historically, traditional Ethernet was not considered a viable fieldbus for industrial control and I/O networks. This was because of two major shortcomings; inherent nondeterminism, and low durability. However, new technology properly applied has mostly resolved these issues. Ethernet equipment was originally designed for the office environment; not harsh industrial settings. However, many factory Ethernet installations can use this standard hardware without a problem; new industrial-rated connectors, shielded cables, and hardened switches and hubs can now help resolve this durability issue.
With respect to the non-deterministic behavior of Ethernet; determinism is used here to describe the ability of a network protocol to guarantee a packet is sent/received in a finite, predictable amount of time. Thus, for critical control applications, determinism is very important.
Carrier Sense Multiple Access with Collision Detect
Carrier Sense Multiple Access with Collision Detect (CSMA/CD) is the arbitration protocol for carrier transmission access on any Ethernet network. Any network device can try to send a data frame at any time. However, with CSMA/CD applied, each device will first sense whether the line is idle and available for use. If the line is available, the device will then begin to transmit its first frame. If another device tries to send a frame at approximately the same time, then a collision occurs; as a result, both frames will be discarded.
Each device then waits a random amount of time and retries its transmission until its frame is sent successfully. This channel-allocation method is inherently non-deterministic. This is because a device may only transmit when the wire is free; thus resulting in unpredictable wait times before data may be transmitted. Additionally, because of cable signaling delay, collisions are still possible once the device begins to transmit the data; consequently forcing additional retransmission/retry cycles.
More Deterministic Ethernet with Fast Ethernet Switches
Most control systems have defined time requirements for packet transmission (typically less than 100ms). Therefore, the potential for collisions and the CSMA/CD method of retransmission isn’t considered deterministic behavior. As a result, traditional Ethernet had problems being accepted for use in critical control applications. However, Ethernet can be made more deterministic by using fast Ethernet switches. These switches increase the bandwidth of large networks by sub-dividing them into several smaller networks, called collision domains. The switch also provides a direct connection from sender to receiver, so only the receiver receives the data; not the entire network.
Switches (AKA switching hubs) are intelligent network devices that connect distributed Ethernet nodes more efficiently. Each port of a switch forwards data to another port based on the MAC address contained in the received data packet/frame. Switches learn and store the MAC addresses of each device they’re connected to, as well as the associated port numbers. The port of a switch doesn’t require its own MAC address.
During retransmission of a received packet, the switch port will instead look like the originating device by having assumed its source address; and the Ethernet collision domain is said to terminate at the switch port. The switch effectively breaks the network into separate data links/collision domains; one at each switch port. The ability of switches to target a packet to a specific port (rather than forwarding it to all switch ports), also help eliminate collisions that make Ethernet non-deterministic.
As switches become less expensive, the tendency in critical industrial control applications is to connect one Ethernet device per switch port; effectively treating the switch device as the hub of a star network. In this manner, with only one network device connected per switch port, the switch can run full-duplex; with no chance of collisions. Thus, a 10/100 Ethernet switch effectively runs at 20/200 Mbps because it can transmit and receive at 10 or 100 Mbps simultaneously (full-duplex). Since there’s only one device connected to a port, there’s no chance of a collision. The higher transfer speed of full-duplex, coupled without the need for invoking CSMA/CD, produces a more deterministic mode of operation. This helps critical control applications to remain both predictable and on-time.
Unfortunately, broadcast traffic on a company network cannot be completely filtered by switches. This may cause additional collisions, reducing the determinism of a network connecting more than one device to a switch port. However, if the company network and the control and I/O network are separated; traffic will not be added to the control network and the company network’s determinism will increase. Further, if a bridge is used to separate the two networks, then the bridge may be configured to filter unnecessary traffic.
Advances in Ethernet Switches
Combining good network design with fast switches and bridges where necessary raises the determinism of a network. This makes Ethernet/IP more appealing. Other advances in Ethernet switches, such as; higher speeds, broadcast storm protection, virtual LAN support, SNMP, and priority messaging, further help increase the determinism of Ethernet networks. As Gigabit (Gbit), 10Gbit, and 100Gbit Ethernet enters the market, determinism will no longer be a concern.
With Ethernet as an open standard, numerous hardware and software vendors compete; resulting in low-cost, off-the-shelf products. As almost everyone knows what Ethernet is, it is also easier and more efficient to train people on Ethernet networks. Research funding for Ethernet far surpasses that of any other fieldbus. This further enables faster development and increasingly higher speeds.
The Open Systems Interconnect (OSI) Network Model
For a better understanding of the meaning “open standard,” and how EtherNet/IP is structured, we need to review the (OSI) Reference Model. The International Standards Organization developed this model and it was adopted in 1983 as a common reference for the development of data communication standards. It does not attempt to define an implementation; but rather serves as a structural aide to understanding “what must be done” and “what goes where.”
As can be seen in Table 1, below, in the traditional OSI model, as well as the simplified 5-layer TCP/IP standard (layers 5 & 6 suppressed); the functions of communication are divided into seven (or five) layers. Every layer handles precisely defined tasks. For example; Layer 1 of this model is the physical layer and defines the physical transmission characteristics. The data link layer is the 2nd layer and defines the bus access protocol. Layer 7 is the application layer and defines the application functions. (This layer defines how device data will be interpreted.)
By the OSI Model, we can infer that for two devices to be interoperable on the same network, they must have the same application-layer protocol. In the past, many network devices have used their own proprietary protocols, and this has hindered their interoperability. This further drove the need for adoption of an open network I/O solution; one that would allow devices from a variety of vendors to seamlessly work together. This drive for interoperability was a key reason for creating Ethernet/IP.
In the TCP/IP Standard Model, Ethernet handles the bottom two layers (1 & 2) of the seven-layer OSI stack; while TCP/IP handles the next two layers (3 & 4). The application layer lies above TCP, IP, and Ethernet, and is the layer of information that gives meaning to the transmitted data.
Although the Acromag 9xxEN-60xx modules are designed for EtherNet/IP, they also provide support for one additional socket of Modbus TCP/IP.
With Acromag 9xxEN-40xx Modbus TCP/IP modules, the application layer protocol is Modbus. That is, Modbus TCP/IP uses Ethernet media and TCP/IP to communicate using an application layer with the same register access method as Modbus RTU. Many manufacturers happen to support Modbus RTU and TCP/IP. Additionally, Modbus is widely understood and freely distributed, thus, Modbus TCP/IP is also considered an open standard.
Acromag’s 9xxEN-60xx modules are designed for EtherNet/IP. However, they also provide support for one additional socket of Modbus TCP/IP. With Acromag 9xxEN-60xx EtherNet/IP and XTxxx2-xxx modules, the application layer protocol is the CIP. The same application layer protocol is used by ControlNet and DeviceNet devices. By sharing the same application layer, these devices can be made interoperable on the same network.
EtherNet/IP is based on the TCP/IP protocol family and shares the same lower four layers of the OSI model common to all Ethernet devices. This makes it fully compatible with existing Ethernet hardware, such as cables, connectors, network interface cards, hubs, and switches. However, EtherNet/IP adds the Control and Information Protocol (CIP) as its application layer. Again, the same application layer protocol is used by both DeviceNet and ControlNet devices; making each of the device types interoperable on the same network. It further allows these protocols to share common device profiles and object libraries.
Learn more about Ethernet: How to Connect to an Ethernet Device for Communication Whitepaper
OSI 7-Layer Model
TCP/IP refers to the Transmission Control Protocol and Internet Protocol which were first introduced in 1974. It’s the foundation for the World Wide Web and forms the transport and network layer protocol of the internet that commonly links all Ethernet installations world-wide. TCP/IP allows blocks of binary data to be exchanged between computers. The primary function of TCP is ensuring that all packets of data are received correctly. IP ensures messages are addressed and routed correctly. Note: the TCP/IP combination does not define what the data means or how the data should be interpreted; it’s merely a transport protocol. UDP (User-Datagram Protocol) is another transport layer protocol that’s responsible for ensuring prompt delivery of a data packet.
In contrast, CIP is an application protocol. It defines rules for organizing and interpreting data and is essentially a messaging structure that’s independent of the underlying physical layer. It’s freely available and accessible to anyone, easy to understand, and widely supported by many manufacturers. Ethernet/IP uses TCP/IP, UDP/IP, and Ethernet to carry the data of the CIP message structure between devices. That is, Ethernet/IP combines a physical network (Ethernet), with a networking standard (TCP/IP & UDP/IP), and a standard method of representing data (CIP).
TCP/IP is formed from a “suite” of protocols; all internet communication is based on this suite (also known as a “protocol stack”). Each host/router on the internet must run a protocol stack. “Stack” refers to the simplified TCP/IP layered Reference Model used to design network software, as outlined below:
TCP/IP Protocol Stack
|5||Application||How an application uses a network|
|4||Transport||How to ensure reliable data transport|
|3||Internet/Network||Packet format and routing|
|2||Host-to-Network||Frame organization and transmittal|
|1||Physical||The basic network hardware|
To better understand stack operation, the following table illustrates the flow of data from a sender to a receiver using the TCP/IP stack. (We have renamed the Host-to-Network layer to the more commonly used Data Link Layer):
TCP/IP Protocol Stack Operation
|Sender||→ Virtual Connection →||Receiver|
|↓ Application||← Equivalent Message →||Application ↑|
|↓ Transport||← Equivalent Message →||Transport ↑|
|↓ Internet/Network||← Equivalent Message →||Internet/Network ↑|
|↓ Data Link Layer||← Equivalent Message →||Data Link Layer ↑|
|→ Physical Hardware||→→→→→→→→→→→→||Physical Hardware ↑|
Each layer on the sending stack communicates with the corresponding layer of the receiving stack through information stored in headers. As you move the data down the stack of the sender, each stack layer adds its own header to the front of the message that it receives from the next higher layer. Hence, higher layers are encapsulated by lower layers. Conversely, this header information is removed by the corresponding layer at the Receiver; in essence, the headers are peeled off as the data packet moves up the receiving stack to the receiver application.
Ethernet/IP Communication Stack
|# / Model||Important Protocols||Reference|
|7 – Application|
5 – Session
(Control & Information Protocol)
|4 – Transport|
3 – Network
|UDP | TCP|
IP, ARP, RARP
|2 – Data Link||Ethernet, CSMA/CD, MAC||IEEE 802.3|
|1 – Physical||Ethernet Physical Layer||IEEE 802.3|
The following figure illustrates the construction of a TCP/IP-Ethernet packet for transmission. For Ethernet/IP, the application layer is CIP. When an application sends its data over the network, the data passes down through each layer. Note: the upper layer information is wrapped into the data bytes of the next lowest layer (encapsulated). Each subsequent layer has a designated function and attaches its own protocol header to the front of its packet. The lowest layer is responsible for sending the data. Next, the entire wrap-into procedure reverses for data received. (The data received is unwrapped at each level, then passed up to the receiver’s application layer.)
Construction of a TCP IP-Ethernet Data Packet
A host application forms its request, then passes its data down to the lower layers. The lower layers then add their own control information to the packet in the form of protocol headers and footers. Next, the packet reaches the physical layer and is electronically transmitted to the destination host. The packet then travels up through the different layers of its destination. Each layer decodes its portion of the message. Then it removes the header and footer that was attached by the same layer of the sending computer. Lastly, the packet reaches the destination application. Each layer only communicates with the layer just above or below it. However, this process can be viewed as a layer at one end, talking to its partner layer at the opposite end.
Learn More: Modbus TCP/IP: an Introduction
Key Concepts & Terminology
To better understand Ethernet/IP and the operation of a stack, please review the following key concepts and terminology:
All network functions are structured as a layered model.
There are one or more protocols (layer entities) at every layer.
Protocol Stack refers to this layering of protocol entities.
Layer n communicates with other layer n entities (other protocols on the same layer) using layer n Protocol Data Units (PDU’s).
Layer n uses the service of layer n-1 and offers a service to layer n+1.
Ethernet/IP follows the Client-Server model.
Protocols are either connection oriented or connectionless. Connection implies that the communication requires synchronization of all parties before data can be exchanged.
Rules of operation followed by peer entities. The Protocol defines the format of Protocol Data Units and their rules of operation.
Two or more protocols on the same layer. Could refer to protocols at the same layer on different nodes.
Operation rules between peer entities.
Service Access Point (SAP):
The interface between a layer and the layer above it.
Service Data Unit (SDU):
The interface data between the layers.
Any program that awaits data requests to be sent to it. Servers don’t initiate contact with clients; they only respond to them.
Any network device that sends data requests to servers.
Address used locally at the transport layer (on one node) and identifies the source and destination of the packet inside that node. Port numbers are divided between well-known port numbers (0-1023); registered user port numbers (1024-49151); and private/dynamic port numbers (49152-65535). Ports allow TCP/IP to multiplex and demultiplex a sequence of IP datagrams that need to go to many different (simultaneous) applications processes.
Application layer address formed from the combination of an IP address and port number (expressed as <Host IP Address>:<Port Number> or <Host Name>:<Port Number>). Additionally, it’s used as the overall identification address of an application process. Application protocols use sockets to keep track of the port number assigned to each instance of an application when using UDP or TCP.
The uppermost layer of the TCP/IP and OSI Reference Models is the Application Layer. There are many application layer protocols that may reside here, such as FTP, Telnet, HTTP, SMPT, DNS, and NNTP, among others. While each of these protocols has their own specific purpose, for EtherNet/IP, the primary application layer protocol of interest is CIP.
Since CIP is built using objects, we’ll go over some basic object-oriented concepts and terminology before going deeper.
Objects are defined by attributes and behaviors.
The information that differentiates one object from another; the data of an object. The data stored within an object defines the state of the object.
The operations or methods the object uses to manipulate its data or attributes. The behavior of an object is what the object can do; this behavior is contained within its methods.
Used to operate on the data. Every attribute of an object will have a corresponding method and you invoke a method by sending a message to it.
The communication mechanism between objects. CIP object models use “get” and “set” messages as methods to access their data.
An object is defined as an entity that contains both data and behavior.
This is key to understanding what an object is; that is, it combines the data and the behavior into one complete package. In this way, we also say that the object encapsulates its data and behavior. This is in contrast to non-object oriented (or procedural) programming, where the data and the behavior are kept separate.
In this way, there is no global data in an object. The object controls access to its attributes and methods. Some object members (both data and methods) are hidden from other objects. As a rule, objects do not normally manipulate the internal data of other objects. Access to the attributes within the object are controlled by the object itself. Data hiding means the restriction of access to certain attributes and method functions. Details that are not important to the use of an object should be hidden from other objects. Additionally, an object should only reveal the interface necessary to interact with it.
Additionally, objects are modeled after classes. A class is like a template, from which specific objects are made. In this way, the class is like a blueprint for the object. Objects are created from classes; therefore classes must define the basic building blocks of objects (i.e., data, behavior, and messages). A class will define the attributes and behaviors that all objects created from this class will possess.
Control & Information Protocol (CIP)
The TCP/IP protocol suite (or stack of independent protocols) provides all the resources for two devices to communicate with each other over an Ethernet Local-Area Network (LAN), or global Wide-Area Network (WAN). However, TCP/IP only guarantees that application messages will be transferred between these devices; it does not guarantee that these devices will understand or interoperate with one another. For Ethernet/IP devices, this capability is provided by the Control and Information Protocol (CIP); or its more modern reference, the Common Industrial Protocol.
Ethernet/IP, ControlNet, and DeviceNet all share the Control and Information Protocol (CIP) at their application layer. For example, DeviceNet is basically CIP running on a CAN bus. Similarly, Ethernet/IP is CIP over TCP/UDP/IP. Because ControlNet, DeviceNet, and Ethernet/IP all have CIP in common, they also share an extensive object library and collection of pre-defined device profiles.
CIP is built using the distributed object model. That is, this model combines appropriate functionality with data by way of distributed objects. These objects are then used to model the behavior of varied application entities. An object is an instance of a class and contains member functions (methods) that are only specified in the class as operations. Although CIP defines a public set of operation, the methods of implementation are separate and application specific. Object oriented applications make it easy to hide data and implementation details by using hierarchies of classes and other object-oriented features.
All CIP devices are modeled as a collection of objects.
An object represents a particular component of a device. Each object has properties (data) and methods (commands). We use the term class to refer to a specific type or set of objects (same kind of system components), and object instance to refer to one implementation of a class (the object instance is the actual representation of a particular object within a class). Each instance of a class has the same attributes, but its own particular set of attribute values.
The term attribute refers to a characteristic of an instance, an object, or an object class. Attributes provide status information and govern the operation of an object. Services are used to trigger the object/class to perform a task. The object’s response is referred to as its behavior. This collection of related data values and common elements that make up the device form its object model. Although the terms object and class are often used interchangeably, a class is actually a specific type of object. Users access these objects through the application layer and this access remains the same, regardless of which network type hosts the device. The application programmer does not need to know which network a device is connected to, because this operation remains transparent to him.
A class is a specific type of object. An instance is one implementation of a class, and an attribute is a characteristic of an instance. For example, if our object is fruit, an apple is a class of fruit. A Macintosh apple is an instance of this class, and red skin is one attribute of this particular instance.
A class exists simply to combine data for I/O messaging among common elements. The CIP library contains many commonly defined objects/classes. Currently, at least 46 object classes are defined.
Discrete input, discrete output, analog input, analog output, position controller, and AC drive are all classes defined in CIP. These CIP objects or classes define the device’s access, behavior, and extensions. This allows different device types to be accessed using a common mechanism—in this case, the object model. It’s important to make the distinction that the CIP standard does not specify how these objects are to be implemented; it only specifies what data values or attributes must be provided and made available to other CIP devices.
The objects and their components are addressed by a uniform integer ID value addressing scheme utilizing the following:
Class Identifier or Class ID:
Assigned to each object class and accessible from the network.
Instance Identifier or Instance ID:
Assigned to an object instance that identifies it among all instances of the same class.
Attribute Identifier or Attribute ID:
Assigned to a class and/or instance attribute.
Denotes a particular object instance and/or object class function.
Media Access Control Identifier (MAC ID):
Assigned to each node on the network.
CIP makes use of object models to provide a standard method for transferring automation data between devices on the network. Individual objects are only added to a device’s object model according to the specific functionality of the device. As a result, a device isn’t burdened with the overhead of support for objects it cannot use. CIP already includes a large collection of commonly defined objects/object classes. While only a few of these objects are specific to the network link layer (only two objects are specific to Ethernet/IP for example—TCP/IP Interface Object & Ethernet Link Object), the majority are common objects that can be used across all CIP based networks. Though most devices use some of these publicly defined objects, device vendors are free to create their own vendor-specific objects. Vendor-specific objects are denoted by class ID’s 100-199.
EtherNet/IP devices are further grouped into two general device classes: adapters or scanners. Adapters are I/O devices that provide data to a scanner. (i.e., Acromag 9xxEN and XTxxx2 modules are adapters.) Scanners are explicit I/O devices which configure adapters to produce their data.
CIP uses the producer/consumer-based connection model, rather than the more traditional source/destination model. The producer/consumer-based connection model implies that as a message is produced on the network, it’s identified by its connection ID; not its destination address. Multiple nodes may also have the right to consume the data to which this connection ID refers. If a node wants to receive data, it only needs to ask once to consume the data each time it’s produced. Likewise, if a second node (or any number of additional nodes) require the same data, they only need to know is the connection ID to receive the same data simultaneously with all the other nodes.
CIP provides many standard services for control of network devices and access to their data via implicit and explicit messages. Recall that implicit I/O messages refer to message exchanges that are time-sensitive (real-time). In contrast, explicit messages emphasize reliability and are used for messages that must arrive. The type of messaging that’s required will determine which specific transport layer protocol will be used; either TCP (explicit/information), or UDP (implicit/control). The UDP/IP/MAC protocol stack typically handles implicit messages. The four general types of implicit messages are; polled, change-of-state, cyclic, and strobed. The TCP/IP/MAC protocol stack will handle the explicit messages, which are simple point-to-point messages. The key thing to remember about implicit messages is that there can be many consumers of a single network packet; this requires UDP. By comparison, TCP is reserved for point-to-point messages.
The Four General Types of Implicit Messages Supported by CIP:
- Polled: messages in which a master device (scanner) sequentially queries all of the slave devices (adapters) by sending them their output data and receiving a reply with their input data.
- Strobed (or Polled Strobed): a special case of polled, in which the scanner sends out a single multicast request for data and the slaves sequentially respond with their data with no further messages required from the master.
- Cyclic: messages are produced by a device, according to a pre-determined schedule, and are associated with a connection ID. (Cyclic messages are implicit.) Other devices that require the data of the producer are made aware of the connection ID; then they accept the network packets associated with the connection ID.
- Change-of-state: similar to cyclic, but in contrast to a timed schedule; data is produced in response to an event which caused the data to change. Change-of-state devices must maintain a background cycle/rate (their “heartbeat”) to allow consuming devices to know that the node is online and functioning.
EtherNet/IP only uses polled and cyclic. DeviceNet and ControlNet use all four types.
Types of CIP Messaging
At this point, it’s important to understand the distinction between the type of messaging that CIP may use. This type will then determine which lower level service and subsequent encapsulation will be performed, TCP/IP/MAC or UDP/IP/MAC. In general, the control portion of CIP makes use of real-time I/O messaging or implicit messaging. The information portion of CIP is used for simple message exchanges or explicit messaging. TCP may only work with unicast (point-to-point) messages.
UDP is typically used for implicit messages. TCP, however, is used for explicit messages, as outlined in Table 5, below:
From the table above, we see that I/O data and real-time interlocking data transfers will typically use UDP to take advantage of its higher speed/throughput. Conversely, simple information exchanges between two devices will use the slower, but more reliable data transfer capability of TCP.
It’s also important to note that CIP does not have its own unique layer 5 frame format; it nests its encapsulation message into the data/payload field of a TCP or UDP frame (depending on the message type). This total is then nested into the IP frame; and subsequently nested into the Ethernet/MAC frame for transmission over Ethernet. This is the encapsulation of CIP messages that’s commonly referred to. (The encapsulation that occurs at each layer, as we move down the stack to the connection media, will be covered in more detail later.)
The CIP encapsulation messages are comprised of an encapsulation header and optional data. The encapsulation header contains fields with control commands, format, and status, as well as synchronization information. The term encapsulation refers to the action of packing (embedding) the message into the TCP, or UDP container. After that, the information packet is encapsulated by the data frames imposed by the TCP/IP stack of protocols (TCP/IP/MAC or UDP/IP/MAC). Lastly, it’s transmitted to the network.
The lower-level encapsulation is illustrated below:
TCP/IP/MAC Encapsulation (Explicit Messaging)
TCP/IP/MAC Encapsulation (Implicit Messaging)
Some CIP messages are only sent via TCP; others may be sent via TCP or UDP. As TCP is a data-stream based protocol, it may send almost any length IP packet it chooses, and it can parse this message as required. For example, it may encapsulate two back-to-back encapsulation messages in a single TCP/IP/MAC packet, or it may divide an encapsulation message across two separate TCP/IP/MAC packets. However, with UDP, only one message may be encapsulated at a time via UDP/IP/MAC.
There are three general types of objects/classes defined by CIP; required objects, application or device-specific objects, and vendor-specific objects.
Required objects must be included in every CIP device.
Device-specific objects are the objects that define the data encapsulated by the device; these are specific to the type of device and its function.
Vendor-specific objects, in contrast, are not found in the profile for a device class. They’re usually included as additional features of the device.
The confusion surrounding this usually arises from the nesting of objects and classes that occurs in defining other objects and classes, in addition to linking together these various objects to build larger device profiles. Required objects must be included in every CIP device, including; identity objects, message router objects, and network objects. Most Ethernet/IP devices require the following objects:
- An Identification Object (Identity Object)
- A Connection Object (Connection Manager Object)
- One or More Network Link Objects (Ethernet Link & TCP Objects)
- A Message Router Object (Message Router Object)
Identity Object (Class Code 1)
|Mandatory Attributes||Optional Attributes|
|Device Type||Configuration Consistency Value|
|Product Code||Heartbeat Interval|
Device-specific objects define the data encapsulated by the device and are specific to the type of device, as well as its function. For example, an analog input object of an I/O device has attributes that define the data type, resolution, and current value for the analog input.
Objects not found in the profile for a device class are vendor-specific objects. Any object ID from 100 (64H) to 199 (C7H) denotes a vendor-specific object type. Generally, vendor extensions are included as additional features of a device, then the data is presented and organized in any way the vendor chooses. The CIP protocol provides access to these extended objects, exactly the same as it does for the required objects and other application layer objects.
A device vendor can group multiple CIP application layer objects into assembly objects/classes to combine data for I/O messaging. Additionally, device vendors can define multiple assembly objects or classes for the same device. Assembly objects/classes are sometimes called “super objects.” These super objects contain the attributes of one or more CIP application layer objects. The purpose of assembly objects is to provide a convenient package for transporting data between different devices.
A vendor of an output module with multiple output channels may define an assembly class for each output channel, and another assembly class for all outputs combined; this allows the user to pick the best-suited assembly for his application, together with its frequency of access. Assemblies are usually predefined by a vendor; however, CIP also provides a mechanism that allows a user to dynamically create an assembly from CIP application layer object attributes
All CIP devices of the same device type must contain an identical series of application layer objects. A device profile is a series of CIP application layer objects making up a particular device type. A large number of profiles already exist for a variety of common device types. The intent is that by using a common profile, you can easily switch between vendors for any type of device.
The pneumatic valve device profile describes a set of application objects that must be implemented to control that valve. Every pneumatic valve will implement a minimum set of common objects. These common objects contain the same minimum data set (i.e. properties), and respond the same way to the same commands (methods). CIP ensures that by knowing how to use one pneumatic valve, likewise you already know how to use pneumatic valves from other manufacturers that conform to the same CIP device profile.
From a device manufacturer’s perspective, the use of common profiles may sound too restrictive for a manufacturer trying to offer unique features and capabilities to his products. But understand that although the use of common device profiles exist, a manufacturer may still incorporate additional features into its products via additional objects and attributes beyond those defined in the common device profile. A vendors’ conformance to an existing device profile simply allows his customers to define to a core set of objects and attributes without regard to the device manufacturer.
CIP Encapsulation Message
As seen in Figure 4, below, the CIP Encapsulation Message (the data portion of the TCP or UDP frame) includes a 24-byte header. The header is followed by its own data (optional), and is limited to a total length of 65535 bytes. This packet takes the following format:
CIP Encapsulation Packet Definitions (Left-to-Right, Top-to-Bottom):
Command (2 Bytes):
The encapsulation command code is shown in Table 7, below. (Refer to the EtherNet/IP Specification for detailed command information.)
|0000H||NOP (No operation) – Sent only via TCP|
|0001..0003H||Reserved for legacy|
|0004H||List_Services – May be sent via TCP or UDP|
|0005H||Reserved for legacy|
|0006..0062H||Reserved for future expansion – compliant products may not use command codes in this range.|
|0063H||List_Identity – May be sent via TCP or UDP|
|0064H||List_Interfaces (optional) – May be sent via TCP or UDP|
|0065H||Register_Session – Sent only via TCP|
|0066H||UnRegister_Session – Sent only via TCP|
|0067..006EH||Reserved for legacy|
|006FH||SendRRData – Sent only via TCP|
|0070H||SendUnitData – Sent only via TCP|
|0071H||Reserved for legacy|
|0072H||Indicate_Status (optional) – Sent only via TCP|
|0073H||Cancel (optional) – Sent only via TCP|
|0074..00C7H||Reserved for legacy|
|00C8..FFFFH||Reserved for future expansion – compliant products may not use command codes in this range.|
A device must accept commands it does not support without breaking the session or underlying TCP connection. A status code that indicates an unsupported command has been received is returned to the sender instead.
Length (2 Bytes):
The length in bytes of the data portion of the encapsulation message (the number of bytes following the header). The total length of the message is the sum of the number in this field plus the 24-bytes of the encapsulation header. This field is 0 for messages that contain no data. Note that the entire encapsulation message must be read from the TCP/IP connection, even if the length is invalid for a command or it exceeds the internal buffer memory. Failure to read the entire message may result in losing track of the message boundaries in the TCP byte stream.
Session Handle (4 Bytes):
The session identification and is application dependent. Some commands do not require a session handle even if a session has been established (NOP for example).
Status (4 Bytes):
Status code indicates whether the receiver was able to execute the requested encapsulation command (0=execution successful). The sender sets this field to 0. If a receiver receives a non-zero status value, it will ignore the request and will not issue a reply.
Other values are used to indicate specific errors detected at the receiver as specified in Table 8, below:
|0001H||Invalid or unsupported command.|
|0002H||Insufficient memory resources for processing command.|
|0003H||Poorly formed or incorrect data in data portion of message.|
|0004..0063H||Reserved for legacy.|
|0064H||Invalid session handle.|
|0065H||Invalid length message.|
|0066..0068H||Reserved for legacy.|
|0069H||Unsupported encapsulation protocol revision.|
|006A..FFFFH||Reserved for future expansion. Compliant products may not use error codes in this range.|
Sender Context (8 Bytes):
The sender of a CIP command may place any value in this field of the header and the receiver will return the same value without modification in its reply. For example; it may be used to match requests with their associated replies. Commands with no expected reply may ignore this field.
Options Flags (4 Bytes):
The sender of a CIP command sets the options field to zero and the receiver verifies that the option field is zero and will discard an encapsulated packet with a non-zero option field. The intent is to provide bits that may modify the meaning of the encapsulation command, but no particular use for this field has been standardized yet.
Data (0-65511 Bytes):
This is command-specific data, and its structure depends on the command code. It may use a fixed structure or a common packet format (refer to CIP specification). Some commands will not require any data; this field may be left empty.
One of two objects control access to the object model of a device; the Connection Manager or the UnConnected Message Manager (UCMM).
As shown above, Ethernet/IP is a connection-based network and most CIP messages are accomplished through connections. CIP also allows multiple connections to coexist in a device at any given time (for example, Acromag 9xxEN-60xx modules allow up to 10 simultaneous Ethernet/IP connections, plus one Modbus TCP/IP connection and 16 simultaneous connections for the XTxxx2 series with no Modbus TCP/IP connections). When a connection is established, all transmissions that are part of that connection are associated with a Connection ID (CID). If the connection involves transmission in both directions, then two CIDs are assigned.
Of course, a process must exist to establish connections between devices that haven’t connected yet. Hence, this is the purpose of the Unconnected Message Manager (UCMM), which serves to process these connection requests. Once the UCMM has established a connection, all connection resources needed between the two devices (including bridges/routers) will be reserved for that connection.
Cyclic Connection & the Heartbeat
UDP and IP are not acknowledged transmission protocols. Consequently, a producer has no way of knowing if a consumer is online and receiving the data. So the producer must first establish a special “cyclic” connection to each of the consuming devices. This provides a mechanism to shut down a connection when a consumer is not connected to the network any longer. No application data is transmitted through this connection (called a “heartbeat”).
If the producer times out all the heartbeat connections associated with a specific produced data object, then all connections associated with that data object are closed.
All connections on a CIP network can be divided into either I/O connections (implicit), or explicit messaging connections.
Recall that explicit message connections are point-to-point communication paths between two devices. They follow a simple request/response network communication format and are always made to the message router (the Message Router Object). Each request contains explicit information (not time critical) that the receiving node decodes and acts upon, then generates an appropriate response. Thus, all explicit connections are direct connections between two devices, which require a source address, a destination address, and a connection ID in each direction. Explicit messages are normally triggered by events that are external to the CIP application layer.
Connections & Data Transmission
Implicit message connections provide dedicated special purpose communication paths (or ports) between a producer application object and one or more consumer application objects. They follow the producer/consumer-based connection model, and contain implicit (time-sensitive) data. The data is implicit because it’s identified at the time the connection is established and the connection IDs are assigned; so we say the data is implicitly defined by its connection ID. (Implicit messaging is commonly used for I/O messages.) It takes place within the application layer of the protocol with both the producer node and consuming nodes aware of the message content before transmission. Its chief distinction: there can be many simultaneous consumers of a single packet of data produced on the network. The UDP/IP/MAC protocol stack is used for implicit communication. This supports the requisite multicast communication (UDP also supports unicast and broadcast communication; TCP is restricted to unicast).
UDP packets are not transmitted directly to the actual IP address of a receiving device. Rather, they’re transmitted using a specific device-allocated IP multicast address. This address is used in parallel with the CIP connection ID; thus filtering out packets that aren’t relevant to a specific node before being presented to the application layer. However, before the data produced can be used, the consuming device must be made aware of this IP multicast address (allocated by the producer). Therefore, the Unconnected Message Manager is used to accomplish this.
A point-to-point TCP packet transmits from the connection originator. This indicates to a consumer the data object it wishes to receive and the rate that it wishes to receive it. The Connection Manager object is then interrogated to determine if there’s a match in its connection table to the data object and periodic rate. If it finds a match, then the data object is being produced (it’s a multicast message), and the Connection ID and related multicast IP address will return to the consumer. If there’s no match, then a UDP-related IP address and Connection ID are allocated and loaded into the Connection Manager object. The data starts production, and may be consumed by any device already aware of its multicast IP address/Connection ID. This clever use of a TCP packet to establish a connection between devices, and then UDP, to pipe the I/O data object conserves network bandwidth.
Learn more: What is PriorityChannel™?
The Transport Layer resides just below the Application Layer, and is responsible for the transmission, reception, and error checking of the data. There are several Transport Layer protocols that may operate at this layer, but the primary ones of interest are TCP and UDP. The application layer may choose to send its message using either the TCP or UDP transport layer protocols, depending on whether it is placing emphasis on speed (UDP), or reliability (TCP).
Transport Control Protocol (TCP)
With respect the port numbers commonly used in Ethernet/IP: UDP/UCM will use port 4418; UDP I/O will use port 2222, and CIP TCP will use 4418.
The Transport Control Protocol (TCP) resides one layer above the Internet Protocol (IP) and is responsible for transporting the application data and making it secure, while IP is responsible for the actual addressing and delivery of the data. Note from Figure 1 of the TCP/IP Stack section; the TCP packet is inserted into the data portion of the IP packet below it. IP itself is an unsecured, connectionless protocol and must work together with the overlaying TCP to operate. In this way, TCP is generally considered the upper layer of the IP platform that serves to guarantee secure data transfer.
Some CIP application messages are not time-critical, and for this kind of data, it’s more important that the data eventually arrive, than when it arrives. If this data is lost, it must be retransmitted. This type of data exchange refers to explicit messaging; it’s commonly used for exchanging information that’s necessary but not time-critical. That is, TCP uses explicit messaging and ensures that a message is received, but not necessarily on time.
TCP is a connection-oriented protocol. TCP establishes a connection between two network stations for the duration of the data transmission. While establishing this connection, conditions such as the size of the data packets are specified (which apply to the entire connection session).
TCP Client-Server Communication Model
The TCP Client is the network station that takes the initiative and establishes the connection. The TCP Server is the station to whom the connection is made. The server does nothing on its own, it just waits for the client to make contact with it. The client then makes use of the service offered by the server (note that depending on the service, one server may accommodate several clients at one time).
TCP verifies the sent-user data with a checksum, and assigns a sequential number to each packet sent. The receiver of a TCP packet uses the checksum to verify having received the data correctly. Once the TCP server has correctly received the packet, it uses a predetermined algorithm to calculate an acknowledgement number from the sequential number. The acknowledgement number is returned to the client with the next packet it sends as an acknowledgement. The server also assigns a sequential number to the packet it sends, which is then subsequently acknowledged by the client with an acknowledgement number. This process helps ensure that any loss of TCP packets will be noticed and that, if needed, they can then be re-sent in the correct sequence.
TCP also directs the user data on the destination computer to the correct application program by accessing various application services using various port numbers.
Telnet can be reached through Port 23, FTP through Port 21, and Modbus through Port 502. In this way, the port number is analogous to the room number in a large office building—if you address a letter to the public relations office in room 312, you are indicating that you wish to utilize the services of the public relations office. A port is the address used locally at the transport layer (on one node), and identifies the source and destination of the packet inside the same node. Port numbers are divided between: well-known port numbers (0-1023); registered user port numbers (1024-49151); and private/dynamic port numbers (49152-65535). Ports allow TCP/IP to multiplex and demultiplex a sequence of IP datagrams that need to go to many different (simultaneous) application processes.
With TCP, the transmitter expects receipt acknowledgement of the data packets from the receiver. Failure to acknowledge receipt either causes the transmitter to send the packet again or break the communication link. Since each packet is numbered, the receiver can determine if a data packet is missing (or it can reorder packets not received into the correct order). If any data is detected as missing, then subsequent received data will be buffered. After the data packet is complete and in the correct order, it will be passed up the protocol stack to the application. This error-checking mechanism of the connection-oriented TCP protocol takes time, and will operate slower than a connection-less protocol like UDP. Thus, sending a message via TCP only makes sense where either continuous data streams or large quantities of data are exchanged; or where a high degree of data integrity is required (with emphasis on secure data).
The following figure illustrates the construction of a TCP Packet:
TCP Header/Packet Contents
TCP Header Field Definitions (Left-to-Right and Top-to-Bottom):
Source Port (SP):
Port of sender’s application. (The port the sender is waiting to listen for a response from the destination machine.)
Destination Port (DP):
Port number of the receiver’s application. (The remote machine’s port that will receive the sent packet.)
Sequence Number (SN):
Offset from the first data byte relative to the start of the TCP flow; SN guarantees a sequence is maintained when large messages require more than one transmission.
Acknowledgment Number (AN):
AN is the sequence number expected in the next TCP packet being sent. It works by acknowledging the sequence number as sent by the remote host. That is, the local host’s AN is a reference to the remote machine’s SN, and the local machine’s SN is related to the remote machine’s AN.
Header Length (HLEN):
Measure of the length of the header in increments of 32-bit sized words.
These 6 bits are reserved for possible future use.
UAPRSF Flags (URG, ACK, PSH, RST, SYN, FIN):
- U = Urgent Flag: specifies that the urgent point included in this packet is valid.
- A = Acknowledgement Flag: specifies that the portion of the header that has the acknowledgement number is valid.
- P = Push Flag: tells the TCP/IP stack that this should be pushed up to the application layer program that needs/requires it as soon as time allows.
- R = Reset Flag: resets the connection.
- S = Synthesis Flag: synchronizes sequence numbers with acknowledgement numbers for both hosts (synthesis of the connection).
- F = Finish Flag: specifies that a connection is finished, according to the side that sent the packet with the F flag set.
Window Size (WS):
WS indicates how many bytes may be received on the receiving side before being halted from sliding any further and receiving more bytes, because of a packet at the beginning of the sliding window not having been acknowledged or received.
TCP Checksum (TCPCS):
A checksum that covers the header and data portion of a TCP packet to allow the receiving host to verify the integrity of an incoming TCP packet.
Urgent Pointer (UP):
UP allows a section of data, as specified by the urgent pointer, to be quickly passed up by the receiving host.
These bits are optional and rarely used.
TCP User Data:
Portion of the packet which may contain any number of application layer protocols (CIP, HTTP, SSH, FTP, Telnet, etc.).
The following simplified example illustrates a typical TCP transaction. In this example a network client (web browser) initiates data transfer with a web server (such as the web server embedded within the Acromag 9xxEN and XT series modules). The client is a PC, running Internet Explorer, connected to the network via a Network Interface Card (NIC).
Example TCP Transaction
A web browser always uses TCP for communication with a web server. Firstly, the web browser (client application) makes a service request to TCP of its transport layer for the opening of a connection for reliable data transport. It uses the IP address of the remote server, together with the well-known port number 80 (HTTP Protocol), as its socket address. TCP opens the connection to its peer entity at the web server by initiating a three-way handshake. If this handshake can complete and the connection successfully open, then data can flow between the web browser (client) and the web server (Acromag module).
Once a connection is made, the web browser and remote server assume that a reliable, open data pipe has formed between them. Then they begin transporting their data in sequence, and without errors, if TCP does not close the connection. TCP will monitor the transaction for missing packets and retransmit them as necessary, thus ensuring reliability.
As shown above, an observer in the data paths at either side of the router would only see the beginning of the message from the client to the web server; in the third data frame exchanged. (The client’s request message is combined with the connection acknowledgement of the third exchange.)
User Datagram Protocol (UDP)
Like TCP, the User Datagram Protocol (UDP) resides above IP and is another protocol for transporting data, but with the emphasis being to transport it on-time, rather than to guarantee delivery. UDP is a connectionless protocol that simply allows one device to send a datagram to another device without guaranteed delivery, a retry mechanism, or any acknowledgement.
Some CIP messages are time-critical. If this data is delayed, then its value is lost; thus, there’s no point in retransmitting it. This type of data exchange refers to implicit messaging, and is commonly used for real-time or control data. Time-critical, implicit messages of CIP are sent using UDP. UDP is faster than TCP and provides the quick, efficient data transport necessary for real-time data exchange.
In contrast to TCP, UDP is a connectionless oriented protocol. That is, the transmitter sends out a data packet, but does not expect to receive a confirmation that the packet has arrived at its destination. Further, the receiver accepts the incoming packets, but cannot tell if any packets are missing or in the wrong order; and uncorrupted data packets are passed up the protocol stack as they are received. The lack of any error checking overhead makes this protocol faster, though somewhat less reliable. Ethernet, IP, and UDP are all connectionless protocols.
UDP packets are treated as separate mailings, with no confirmation of packet receipt. It does not require connections to be established or broken off, thus no timeout situations occur. If a packet is lost, then data transmission continues unabated, and a higher protocol is usually responsible for repetition. Data integrity under UDP is generally handled by the application program itself. These characteristics effectively allow UDP to communicate much faster than TCP.
Sending a message via UDP makes sense where transmission parameters are changing frequently and when data integrity can instead be assured by a higher order protocol (the emphasis again here is on time-critical data).
In contrast, sending a message via TCP makes sense where either continuous data streams or large quantities of data must be exchanged, or if a high-degree of data integrity is required. (The emphasis here is on secure data.)
Ethernet/IP uses both TCP and UDP in an intelligent way to provide more deterministic performance. Therefore, time-critical, implicit messages are sent using UDP because it’s faster. On the other hand, explicit messages are sent using TCP for security. Lost data will not prevent subsequent time-critical data from being processed with UDP. Instead, the slower (but more reliable) TCP ensures messages are received by retransmitting any lost data; but this process may not be suitable for real-time data.
Figure 8, below shows the construction of a UDP packet and header:
UDP Header/Packet Contents
UDP Header Field Definitions (Left-to-Right and Top-to-Bottom):
Source Port (SP):
Port of sender’s application. (The port the sender is waiting to listen for a response from the destination machine.)
Destination Port (DP):
Port number of the receiver’s application. (The remote machine port where a sent packet is received.)
LEN is the calculated result of how many bytes are included in the UDP packet. This includes the 8 bytes of the UDP header, thus allowing the receiving station to know how many of the incoming bits are part of a valid packet.
UDP Checksum (UDPCS):
Covers the header and data portions of a UDP packet. Allows the receiving host to verify the integrity of an incoming UDP packet.
First, the UDP packet is loaded with a predefined number in the checksum field. When the checksum is computed, the new checksum is written over the previous value. Once the packet arrives at its destination, the destination machine’s operating system extracts bits 16-31 of this field; then it recalculates the checksum on the packet without anything in the checksum field. After that, the OS compares the calculated checksum to the one transmitted in the packet. If they’re the same, then the data will be judged reliable and allowed to pass through.
If the OS compares the calculated checksum to the one transmitted in the packet and they’re different, then the UDP packet and data will be dropped. No attempt will be made by the receiving machine to get a new copy, the packet won’t be retransmitted by the sending machine, and the packet becomes permanently lost. This is why UDP is considered unreliable. Hence, TCP is a better choice for a more reliable transport layer protocol.
UDP User Data:
A portion of the packet which may contain any number of application layer protocols (NFS, DNS, audio/video streaming protocols, etc.). If an error occurs in a UDP packet, and it needs to be fixed, then it’s up to the application layer to find the error and request its application layer to hunk/chunk the data.
The Network (or Internet) Layer resides just below the Transport Layer, and is responsible for routing the packets to the network. Although there are many network layer protocols such as ICMP, IGMP, and others, the most important of these are IP, ARP, and RARP.
Internet Protocol (IP)
Even though Ethernet/IP, TCP/IP, and UDP/IP are named together, the protocols are complimentary. The Internet Protocol (IP) manages the actual addressing and delivery of the data packets. IP provides a connectionless, unacknowledged method for sending data packets between two devices on a network. IP does not guarantee delivery of the data packet; it relies on a transport layer protocol (i.e. TCP) or application layer protocol (i.e. CIP) to do that. IP also makes it possible to assemble an indefinite number of individual networks into a larger overall network, without regard to physical implementation of the sub networks. That is, the data is sent from one network station to another, regardless of these differences.
An IP packet is a chunk of data transferred over the Internet using standard Internet Protocol (IP). Each packet begins with a header containing addressing and system control information. Unlike uniform ATM “cells,” IP packets vary in length (depending on the data being transmitted).
The table below shows contents of an IP header. As you can see, the first 5 rows are commonly used (20 Bytes). In contrast, the 6th (or more) rows will depend on how many 32-bit option words are required by special options. The data is the encapsulated packet of the upper Transport Layer (a TCP or UDP packet).
IP Header/Packet Contents
IP Header Field Definitions (Left-to-Right and Top-to-Bottom):
A 4-bit field that specifies what version of the Internet Protocol is being used (currently IP, version 4). IP version 6 has many advantages over IP version 4, but is not in widespread use yet.
Header Length (HLEN):
A 4-bit number specifying the increments of 32-bit words; HLEN tells the machine that decodes the IP packet where the IP header should end. (This dictates the beginning of the data.) For example, “0101” (5) would specify an IP packet having only the first 5 rows as header information and its data thus beginning with the 6th row.
TOS is used for special IP packet information that may be accessed by routers passing along the packet, or by receiving interfaces. The first 3 bits are reserved and the fourth bit is set to 0. The remaining 4 bits flag the following (respectively); minimizing delay for the packet, maximizing throughput then reliability for the packet, and finally, minimizing monetary cost.
Many application layer protocols have recommended values for each of these bits, based on the kind of service they use. For example, NNTP (Net News Transfer Protocol) is not a very time-critical operation. NNTP is used for USENET posts and group synchronization between servers, or to a client from a server. It’s okay if it happens to take a long time to transfer all this data. Since it’s not time sensitive, the “minimize monetary costs” bit may be set for a server synchronizing itself with another server under these conditions. Thus, it’s up to the router to determine the paths that are cheapest, and then route a packet based on the flags that are set.
There aren’t multiple routes to the packet’s destination. Therefore, if a router has only two routes (one to/from the internet and a second to/from a LAN), then these 4 bits are often ignored. These bits may be useful where a router has four routes to a distant network; each route using a medium that has specific cost-related bandwidth, reliability, or latency (i.e. fiber, satellite, LAN line, or VPN). With each of these links up through a router, an incoming packet may be routed via any of these paths. A router configured properly could take advantage of how the packet bits are set by the sender in determining which route to take.
Differentiated Services Code Point
These bits, sometimes known as the Differentiated Services Code Point (DSCP), which defines one of a set of classes of service. This value is usually set to 0, but may be used to indicate a particular Quality of Service request from the network.
Total Length (TL):
The total length of the IP packet in 8-bit (byte) increments. By subtracting header length (HL) from total length (TL), you can determine how many bytes long the data portion of the IP packet is. As a 16-bit value, valid ranges would be from 20 (minimum size of IP header) to 65535 bytes. A TL of 20 is unlikely (no data) but could happen if something was broken. Very large IP packets (greater than 1500 bytes) are also uncommon, since they must typically be fragmented onto some networks.
A 16-bit number that distinguishes one sent IP packet from another, by having each IP packet sent increment the ID by 1 over the previous IP packet sent.
Sequence of 3 fragmentation flags used to control where routers can fragment a packet (via Don’t Fragment flag), and to indicate the parts of a packet to the receiver; 001=More, 010=Don’t Fragment, 100= Unused
Fragmentation Offset (FO):
Byte count from the start of the original packet sent and set by any router that performs IP router fragmentation.
An 8-bit value used to limit the number of routers that a packet may travel through before reaching its destination (the number of hops/links which the packet may be routed over). Most routers decrement this number by 1 to prevent accidental routing loops. If the TTL drops to zero, the packet will be discarded; either by the server that has last decremented it, or the next server that receives it.
An 8-bit value used to allow the networking layer to know what kind of transport layer protocol is in the data segment of the IP packet. Example: 1=ICMP, 2=IGMP, 6=TCP, 17=UDP.
16-bit checksum (1’s complement value) for the header data that allows a packet to offer verification data, to help ensure that the IP header is valid. The header checksum is originally inserted by the sender, then it’s updated whenever the packet header is modified by a router. It detects processing errors on the part of the router or bridge, where the packet is not already protected (by a link layer cyclic redundancy check). Packets with invalid checksums are discarded by all the nodes in an IP network.
Source IP Address (32 bits):
IP address of the Source machine sending the data onto the network. Commonly, this address is represented by 4 octets; representing decimal values and separated by periods (255.255.255.10 for example).
Destination IP Address (32 bits):
This is the IP address of the Destination Machine where the packet is routed. As with the Source IP Address, the Destination IP Address is normally represented by 4 octets; representing decimal values and separated by periods (i.e. 255.255.255.10).
Options (Variable Number of Bits/Words):
Bits reserved for special features. Rarely used, but when they are, the IP header length will be greater than 5 (five 32-bit words), to indicate the relative size of the option field.
IP Data (Variable Number of Bits/Words):
Portion of the packet which may contain any number of nested protocols (TCP, UDP, ICMP, etc.).
A Network’s Infrastructure includes the physical hardware used to transmit data electronically, such as; routers, switches, gateways, bridges, as well as hubs.
A router is located at the gateway, where it directs the flow of network traffic and determines the route of packets as they travel from one network to another. Routers can either be hardware devices or software applications.
Ethernet (MAC) Address
Ethernet (or MAC) Address refers to the Media Access Control Address that uniquely identifies the hardware of any network device. The address is 48-bit fixed, unique, and assigned and hard-coded into an Ethernet device at the factory. MAC addresses are usually expressed in hexadecimal form, with 12 hex characters (6 bytes). The first 3 bytes (6 leftmost hex characters) represent the device manufacturer. The last 3 bytes (6 rightmost hex characters) are uniquely assigned by the manufacturer. All six bytes taken together uniquely identify the network device.
Do not confuse the Ethernet (MAC) Address with the Internet Protocol (IP) Address. IP is a 32-bit number assigned to your computer (see below), that can change each time you connect to a network.
TIP: To determine the Ethernet address of the NIC card installed in your PC; at the DOS command prompt, type WINIPCFG <Enter> (Windows 98), or IPCONFIG /ALL <Enter> (Windows XP).
Internet (IP) Address
IP addresses are 32-bit numbers, administered by an independent authority (InterNIC), and are unique to each device on the network. The IP address is a 32-bit value. It’s made up of four octets (8 bits), and each octet has a value between 0-255 (00H-FFH). Consequently, there are about 4.3 billion possible combinations of IP addresses. IP addresses are typically expressed as four decimal numbers (8-bit values) separated by a decimal point.
Large networks of corporations, communications companies, and research institutions obtain large blocks of IP addresses, then divide them into subnetworks within their own organization, and distribute these addresses as they see fit. The smaller networks of universities and companies will acquire smaller blocks of IP addresses to distribute among their users. Since the addresses are ultimately assigned by the Internet Assigned Number’s Authority, the IP address can be used to approximate the location of a machine.
Like the Ethernet Address, the IP address has two parts; the network address or Net ID (first part), and the host address or Host ID (last part). This last part refers to a specific machine on a given subnetwork (identified by the first part). The number of octets of the four total that belong to the network address depend on the Class definition (Class A, B, or C); this refers to the size of the network.
A Subnet is a contiguous string of IP addresses. The first IP address in a subnet identifies the subnet and it usually addresses the server for the subnet. The last IP address in a subnet is always used as a broadcast address. Further, anything sent to the last IP address of a subnet is sent to every host on that subnet.
Based on the 4 octets that make up the IP address, subnets are further broken down into three size classes. Class A subnets are subnets that share the first octet of the IP address. The remaining 3 octets of a Class A subnet will define up to 16,777,214 possible IP addresses (224 – 2). A Class B subnet shares the first two octets of an IP address (providing 216 – 2, or 65534 possible IP addresses). Class C subnets share the first 3 octets of an IP address, giving 254 possible IP addresses. Recall that the first and last IP addresses are always used as a network number and broadcast address, respectively. Therefore, we subtract 2 from the total possible unique addresses that are defined via the remaining octet(s).
A Subnet Mask determines which subnet an IP address belongs to. The use of subnet masks allows the network administrator to further divide the host part of this address into two or more subnets. Subnet masks flag the network address portion of the IP address, as well as the bits of the host portion, that identify the sub-network. By mask convention, the bits of the mask that correspond to the sub-network address are all set to 1’s (it would also work if the bits were set exactly as in the network address). It’s called a mask because it identifies the unique subnet that an IP address belongs to. The subnet mask does this by performing a bitwise AND operation between the mask itself and the IP address; with the result being the sub-network address and the remaining bits the host or node address.
The default IP address of this module is 220.127.116.11. If we assume that this is a Class C network address (based on the default Class C subnet mask of 255.255.255.0), then the first three numbers represent this Class C network at address 18.104.22.168, the last number identifies a unique host/node on this network (node 100) at address 22.214.171.124.
To further to divide this network into 14 subnets, the first 4 bits of the host address are required to identify the subnetwork (0110). Then we would use “11111111.11111111.11111111. 11110000” as our subnet mask. This effectively subdivides our Class C network into 14 subnetworks of up to 14 possible nodes each.
The first node address (0) should not be used; it’s reserved for the network server. The last node (255) is a broadcast address. Use of these node addresses for any other purpose may yield poor performance.
With respect to the default settings of Acromag 9xxEN modules:
- Subnet Mask: 255.255.255.0
- IP Address: 126.96.36.199
- Subnet Address: 188.8.131.52
Subnetwork address 184.108.40.206 has 254 possible unique node addresses. For our module, we’re using node 100 of 254 possible.
With respect to the default settings of Acromag XTxxx2 modules:
- Subnet Mask: 255.255.255.0
- IP Address: 192.168.1.100
- Subnet Address: 192.168.1.0
Subnetwork address 192.168.1.0 has 254 possible unique node addresses. We are using node 100 of 254 possible for our module.
At this point, we see each layer (application, transport, network, and data link layer) using its own address method. The application layer uses socket numbers, which combine the IP address with the port number. The transport layer uses port numbers to differentiate simultaneous applications. The network layer uses the IP address, and the Data Link layer uses the MAC address.
Address Resolution Protocol (ARP)
Address Resolution Protocol (ARP) is a TCP/IP function, residing at the network layer (layer 3), with the Internet Protocol (IP). Its function is mapping Ethernet addresses (the MAC ID) to IP addresses and maintaining a mapping table within the network device. Thus, a sending station can gather address information used to form a layer 2 frame, complete with the IP address and hardware (MAC) address.
Every TCP/IP-based device contains an ARP Table (or ARP cache). When the router needs to forward a datagram to the hardware address of a device (that it knows the IP address for), it refers to the ARP table. If Device A wants to transmit an IP packet to Device B; first Device looks in its ARP Table for Device B’s Ethernet address. Upon finding a match, Device A will pass the IP packet and Ethernet address to the Ethernet driver (physical layer). If no hardware address is found in Device A’s ARP table, then an ARP broadcast is sent to the network.
The ARP protocol queries the network, via a local broadcast message, asking Device B’s corresponding IP address to return its Ethernet address. Every connected station reads this broadcast, including the destination station. The destination station sends back an ARP reply with its hardware address attached. Then the router can forward the IP datagram to Device B. Lastly, the hardware address of the ARP response is saved in an internal table and used for subsequent communication.
ARP only knows its IP address and is used to search for another station’s MAC address.
RARP only knows its MAC address and is used to search for a local station’s IP address.
When we used the term “local broadcast message” above; Ethernet broadcast messages will pass through hubs, switches, and bridges, but will not pass through routers. As a result, broadcast messages are confined to the subnet where they originated; thus will not propagate out to the worldwide web.
How ARP Works
The IP driver uses “FF FF FF FF FF FF” as the Ethernet address; this ensures the broadcast message is recognized by all connected network stations. The station that recognizes its own IP address in the ARP request will confirm this with an ARP reply. The ARP reply is a data packet addressed to the ARP request sender. It has an ARP identifier indicated in the protocol field of the IP header.
Next, the IP driver extracts the Ethernet address obtained from the ARP reply and enters it into the ARP table. These dynamic entries don’t normally remain in the ARP table. Further, the entries will age out if the network station isn’t contacted within a few minutes (typically 2 minutes with Windows).
The ARP table may also support static address entries. Static addresses are not subject to aging, fixed, and manually written into the ARP table. Sometimes these static address entries pass the desired IP address to new network devices that don’t have IP addresses yet.
Recall that ARP allowed a station to recover the destination hardware (MAC) address when it knows the IP address. Reverse Address Resolution Protocol (RARP) is a complimentary protocol that resolves an IP address from a given hardware address (i.e. Ethernet address). A station uses RARP to determine its own IP address (it already knows its MAC address).
Learn more: How to Configure the Acromag Modbus OPC Server
Reverse Address Resolution Protocol (RARP)
RARP is the complement of ARP. It translates a hardware interface address to its protocol (IP) address.
ARP translates a protocol address to a hardware (MAC) address.
Like ARP, RARP is a layer 3 protocol that does not use an IP header. Additionally, RARP has its own packet format that it broadcasts on the local LAN within the data field of a layer 2 frame and it doesn’t need to be routed. (The Ethernet Type field of the layer 2 frame has the value 0835H in it to indicate an RARP request.)
RARP essentially allows a node in a local area network to request its IP address from a gateway server’s ARP table. The ARP table normally resides in the LAN’s gateway router and maps physical machine addresses (MAC addresses) to their corresponding Internet Protocol (IP) addresses. When a new machine is added to a LAN, its RARP client program requests the machine’s IP address from the RARP server (on the router). Assuming that an entry has been set up in the router table; the RARP server will return the IP address to the machine, which will then store it for future use.
ARP and its variant, RARP, are needed because IP uses logical host addresses (the IP address). Alternatively, media access control protocols (Ethernet, Token-Ring, FDDI, etc.) need MAC addresses. The network managers assign the IP addresses to IP hosts. This is accomplished by configuration file options and driver software, as a result, they’re sometimes called “software addresses.” LAN topologies can’t use these software addresses, and they require that the IP addresses are mapped to their corresponding MAC addresses.
A diskless workstation cannot read its own IP address from configuration files. They will send an RARP request (or BOOTP request) to a RARP server (or BOOTP server). The RARP server will find the corresponding IP address in its configuration files using the requesting station’s MAC address as a lookup, and then send this IP address back in a RARP reply packet.
ARP/RARP Header Structure
ARP/RARP Header Field Definitions (Left-to-Right, Top-to-Bottom):
Specifies a hardware interface type from which the sender requires a response. This is “1” for Ethernet.
The protocol type used at the network layer and used to specify the type of high-level protocol address the sender has supplied.
Hardware Address Length (HALEN)
This is the hardware address length in bytes which is “6” for an Ethernet (MAC Address).
Protocol Address Length (PALEN)
This is the protocol address length in bytes which is “4” for a TCP/IP (IP Address).
The code commonly used to indicate whether the packet is an ARP request (1), or an ARP response (2). Valid codes are as follows: 1 = ARP Request; 2 = ARP Response; 3 = RARP Request; 4 = RARP Response; 5 = Dynamic RARP Request; 6 = Dynamic RARP Reply; 7 = Dynamic RARP Error; 8 = InARP Request; 9 = InARP Reply.
Sender Hardware (MAC) Address
This is the 48-bit hardware (MAC) address of the source node.
Sender Protocol (Software) Address
This is the 32-bit senders protocol address (the layer 3/network layer address—the IP address).
Target/Destination Hardware (MAC) Address
Used in an RARP request. The RARP request response carries both the target hardware address (MAC address) and layer 3 address (IP address).
Target/Destination Protocol (Software) Address
Used in an ARP request. The ARP response carries both the target hardware address (MAC address) and layer 3 address (IP address).
Data Link Layer
The Data Link Layer (or Host-to-Network Layer) provides the protocol for connecting the host to the physical network. Specifically, this layer interfaces the TCP/IP protocol stack to the physical network for transmitting IP packets.
In Figure 1 of the TCP/IP Stack section above, we saw that various protocols at each different layer are encapsulated (nested) in the data frame of the next (lower) layer. That is, packets generally carry other packet types inside them, and their function is to often contain or encapsulate other packets. In this section, we will look at the lowest encapsulation layer (often referred to as the data link layer or the MAC layer) where Ethernet resides.
Bits are transmitted serially. They start with the least significant bit of each byte being transmitted at the physical layer. When the frame is stored on most computers, bits are ordered and stored with the least significant bit of each byte in the rightmost position. Generally, bits are transmitted right-to-left within the octets, and the octets are transmitted left-to-right.
Carrier Sense Multiple Access w/CD (CSMA/CD)
The data link layer also uses the CSMA/CD protocol (Carrier Sense Multiple Access w/ Collision Detection) to arbitrate access to the shared Ethernet medium.
Recall that with CSMA/CD, any network device can try to send a data frame at any time, but each device will first try to sense whether the line is idle and available for use. If the line is available, the device will begin to transmit its first frame. If another device tries to send a frame at approximately the same time (perhaps because of cable signaling delay), then a collision occurs. Consequently, both frames will be discarded. Following that, each device waits a random amount of time and will retry transmission until the frame is sent successfully.
Medium Access Control (MAC) Protocol
The Medium Access Control (MAC) protocol provides the services required to form the data link layer of Ethernet. This protocol encapsulates its data by adding a 14-byte header containing the protocol control information before the data and appending a 4 byte CRC value after the data. A short idle period (the minimum inter-frame gap), and an 8-byte preamble precede the entire frame.
Ethernet (MAC) Packet
The figure below shows, in detail, the construction of the Ethernet packet, along with its preamble (via the MAC protocol). Usually a short idle period precedes frame preambles, corresponding to the minimum inter-frame gap of 9.6 microseconds at 10Mbps. This idle time before transmission is to allow the receiver electronics at each station to settle after completion of the prior frame.
Ethernet (MAC) Frame Definitions (Left-to-Right & Top-to-Bottom):
Preamble & SFD (56-bits+8-bits SFD)
Technically, the preamble is not part of the Ethernet frame; it synchronizes signals between stations. It’s comprised of a pattern of 62 alternating 1’s and 0’s, followed by two set bits of “11.” The last 8-bits of the pattern are called the Start-of-Frame Delimiter (or SFD) byte. The 8-byte preamble/SFD is also preceded by a small idle period, corresponding to the minimum inter-frame gap period of 9.6us (at 10Mbps). After transmitting a frame, the transmitter must wait for this period to allow the signal to propagate through the receiver of its destination.
The preamble allows the receiver at each station to lock into the Digital Phase Lock Loop used to synchronize the receive data clock to the transmit data clock. When the first bit of the preamble arrives, the receiver may be in an arbitrary state (out of phase), with respect to its local clock. It corrects this phase during the preamble and may miss/gain several bits in the process. That’s why the special pattern of two set bits (11) mark the last two bits of the preamble. When it receives these two bits, it starts assembling the bits into bytes for processing by the MAC layer. When using Manchester encoding at 10Mbps, the 62 alternating 1/0 bits of the preamble will resemble a 5MHz square wave.
Ethernet (MAC) Packet
Destination Address (48-bits)
This 6-byte address is the destination Ethernet address (MAC Address). It may address a single receiver node (unicast), a group of nodes (multicast), or all receiving nodes (broadcast).
Source Address (48-bits)
This 6-byte address is the sender’s unique node address. Network layer protocols use source addresses to identify senders, and they allow switches/bridges to perform address learning.
This 2-byte field provides a Service Access Point (SAP) and is used to identify the type of network layer protocol being carried. The value 0800H indicates an IP network protocol, other values indicate other network layer protocols. For example, 0806H would indicate an ARP request, 0835H would indicate a RARP request. This field may be also used for IEEE 802.3 LLC (Logical Link Control), to indicate the length of the data portion of the packet.
CRC-Cyclic Redundancy Check (32-bits)
CRCs are added at the end of frames. They support error detection for cases where line errors or transmission collisions result in a corrupted MAC frame. MAC receivers discard frames with invalid CRCs without further processing. MAC protocols do not provide any other indication that a frame has been discarded due to an invalid CRC.
The Ethernet standard dictates a minimum frame size which requires at least 46 data bytes in a MAC frame. If a network layer tries to send less than 46 bytes of data, the MAC protocol adds the requisite number of 0 bytes (null padding characters) to satisfy this requirement. The maximum data size which may be carried in a MAC frame over Ethernet is 1500 bytes.
If a received frame is smaller than 64 bytes, it’s illegal. These frames may be the result of a collision and are called “runts.” Receivers will discard runts.
Any received frame which does not contain an integral multiple of octets (bytes) is also illegal (misaligned frame), as the receiver cannot compute the CRC for the frame and these will also be discarded by the receiver.
“Giants” are received frames that are larger than a maximum frame size; they’re also discarded by Ethernet receivers.
ELECTRONIC DATA SHEET (EDS) FILE
Unless there’s some mechanism for identifying which objects have been implemented in a device to an external application, the object model of a device is of no use. This is the purpose of the Electronic Data Sheet or EDS.
All Ethernet/IP devices are required to provide an Electronic Data Sheet (EDS) file to configure the devices. Various control software configuration tools and application programs use EDS files to help identify and understand the capabilities of a remote Ethernet/IP device.
EDS files are text files that are used by network configuration tools. They identify products and commission the products on a network. For example, an EDS file describes a product’s device type, product revision, and its configurable parameters on a network. Some devices embed the EDS file into hardware memory and do not require a separate physical (software) file.
EDS files must contain file revision information (File), identity object information (Device), device type information – DeviceNet, Ethernet/IP or ControlNet (Device Classification), physical connection information (Port), and connection information (Connection Manager).
EDS files may optionally contain parameter information used to configure specific attributes (Parameter), group information used to logically group parameters together (Group), enumeration information used to assign meaningful names to values (Enum), and other information.
Sample EDS File (983ENEIP.EDS)
Below is an example EDS file, taken from the Acromag Model 983EN-6012; a 12 channel digital I/O module: