What is the “IEEE 802.3 (Basic)” Ethernet Frame?

This blog post presents a brief description of the IEEE 802.3 (Basic) Ethernet frame. It also identifies differences between this frame and the DIX Frame.

in 1985, the Institute of Electrical and Electronic Engineers (IEEE) published their first IEEE 802.3 standard, defining their own version of the Ethernet Frame. 

Over time, there were some changes to this Ethernet frame structure, and the current IEEE 802.3 (Basic) Ethernet frame is as shown below in Figure 1.

IEEE 802.3 Basic Ethernet Frame Format

Figure 1, The IEEE 802.3 (Basic) Frame Structure/Format.

Why the Word “Basic”?

I include the word “Basic” to differentiate this format of the Ethernet frame from other IEEE 802.3 formats, such as:

  • IEEE 802.3 Compliant Ethernet frame – with Q-Tag
  • IEEE 802.3 Compliant Ethernet frame – with Envelope Prefix and/or Suffix

These other two frames have also been standardized in IEEE 802.3.  However, each of these frame formats are different from each other. 

Very Similar to the DIX Frame

The IEEE 802.3 (Basic) Ethernet frame is almost identical to the DIX frame

It can have a minimum frame length of 64 bytes and a maximum frame length of 1518 bytes (not including the Preamble).  Hence, the length of this frame is identical to that of the DIX Frame

Preamble Differences

In reality, the Preamble of the IEEE 802.3 frame is identical to that of the DIX Frame. However, the IEEE Committees have defined the Preamble differently than the DIX Consortium.

I illustrate the Preamble (within the IEEE 802.3 Basic Ethernet frame) in Figure 2.

The Preamble for the IEEE 802.3 Ethernet Frame

Figure 2, Illustration of the Preamble (within the IEEE 802.3 Basic Ethernet frame).

The IEEE 802.3 Standard defines the Preamble as a 7-byte field (each byte with the value of 0xAA (or 10101010 – in binary format).  This standard also defines the 8th byte (of the Preamble) as a Start of Frame Delimiter (SFD).  In this case, the SFD byte always has the value of 0xAB (or 10101011 – in binary format). 

I show an illustration of the IEEE 802.3 (Basic) Ethernet frame format, with the SFD byte highlighted below in Figure 3.

IEEE 802.3 Basic Frame Structure with the SFD Byte Highlighted

Figure 3, Illustration of the IEEE 802.3 (Basic) Ethernet frame format, with the SFD byte highlighted. 

Please note that although the DIX and IEEE standards define the Preamble differently, if you look closely at the byte values (of the Preamble), the Preamble for the DIX Frame and the Preamble plus SFD for the IEEE frame are identical. 

The Length/Type Field

Another difference between the DIX and the IEEE 802.3 frames is in the “Type” or “Length/Type” field. 

I show an illustration of the IEEE 802.3 (Basic) Ethernet frame, with the Length/Type field highlighted in Figure 4.

IEEE 802.3 (Basic) frame Structure with the Length/Type Field highlighted

Figure 4, Illustration of the IEEE 802.3 (Basic) Ethernet frame format, with the “Length/Type” field highlighted. 

The first version of the IEEE 802.3 standard (published in 1985) defined this particular field as the “Length” field.  However, in 1997, the IEEE 802.3 Committee changed this field to the “Length/Type” field, to be compatible with the DIX Standard

How Does the Length/Type Field Work?

The current standards define the Length/Type field as follows:

If the Length/Type field value is 1500 (or 0x05DC in Hexadecimal)

If the Length/Type field is 1500 (or 0x5DC in hexadecimal), then this 16-bit field will function as the “Length” field.  The value of the “Length/Type” field will then reflect the number of octets, within the Data field of the Ethernet frame. 

If the Length/Type field value is greater than 1536 (or 0x0600 in Hexadecimal) – Compatible with DIX Frame

If the Length/Type field is greater than 1536 (0x0600 in hexadecimal), then this 16-bit field will function as a “Type” field.  In this case, the value of the “Length/Type” field indicates the type of protocol data, that the Ethernet frame is transporting (just like for DIX frames). 

In another blog post, I present a list of standard values for the Length/Type field (when the value is greater than 1536), along with their meaning.

What is the “DIX” Ethernet Frame?

This blog post briefly defines the DIX (Ethernet) Frame. It identifies key differences between this faame and other types of Ethernet frames.

The very first standard Ethernet frame was the DIX standard.

I show an illustration of this frame below in Figure 1.

DIX Basic Ethernet Frame Format

Figure 1, Illustration of the DIX (Ethernet) Frame.

We call this frame the “DIX” frame because DEC-Intel and Xerox Corporations (DIX) invented this standard.

With some very small changes to this Frame, the Institute for Electrical and Electronic Engineers (IEEE) developed its standard for an Ethernet frame. It referred to this particular frame structure as the IEEE 802.3 (Basic) Ethernet frame.

In another blog post, I will discuss the IEEE 802.3 (Basic) Ethernet frame in greater detail.

The DIX (Ethernet) frame can be as short as 64 bytes and as long as 1518 bytes (not including the Preamble).

A couple of things that differentiate this frame from the IEEE 802.3 (Basic) frame are:

  • The Preamble, and
  • The Type Field

I will discuss each of these items below.

The Preamble

I identify the location of the Preamble within the DIX frame below in Figure 2.

DIX Ethernet frame with the Preamble Highlighted.

Figure 2, The Location of the Preamble within the DIX Frame.

The main difference between the Preamble, within the DIX Frame, and that within the IEEE 802.3 (Basic) Frame is how they are defined.

I also show the byte format of the Preamble within the DIX frame below in Figure 3.

Close-up View of the Preamble - DIX Frame

Figure 3, The Byte-format of the Preamble within the DIX Frame.

I will list the characteristics/features of the Preamble below.

  • Consists of 8-bytes
  • The first seven (7) bytes contain the value of 10101010
  • The 8th byte contains the value: 10101011
  • The last two bits (of the Preamble) are set to “[1, 1,]” to denote the end of the Preamble and the start of the Destination Address field.

The Type Field

I show the location of the Type field (within the DIX Frame), below in Figure 4.

The DIX Ethernet Frame - with the Type field highlighted

Figure 4, Illustration of the Location of the Type-Field within the DIX Frame.

In the DIX Standard, the Type field is a 16-bit field containing an identifier that indicates the type of high-level protocol data we are carrying within the Data Field of the Ethernet Frame.

For example, if the Type field is set to 0x0800, then the Data Field (within this particular Ethernet frame) is transporting data that supports the IP (Internet Protocol).

In another blog post, I present a list of standard values for the Type field.

The IEEE 802.3 (Basic) and the other IEEE 802.3-compliant Ethernet frames all use the Type/Length for this 2-byte position within the Ethernet frame.

I have defined the Destination Address, Source Address, Data Field, and Frame Check Sequence fields in other blog posts.

What are the Various Types/Formats of Ethernet Frames?

This blog post presents an overview of the various types of Ethernet frames, that are in use today.

The purpose of this blog post is to list, itemize, and briefly describe the various types of Ethernet frames that are in use today.

This blog post will also provide links to blog posts with more details about these various Ethernet frames and the various fields (within these frames).

In short, there are five different types of Ethernet frames (that are widely used in networking today).

I present the byte format of each of these types of Ethernet frames in the figures below.

The DIX Ethernet Frame

The DIX Ethernet frame is the “DEC, Intel, Xerox” (DIX) Standard Ethernet frame.

A consortium of these three companies created this particular Ethernet format.

I present an illustration of the DIX Ethernet frame below in Figure 1.

DIX Basic Ethernet Frame Format

Figure 1, Illustration of the DIX Ethernet Frame

NOTE: The DIX and IEEE 802.3 Compliant (Basic) Ethernet frames each have a maixmum size (or length) of 1518 bytes (plus the Preamble).

I present a more detailed description of the DIX Ethernet frame in another blog post.

IEEE 802.3 Compliant (or Basic) Ethernet Frame

I illustrate the IEEE 802.3 (Basic) Ethernet frame below in Figure 2.

IEEE 802.3 Basic Ethernet Frame Format

Figure 2, Illustration of the IEEE 802.3 (Basic) Ethernet frame.

NOTE: The DIX and IEEE 802.3 Compliant (Basic) Ethernet frames each have a maixmum size (or length) of 1518 bytes (plus the Preamble).

I present a more detailed description of the IEEE 802.3 (Basic) Ethernet frame in another blog post.

IEEE 802.3 Compliant Frame with Q-Tag

We call this type of a frame a “Q-Tag” frame, because it includes the IEEE 802.1Q Tag. The literature also calls this tag the VLAN or priority tag. We discuss VLAN (Virtual LANs) in another post.

I illustrate the IEEE 802.3 Compliant Frame with Q-Tag below in Figure 3.

IEEE 802.3 Frame with Q-Tag - Ethernet Frame format.

Figure 3, Illustration of the IEEE 802.3 Compliant Frame with Q-Tag.

The maximum length of the IEEE 802.3 Frame (with Q-Tag) is 1522 bytes (plus Preamble).

I present a more detailed description of the IEEE 802.3 Compliant Frame – with Q-Tag, in another blog post.

IEEE 802.3 Complaint Ethernet Frame with Envelope Prefix and/or Suffix

I illustrate the IEEE 802.3 Compliant Ethernet Frame with Envelope Prefix and/or Suffix, below in Figure 4.

IEEE 802.3 Fraame with Envelope Prefix and Suffix - Ethernet Frame Format

Figure 4, Illustration of the IEEE 802 Compliant Ethernet Frame with Envelope Prefix and/or Suffix

The IEEE 802.3 Compliant – Envelope Frames, can have a maximum length of 2000 bytes (plus the Preamble).

I present a more detailed description of the IEEE 802.3 Compliant Ethernet frame with Envelope Prefix and Suffix in another blog post.

Jumbo Frame

I illustrate the Jumbo Frame before in Figure 5.

Jumbo Ethernet Frame Format

Figure 5, Illustration of the Jumbo Frame

The Jumbo Frame can be a large as 9018 bytes (in length) plus the Preamble.

I present a more detailed description of the Jumbo Ethernet frame in another blog post.

What is Broadcast Communication?

This blog post briefly defines the term Broadcast Communication. It also contrast Broadcast Communication with the terms Unicast and Multicast Communication.

In Computer Network Architecture, the three types of communication are:

These forms of communication can occur in Layer 2 (the Data Link Layer) and Layer 3  (the Network Layer). 

NOTE:  Layer 2 is the Data Link Layer. At this layer, the switch device works using MAC addresses for communication. Layer 3 is the Network Layer, where the router device uses the IP addresses for communication. 

In this case, the word “cast” refers to how many people or devices we send data to. As I mentioned above, we can send data in a unicast, multicast, or broadcast manner.

I will briefly define these terms below.

Unicast Communication

Unicast:  Means one-to-one communication. In this case, a single sender sends data to a single receiver or device. 

I show a simple illustration of Unicast Communication below in Figure 1.

Simple Drawing of Unicast Communication - One Sender Communicating with a Single Receiver.

Figure 1, Illustration of Unicast Communication.

Multicast Communication

Multicast:  This means one-to-many communication. In this case, a single sender sends data out to multiple devices in parallel. However, Multicast communication does not involve ALL DEVICES. Some devices on the network are excluded from this communication. This makes Multicast Communication different from Broadcast Communication. 

I show a simple illustration of Multicast Communication below in Figure 2.

Simple Illustration of Multicast Communication - A single sender communicates with multiple receivers.

Figure 2, Illustration of Multicast Communication. 

Broadcast Communication

Broadcast: Means one-to-all communication. In this case, a single sender sends data to ALL network devices. Broadcast is different from Multicast Communication in that (for Broadcast) the sender sends information to ALL devices and excludes no one. 

I show a simple illustration of Broadcast Communication below in Figure 3.

Simple Illustration of Broadcast Communication. A single sender communicates with all Receivers within a network.

Figure 3, Illustration of Broadcast Communication.

What is Broadcast Communication?

Broadcast is a type of data transmission where data is sent from one device to all devices on a network. 

In a Broadcast transmission, every packet is addressed to the network’s broadcast address. This means that every device on the network will receive the packet. 

It is a one-to-all transmission which means there is one sender, but the information is delivered to all the connected receivers. 

Broadcast is used for scenarios where a single device must communicate with all network devices. 

We mainly use the term “broadcast” for cable TV transmission, where a broadcast sends TV signals from one source (one point) to all the possible destinations (all points). 

Broadcast Communication is useful in network management packets such as ARP (Address Resolution Protocol) and RIP (Routing Information Protocol), where all the devices must see the data. 

NOT All Network Technologies support Broadcast Communication.

Not all network technologies support Broadcast addressing. X.25 nor Frame Relay do not support broadcast communication.

IPv4 (Internet Protocol Version 4), which is and has been the primary networking protocol for Packet-Switching communication, supports Broadcast Communication. However, in this case, the broadcast domain is the broadcasting host subnet (which is typically small). There is no way to do an internet-wide broadcast. Broadcasting is mainly confined to the local area network (e.g., Ethernet).

IPv6, which is intended to be the successor to IPv4, does not support broadcast communication. IPv6 relies on multicast addressing/communication instead.

I show an illustration of Limited Broadcast Communication below in Figure 4.

Examples of Broadcast Communication. Broadcast Comnmunication only broadcast packets to devices within a LAN. It does not broadcast to devices outside of a LAN.

Figure 4, Illustration of Limited Broadcast Communication.

Figure 4 shows that all packets will go to each receiver within the LAN for Broadcast Communication. However, this form of communication does not go past the router (which is outside of the LAN). Broadcast Communication is mostly for LAN-only communication.

Broadcast Communication is mainly for “within a LAN” communication. In other words, it only sends packets to devices within its Local Area Network.

When working with IPv4 packets, the Broadcast Address is 255.255.255.255. Whenever the Broadcast sends packets to this Broadcast Address, all devices (within the LAN) will receive these packets.

Unicast and Multicast do not have this restriction. These forms of communication can send packets outside of their LANs.

What is Multicast Communication?

This blog post briefly defines Multicast Communication. It also differentiates it from Unicast and Broadcast Communication.

In Computer Network Architecture, the three types of communication are:

These forms of communication can occur in Layer 2 (the Data Link Layer) and Layer 3  (the Network Layer). 

NOTE:  Layer 2 is the Data Link Layer.  At this layer, the switch device works using MAC addresses for communication.  Layer 3 is the Network Layer, where the router device uses the IP addresses for communication. 

In this case, “cast” refers to how many people or devices we send data to.  As mentioned above, we can send data in a unicast, multicast, or broadcast manner.

I will briefly define these terms below.

Unicast Communication

Unicast:  Means one-to-one communication.  In this case, a single sender sends data to a single receiver or device. 

I show a simple illustration of Unicast Communication below in Figure 1.

Simple Drawing of Unicast Communication - One Sender Communicating with a Single Receiver.

Figure 1, Illustration of Unicast Communication.

Multicast Communication

Multicast:  This means one-to-many communication.  In this case, a single sender sends data to multiple devices in parallel. 

However, Multicast communication does not involve ALL DEVICES.  Some devices on the network are excluded from this communication.  This makes Multicast Communication different from Broadcast Communication. 

I show a simple illustration of Multicast Communication below in Figure 2.

Simple Illustration of Multicast Communication - A single sender communicates with multiple receivers.

Figure 2, Illustration of Multicast Communication. 

Broadcast Communication

Broadcast: Means one-to-all communication.  In this case, a single sender sends data to ALL network devices. 

Broadcast is different from Multicast Communication in that (for Broadcast) the sender sends information to ALL devices and excludes no one. 

I show a simple illustration of Broadcast Communication below in Figure 3.

Simple Illustration of Broadcast Communication. A single sender communicates with all Receivers within a network.

Figure 3, Illustration of Broadcast Communication.

What is Multicast Communication?

Multicast is a type of data transmission where data is sent from one device to a group of devices on a network. 

It is a type of one-to-many communication where a single packet of data is transmitted to multiple recipients simultaneously. 

In a Multicast transmission, a single packet is addressed to a group of devices rather than to a single device like in Unicast.  The packet is then replicated and sent to all devices in the group, allowing for more efficient network resource use. 

Every packet is addressed to a multicast group address in a Multicast transmission.  This means that only devices that have subscribed to the multicast group will receive the packet. 

This characteristic (of communicating with many, but NOT ALL, receivers) makes multicast communication different from broadcast communication (in which a single device sends packets to ALL devices within the network). 

Multicast transmission is widely used in applications such as video streaming, online gaming, and real-time communication, where the same data must be sent to multiple recipients simultaneously.  For example, a video streaming application sends a video stream to a group of users watching the same video.

Examples of Applications using Multicast Communication

  • PPV Services for Events such as boxing matches or World Cup (Soccer Matches). 
  • Streaming Services, such as Netflix, Sling, Hulu, Amazon Prime Video, and Disney+.

I show a simple illustration of Multicast Communication to realize a Live-Streaming Service below in Figure 4.

Using Multicast Communication to realize a Live Streaming Application

Figure 4, Illustration of Multicast Communication to realize a Live-Streaming Service.

What is Unicast Communication

This blog post briefly defines the term Unicast Communication. It also contrast this term with the definitions for Multicast and Broadcast Communication.

In Computer Network Architecture, the three types of communication are:

These forms of communication can occur in Layer 2 (the Data Link Layer) and Layer 3  (the Network Layer). 

NOTE:  Layer 2 is the Data Link Layer.  At this layer, the switch device works using MAC addresses for communication.  Layer 3 is the Network Layer, where the router device uses the IP addresses for communication. 

In this case, the word “cast” refers to how many people or devices we send data to.  As mentioned above, we can send data in a unicast, multicast, or broadcast manner.

I will briefly define these terms below.

Brief Definition of Unicast Communication

Means one-to-one communication.  In this case, a single sender sends data to a single receiver or device. 

I show a simple illustration of Unicast Communication below in Figure 1.

Simple Drawing of Unicast Communication - One Sender Communicating with a Single Receiver.

Figure 1, Illustration of Unicast Communication.

Brief Definition of Multicast Communication

This means one-to-many communication.  In this case, a single sender sends data out to multiple devices in parallel.  However, Multicast communication does not involve ALL DEVICES.  Some devices on the network are excluded from this communication.  This makes Multicast Communication different from Broadcast Communication. 

I show a simple illustration of Multicast Communication below in Figure 2.

Simple Illustration of Multicast Communication - A single sender communicates with multiple receivers.

Figure 2, Illustration of Multicast Communication. 

Brief Definition of Broadcast Communication

Means one-to-all communication.  In this case, a single sender sends data to ALL network devices.  Broadcast is different from Multicast Communication in that (for Broadcast) the sender sends information to ALL devices and excludes no one. 

I show a simple illustration of Broadcast Communication below in Figure 3.

Simple Illustration of Broadcast Communication. A single sender communicates with all Receivers within a network.

Figure 3, Illustration of Broadcast Communication.

What is Unicast Communication?

In a Unicast transmission, a single sender sends data to a single receiver. 

In this case, every packet (or frame) is addressed to a specific device on the network.  We use unicast communication for point-to-point communication, where a single device (or station) communicates with another device or station. 

Generally, we use unicast communication to send a message, browsing a website, downloading a file, etc.

Examples of Unicast Communication

  • If a device has an IP address of 21.2.4.0 in a network and wishes to transmit a packet to a device with an IP address 32.12.5.0 (in a different network).

I show an illustration of this below in Figure 4.

Device at an IP Address Communicates with another Device, at a different Network, at a different IP Address

Figure 4, Illustration of a PC (with an IP address of 21.2.4.0) transmitting a packet to a device with an IP address of 32.12.5.0

  • 4 computers are connected to a switch.  If computer # 3 wants to directly communicate with computer # 2; this is unicast communication. 

I show an illustration of this example below in Figure 5.

Personal Computer communicating with another Personal Computer via an Ethernet Switch

Figure 5, Illustration of 4 Computers connected together via a switch. Computer # 3 is now communicating with Computer # 2.

  • Whenever we use a computer to browse a website, the web server acts as a sender, and our computer acts as the receiver. 

In Figure 6, I show an illustration of this particular example.

Personal Computer browsing a website, while connected to a Web Server

Figure 6, Computer (operating a web browser) while connected to a Web Server.

  • Downloading a file from an FTP server is an example of unicast transmission.  In this case, the FTP server is the sender, and our computer is the receiver. 

What is Running Disparity (RD)?

The Running Disparity (or RD) is defined as the difference between the number of logic 1 bits and logic 0 bits between the start of a data sequence and a particular instant in time during its transmission.


What is Running Disparity (RD)?

We define the Running Disparity (or RD) as the difference between the number of logic 1 bits and logic 0 bits between the start of a data sequence and a particular instant in time during its transmission.

In other words, the RD for a character is the difference between the number of logic 1 bits and logic 0 bits in that character.

Hence, if there are more logic 1 bits than logic 0 bits (within a character or string of consecutive bits), we can state that the RD is positive.

If there are more logic 0 bits than logic 1 bits, then we can state that the RD is negative.

Finally, if the number of logic 1 and logic 0 bits are the same, we can state that the RD is neutral or zero.

We can express the Running Disparity as either an integer or as a ratio:

EXPRESSING RD AS AN INTEGER NUMBER:

If you wish to express the RD of a character or string (of consecutive bits) as an integer number, then you can calculate the RD with the following equation:

RD = (Number of Logic 1 bits in the character or string) – (Number of Logic 0 bits in the character or string)

For example:  

The running disparity of the hexadecimal expression of 0x78 is 0.

To understand why this is the case, if we were to express this value in its binary format, we get 0111 1000.  The binary expression (for this value) contains four 0s and four 1s.

Thus, RD = 4 – 4 = 0

On the other hand, the running disparity of the hexadecimal expression of 0x7F is +6.

Again, if we were to express this value in its binary format, we would get 0111 1111.  The binary expression (for this value) contains seven 1s and one 0.

Hence, RD = 7 – 1 = +6

EXPRESSING RD AS A RATIO:

If you wish to express the RD of a character or string (of consecutive bits) as a ratio, then you would do the following:

  • Count the total number of logical “1s” in the expression.
  • Count the total number of logical “0s” in the expression.

And then express this information in the following format:

Number of Logical 1s (in character/string) :  Number of Logical 0s (in character/string)

For example:

We express the running disparity of the hexadecimal expression of 0x78 as:

4:4, which we can reduce (or simplify) to 1:1.

Likewise, we can compute and express the RD for the value 0x7F as
7:1.

Some communication and data storage system standards (such as Gigabit Ethernet/1000BASE-X, Fibre-Channel, etc.) require that we maintain the RD as near to neutral as possible.

The system designer must ensure that the ratio of logical 1 bits to logical 0 bits (over time) should be kept close to 1:1.

Thus, the System Designer must follow any character/string with negative disparity with another character/string with an equal amount of positive disparity, and vice-versa.

Keeping RD to a minimum is to maintain dc balance on the transmission medium.

The System Designer must ensure that the RD does not increase without bounds.

The 8B/10B line code is a specific example of a line code that requires and exercises control over RD.

NOTE:  Controlling and monitoring RD can also help detect transmission errors.

Has Inflaton got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

What does the expression 100GBASE-R Mean?

This post defines and describes the expression 100GBASE-R for 100Gbps Ethernet Applications.


What does the expression 100GBASE-R Mean?

For Ethernet applications, the IEEE 802.3 standard states that the term 100GBASE-R represents a group (or family) of Physical Layer (e.g., 100Gbps Transceiver) devices that do the following:

  • When it transmits its data towards the PMD (Physical Medium Dependent) device, it will:
    • Encode the CGMII data into the 64B/66B PCS (Physical Coding Sublayer) code.
      • This is what the -R suffix means, by the way.  
    • Divide (or de-multiplex) its outbound traffic into 20 PCS Lanes by routing each 66b (66 bit) block to a different PCS lane (in a round-robin manner).
    • It will often multiplex these 20 PCS Lanes into 4 or 10 physical (or electrical) lanes for CAUI-4 and CAUI-10 applications, as it transports this data to an Optical Transceiver (or PMD), respectively.
  • When it receives data (from the PMD), it will:
    • De-multiplexes these CAUI-4/CAUI-10 physical (or electrical) lanes of traffic that it receives from the Optical Transceiver into 20 PCS Lanes.
    • Combines (or multiplexes) these 20 PCS Lanes into a single stream of traffic as it routes this data towards the MAC (Media Access Control) device.
    • Decodes this data from the 64B/66B PCS code back into the CGMII (100Gbps Media Independent Interface) format.  

NOTE:  I discuss some of this processing (with 100GBASE-R data) for ITU-T G.709, Annex E mandated handling (before GMP Mapping this data into the OPU4 Payload) in Lesson 10; within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

In Summary

In summary, these 100Gbps Ethernet devices will encode their “outgoing” data into the 64B/66B PCS code before transmitting it over some media.  

These 100Gbps Ethernet devices will also decode their “incoming” data from the 64B/66B PCS code (to restore the data to its original CGMII content) as it receives this data.

In other words, the 100Gbps Ethernet system will encode this data into the 64B/66B PCS format solely to transport this data across the communication media.  

Once this Ethernet data has arrived (at the other end of the media), the Ethernet system will decode this data (from the 64B/66B PCS format) to restore it to its original content.

The bit rate of this 64B/66B PCS encoded 100Gbps Ethernet data stream is 103.125Gbps ‡ 100pm.

Why Do We Encode our 100Gbps Ethernet Data into this 64B/66B PCS Code before we transmit this data over Optical Fiber?

We encode this 100Gbps Ethernet (CGMII) data into this 64B/66B PCS Code before we:

  • Transmit this data over Optical Fiber, or
  • Map this data into an OPU4 Frame (again for transmission over Optical Fiber).

There are several reasons we encode this data (before transmission over Optical fiber).  But the main goals are to convert this data into a more conducive format for transport over Optical Fiber.  More specifically, by converting this data into the 64B/66B code, we:

  • Minimize Running Disparity (e.g., maintain DC balance) with our data, and 
  • Ensure that we have no long strings of consecutive “1s” or consecutive “0s” within the data, we transport over Optical Fiber.  
  • Offer greater management capability (within our 100Gbps signal) by including Sync Bits within our 66-bit blocks.   These Sync bits permit us to designate certain 66-bit blocks as data blocks and other 66-bit blocks as control blocks.  I discuss some of this in detail in Lesson 10 within THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!!

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

The Various 100GBASE-R Transceiver Devices

IEEE 802.3 also states that the Physical Layer (Transceiver devices) supporting the following standards must support the 100GBASE-R PCS encoding/decoding scheme.

  • 100GBASE-CR4
  • 100GBASE-CR10
  • 100GBASE-SR4
  • 100GBASE-SR10
  • 100GBASE-KP4
  • 100GBASE-KR4
  • 100GBASE-LR4
  • 100GBASE-ER4

Please check out the post on 64B/66B encoding to learn more about that encoding scheme.

Where is this PCS Encoder/Decoder Located?

IEEE 802.3 states that the 100GBASE-R PCS block (e.g., the entity that performs the PCS Encoding/Decoding) resides between the Reconciliation Layer and the PMA (Physical Medium Attachment), as shown in Figure 1 below.

IEEE 802.3 100Gbps Ethernet Architectural Diagram

Figure 1, Architectural Positioning of 100Gigabit Ethernet (from the IEEE 802.3 Standard)

But, in a real system, this PCS Encoder/Decoder often resides in the same IC containing the MAC (Media Access Controller).  

Figure 2 illustrates a MAC that includes the PCS Encoder and Decoder functions.

100GBASE-R Encoder and Decoder in MAC IC

Figure 2, Illustration of a Connection between the MAC and a 100Gbps Transceiver IC

This figure also shows the MAC or Switch IC exchanging data with the 100Gbs Ethernet Transceiver IC over a CAUI-4 or CAUI-10 Interface.

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!!

Temporary Discounts Available Now!!

What is the PSI – Payload Structure Identifier Byte

This post describes the role of the PSI (Payload Structure Identifier) byte, within the OPUk Overhead, is used within the OTN.

What is the PSI – Payload Structure Identifier (Byte and Message)?

The PSI Byte

The PSI (or Payload Structure Identifier) byte is an Overhead byte within the OPUk structure.

Figure 1 presents an OPU frame with the location of the PSI byte identified.

Generic OPU Frame with PSI Byte Highlighted

Figure 1, Illustration of an OPUk Frame Structure with the Overhead Bytes (along with the PSI Byte) Identified  

The purpose of the PSI byte is to permit an OTN Path Terminating Equipment (PTE) to transport a 256-byte PSI (payload structure identifier) message throughout the OTN (Optical Transport Network).

The primary purpose of this 256-byte PSI Message is to permit the Source PTE to alert the OTN (Network) of the type of data (or traffic) we are transporting within this particular OPU data stream.

Since each OPUk frame contains only 1 PSI byte, an OTN PTE will have to transmit 256 consecutive OPU frames to transmit this PSI message completely.

The OTN PTE will align its transmission of this 256-byte PSI message with the MFAS byte.

Please see the OTUk Frame Structure post for more information on the MFAS byte.

In other words, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x00”, then the OTN PTE will also be sending the first byte of the PSI message (e.g., PSI[0]) via the PSI byte-field.

Likewise, whenever the OTN PTE is transmitting an OTUk frame with the MFAS byte set to “0x01”, then the OTN PTE will also be sending the second byte within this 256-byte message (e.g., PSI[1]) via the PSI byte field, and so on.

Two Types of PSI Messages

An OTN Source PTE will transport one of two types of PSI Messages.

  • The Non-Multiplexed Traffic – PSI Message, and
  • The Multiplexed Traffic – PSI Message.

I will describe each of these types of PSI Messages below.  

The Non-Multiplexed Traffic PSI Message

We will use the Non-Multiplexed Traffic PSI Message when transporting Non-Multiplexed Traffic within our OPU data stream.

Examples of Non-Multiplexed Traffic would be:

  • Transporting 1000BASE-X via an OPU0 signal
  • 10GBASE-R via an OPU2e signal.
  • 100GBASE-R via an OPU4 Signal.

In other words, we are handling Non-Multiplexed Traffic whenever we only transport a single Non-OTN client signal via this OPUk data stream.  

I present an illustration of an OPU Frame, with the PSI field highlighted (along with a break-out of the Non-Multiplexed Traffic type of PSI Message) below in Figure 2.

OPU Frame with PSI Byte-Field highlighted and a Breakout of the Non-OTN Client/Non-Multiplexed PSI Message

Figure 2, Illustration of an OPU Frame, transporting the Non-Multiplexed traffic of PSI Message

NOTE:  The easiest way to tell if you’re working with the Non-Multiplexed Traffic type of PSI Message is to check and see if you see the CSF (Client Signal Fail) bit-field in PSI Byte # 2.

If the CSF bit-field is present, you’re dealing with the Non-Multiplexed Traffic type of PSI Message.

If the CSF bit-field is NOT present (within the PSI Message), then you are dealing with the other type of PSI Message.

The Multiplexed Traffic Type of PSI Message

We use the Multiplexed Traffic type of PSI Message anytime we work with an OPU server signal transporting numerous lower-speed ODUj Tributary Signals.

For example, if we mapped and multiplexed 80 ODU0 tributary signals into an OPU4 server signal, then this OPU4 signal would transport the Multiplexed Traffic type of PSI Message.

Figure 3 presents an illustration of an OPU Frame, with the PSI field highlighted, along with a break-out of the Multiplexed Type of PSI Message.

OPU Frame with PSI Byte-Field Highlighted and a Breakout of the Multiplexed Structure PSI Message

Figure 3, Illustration of an OPU Frame transporting the Multiplexed Traffic Type of PSI Message

Again, one big difference between the Multiplexed Traffic type of PSI Message and that for Non-Multiplexed Traffic is that the Multiplexed Traffic type of PSI Message will not have the CSF (Client Signal Fail) bit-field.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

The PSI Message

The PSI (Payload Structure Identifier) message is a 256-byte message that an OTN terminal will transport via the PSI byte for 256 consecutive OPUk/ODUk/OTUk frames.

Let’s talk a little bit about the data that we are transporting within these PSI Messages.  

PSI[0] – or PSI Byte # 0 – PT (Payload Type)

The first byte of the PSI Message (e.g., PSI[0]) carries the Payload Type (or PT) value.  The PT byte identifies the type of client data the OPUk structure is transporting via its payload.  

First, Table 1 presents a list of standard PT values and the corresponding client data types (being transported within the OPUk Structure).

Table 1a, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part I

PT - Payload Type - PSI Byte - Client Signal into OPUk

Table 1b, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part II

PT - Payload Type - PSI Byte - Client Signal into OPUk

NOTES: 

  1. We will discuss the PT = 0x07 case when mapping 100GBASE-R into an OPU4 in Lesson 4.  
  2. Access to Lesson 4 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

Table 1c, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part III

PT - Payload Type - PSI Byte - Client Signal into OPUk

NOTE: 

  1. We will discuss cases where PT = 0x20 and 0x21 in Lesson 5.  
  2. Access to Lesson 5 requires that you have a membership to “THE BEST DARN OTN TRAINING PERIOD” training.

Table 1d, PT (PSI[0]) Values, and the Corresponding Client Data within the OPUk Structure – Part IV

PT - Payload Type - PSI Byte - Client Signal into OPUk

Other posts contain detailed information on how ITU-T G.709 recommends that the System Designer map each client signal into their corresponding OPUk structure.

Click HERE for more information about the PT = 0x21 Method for Mapping/Multiplexing Lower-Speed ODUj signals into a Higher-Speed ODUk Signal.

The Remaining Bytes within the PSI Message

PSI bytes 1 and 3 through 255 are for “Mapping and Concatenation Specific” roles that we will discuss in another post. 

In Multiplexed-Traffic Type of PSI Messages

For the Multiplexed-Traffic type of PSI Message, we use these bytes to transport MSI (Multiplex Structure Identifier) information throughout the OTN.  

In other words, we will transport the MSI information (via these PSI Messages) for applications in which we are mapping/multiplexing lower-speed ODUj tributary signals into higher-speed OPUk/ODUk server signals.

The MSI aims to identify these lower-speed ODUj tributary signals we are transporting via this OPUk/ODUk signal to the OTN.  

You can think of the MSI as a passenger list or manifest of lower-speed ODUj tributary signals riding along (or being transported) within this OPUk server signal.  

In Non-Multiplexed-Traffic Type of PSI Messages

PSI byte 2, Bit 1 (for the Non-Multiplexed Traffic PSI Message) is the CSF (or Client Signal Fail) indicator.  The ITU-T Standards Committee has reserved PSI Byte 2, Bits 2 through 8 for “future standardization.”

We discuss the CSF indicator and the MSI information in other posts.

We also extensively discuss these PSI Messages within THE BEST DARN OTN TRAINING PRESENTATION….PERIOD!!!.  

You can click on the Banner below to learn more our this training package.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You Become an Expert on OTN!!  Click on the Banner Below to Learn More.

Discounts Available for a Short Time ONLY!!

For More Information on OTN-Related Posts in this Blog, click on the image below.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...

The BMP (Bit-Synchronous Mapping Procedure)

This post describes the Bit-Synchronous Mapping (BMP) for mapping non-OTN CBR client signals into an OTN signal.


What is the BMP (Bit-Synchronous Mapping Procedure)?

This post describes the BMP (Bit-Synchronous Mapping Procedure) for mapping a non-OTN CBR (Constant Bit Rate) client signal into an OPUk/ODUk signal.

NOTE:  Whenever ITU-T G.709 discusses procedures for mapping a client signal into an OPUk/ODUk signal, it will often refer to the OPUk/ODUk signal as the Server signal.  

Therefore, we will use the terms OPUk/ODUk and Server interchangeably throughout the remainder of this post.

ITU-T G.709 also defines two other mapping procedures that one can use to map a non-OTN CBR client signal into a Server signal.

(*) – Requires membership to THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!  to see this post.  

We discuss each of these other two mapping procedures in other posts.

What is the Bit-Synchronous Mapping Procedure?  

The name Bit-Synchronous Mapping Procedure means that there is a bit-synchronous relationship between the client signal (that we are mapping into an OPUk payload) and the bit rate of the OPUk payload.

In other words, the System Designer must ensure that ALL the following conditions are true before they can use the Bit-Synchronous Mapping Procedure to map a particular client signal into the OPUk payload.

  • The OPUk/ODUk/OTUk clock signal must be phase-locked (or synchronized) to the client clock signal, as Figure 1 illustrates below.

Timing Requirements between Client Signal and OPUk/ODUk Signal to use Bit Synchronous Mapping Procedure - BMP

Figure 1, Illustration of the Synchronization Requirements (between the OPUk/ODUk/OTUk signal and the client signal) to use BMP

  • We must use fixed-stuffing to handle rate differences (between the Client signal and OPUk/ODUk/OTUk signal).
    • In other words, we insert a fixed number of bits/bytes into the Server (OPUk) payload, along with the client data.
      • OPUk_rate = Client_rate + (Fixed_Stuff x Server_Frame_Rate);
  • Client bit-rate tolerances MUST NOT exceed the Server bit-rate tolerances.
    • For example, if the bit-rate tolerance for an OPUk is +/-20ppm, then the Client signal’s bit rate tolerance cannot exceed +/-20ppm.

New Comprehensive OTN Training…Available Now. Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!

ITU-T G.709 Recommendations on Using BMP

ITU-T G.709 recommends using BMP when mapping the following non-OTN Client Signals into each of the OPUk/ODUk Structures listed below in Table 1.

Table 1, List of Client Signals that ITU-T G.709 Recommends using BMP when mapping into an OPUk Structure

ITU-T G.709 Recommendations for the Bit-Synchronous Mapping Procedure (BMP)

BMP and De-Mapping Jitter

BMP offers the best de-mapping jitter of the three recommended Mapping Procedures.  

Fixed stuffing and the presence of the OTUk/ODUk/OPUk overhead bytes are the only contributions to mapping (and de-mapping jitter).  Justification events (which imposes 8UI-pp of mapping-related jitter) for AMP applications do not occur in BMP.

However, the System Designer will still need to implement a clock-smoothing or jitter attenuation scheme to comply with de-mapping jitter requirements.  

This requirement is especially true for SONET/SDH applications.

Summary

Finally, Table 2 summarizes the timing requirements (between the Client Clock Signal and that for the OPUk/ODUk clock) that the System Designer must comply with before using any ITU-T G.709 Recommended Mapping Procedures.  

Please note that I have highlighted the BMP items below with a “Red Rectangular” outline.

TABLE 2, MAPPING PROCEDURE TIMING REQUIREMENTS

BMP Mapping Requirements

Has Inflation got You Down? Our Price Discounts Can Help You Fight Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

For More Information on OTN Posts in this Blog, click on the Image below.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...