Which part of the ethernet frame helps a destination detect if there are errors in a frame?

Frame Format

Each Ethernet frame is defined by the format given in Figure 2.25.6 The 64-bit preamble allows the receiver to synchronize with the signal; it is a sequence of alternating 0s and 1s. Both the source and destination hosts are identified with a 48-bit address. The packet type field serves as the demultiplexing key; it identifies to which of possibly many higher-level protocols this frame should be delivered. Each frame contains up to 1500 bytes of data. Minimally, a frame must contain at least 46 bytes of data, even if this means the host has to pad the frame before transmitting it. The reason for this minimum frame size is that the frame must be long enough to detect a collision; we discuss this more below. Finally, each frame includes a 32-bit CRC. Like the HDLC protocol described in Section 2.3.2, the Ethernet is a bit-oriented framing protocol. Note that from the host's perspective, an Ethernet frame has a 14-byte header: two 6-byte addresses and a 2-byte type field. The sending adaptor attaches the preamble and CRC before transmitting, and the receiving adaptor removes them.

IPX/SPX

Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) is a Novell communications protocol suite derived from the Xerox Network System (XNS) protocol. Figure 1.8 shows how the IPX/SPX protocol stack maps against the OSI reference model.

IPX is a connectionless Layer 3 network protocol. Although multiple Novell protocols operate at Layer 4, SPX is the most common one. SPX, a reliable, connection-oriented protocol, was derived from the XNS Sequenced Packet Protocol (SPP). Network Core Protocol (NCP) provides interaction between clients and servers by defining connection control and service request/reply. Service Advertisement Protocol (SAP) allows servers to advertise their addresses and the services they provide.

Figure 1.9 shows an example of an IPX packet captured with Sniffer Pro.

How to Translate an IPX Address

Figure 1.10 describes an IPX address in more detail. The first 32 bits of the address are the network number and are configured by the network administrator. This number must be a hex value between 0x00000001 and 0xFFFFFFFD. In this case, the network number is configured as the hex value 0xBEEF. The last 48 bits of the address are the same as the Media Access Control (MAC) address and come from the NIC. In this case, the MAC address of the NIC is 00-20-E0-88-80-74, which is also used as the IPX node number.

Figure 1.10. Example of an IPX Address

NOTE

The default behavior for an IPX node is to adopt the NIC's MAC address as the IPX node number. However, a network administrator can choose to override this behavior by statically assigning an IPX node number to a system. Be careful, however! If the assigned node number is not unique on the network, you may end up with two systems on the network with the same IPX node number. This can cause serious network problems. You can use the Sniffer Pro software to find duplicate node numbers assigned on a network.

Priority-based flow control

PFC is very similar to priority link-level flow control that we described in Chapter 3 and is used to provide lossless operation for certain types of data center traffic, such as storage. Figure 5.3 shows an example implementation of PFC between switch stages.

Up to eight priority levels are supported with PFC, but typical implementations may use only two or three. In this example, the second switch stage uses traffic-class-based memory partitions with programmable watermarks. If an allocated memory partition starts to fill up and a watermark is crossed, a priority flow control message is generated and sent to the transmitting switch, which then stops sending frames assigned to that particular traffic class for a specified pause time included in the frame. Transmission is resumed when the pause time expires. This ensures that other noncongested traffic is not paused and, therefore, remains unaffected. Keep in mind that a single memory partition in a shared memory switch may be receiving data from multiple switch ports and, therefore, will need to send PFC messages to all of these ports once a watermark level is exceeded.

Priority flow control evolved from the IEEE 802.3x pause frame which was designed to pause all traffic if a receiving switch global memory started to fill up. The IEEE 802.1Qbb PFC frame format is shown in Figure 5.4.

This is effectively a standard Ethernet frame but with some predefined fields and a special payload. The important fields are defined as follows:

Destination MAC address: This field is set to a specially reserved multicast address of 0x0180C2000001 in order to identify the frame as an IEEE 802.1Qbb PFC frame.

Source MAC address: This is set to the MAC address of the sending device.

Ethernet type: This is set to 0x8808 for this type of frame.

Class-enable bits: These bits represent traffic classes 0–7. If a bit is set high, pause is enabled for that class.

Class time fields: For each class-enable bit that is set, these 16-bit values specify the length of time to enable pausing of the particular traffic class. A value of zero tells the sender to un-pause that particular traffic class.

The method in which these values are generated is somewhat vendor and implementation specific. For example, one switch may support eight traffic classes, while the other supports only two. In addition, the pause time and watermark settings depend on the round-trip flow control delay time as described in Chapter 3. The watermark settings must leave enough room in the memory partition so that frames in flight before pause is enabled will still have available memory space. Pause delay times must be long enough so that memory usage levels drop sufficiently before new frames start to arrive. For example, if jumbo frames are being used, or there are long distances between link partners, the watermark setting will need to be lowered and pause times will need to be increased.

Address Resolution Protocol

The IP protocol is capable of routing an IP datagram within the same IP segment (network address), or else it would need a router to route the datagram to a different IP segment (network address). The IP protocol uses the IP address specified in the destination IP field and the subnet mask to extract the destination IP network address to which the datagram must be routed. The IP protocol looks up in its routing table to determine whether the destination network is directly accessible by the node or whether it needs the router to route the datagram to the destination network. The reader needs to be reminded that the Ethernet protocol on the host node needs the MAC address of the destination node to prepare the Ethernet frame. The host node has a routing table with IP addresses mapped to Ethernet addresses, known as ARP cache. If the ARP cache does not have the MAC address mapped to its corresponding IP address entry, an ARP request is generated by the host node to discover the MAC address corresponding to its IP address. If the destination node is on the same network, this is resolved by the destination node upon its ARP reply, and the destination MAC address corresponding to destination IP address is resolved. If the datagram needs to be routed out of the network address, the IP on the host node generates an ARP request to resolve the IP address to the MAC address of the Ethernet interface on the router to which the network segment connects. In such a case, the MAC address of the router interface is used as an intermediate MAC address. Once the IP address to the MAC address is resolved, the Ethernet protocol can build the Ethernet frame next and encapsulate the IP datagram. An ARP packet is directly encapsulated (bypassing IP datagram) into an Ethernet frame, as shown in Fig. e73.6.

The destination address in the Ethernet frame is all 1s, indicating that it is a broadcast address. Fig. e73.7 illustrates the ARP packet format. Each field is described as follows:

Hardware type: 16-bit field that defines the type of the network on which ARP is running. Ethernet is given type 1

Protocol type: 16-bit field defines the protocol. For IPv4, the value of this field is 0 × 800

Hardware length: 8-bit field that defines the length of the physical address, which is 6 bytes for the Ethernet address

Protocol length: 8-bit field that defines the length of the logical address, which is 4 bytes for the IPv4 protocol

Operation: 16-bit field defining the type of packet. Two packet types are ARP request (1) and ARP reply (2)

Sender hardware address: The physical address of the sender node

Sender protocol address: The logical address of the sender node

Target hardware address: A field set to all 0s for an ARP request

Target protocol address: A field set to the IP address of the target node

Fig. e73.8 is a screen capture of an Ethernet frame using a sniffer program. Ping is executed from a node with IP address 192.168.1.3 to a node with IP address 192.168.1.4. The screen capture is divided into three panels. The upper panel displays six columns of information. Packet 6 is highlighted in the upper panel, showing that an ARP request was generated with the source address 00,045AA29675 and destination address FFFFFFFFFFFF, which is a broadcast address. Under the description column in the upper panel, the node with IP address 192.168.1.3 is broadcasting on the network to find the MAC address corresponding to IP address 192.1681.4. The Ethernet frame in the lower-right panel shows a destination address of FFFFFFFFFFFF, which is a broadcast address.

Fig. e73.9 represents the contents of the Ethernet frame and the ARP packet it encapsulates. The contents of the ARP packet displays the IP and MAC addresses of the sender's node. The target hardware address is 16 zeros and the target IP address is 192.168.1.4.

Ethernet/IP

Ethernet/IP uses standard Ethernet frames (ethertype 0x80E1) in conjunction with the Common Industrial Protocol (CIP) suite to communicate with nodes. Communication is typically client/server, although an “implicit” mode is supported to handle real-time requirements. Implicit mode uses connectionless transport—specifically the User Datagram Protocol (UDP) and multicast transmissions—to minimize latency and jitter.

Note

The “IP” in Ethernet/IP derives from “Industrial Protocol” and not “Internet Protocol,” because of the use of the Common Industrial Protocol (CIP). Similarly, the acronym “CIP” meaning “Common Industrial Protocol” should not be confused with “Critical Infrastructure Protection” of NERC CIP.

The CIP uses object models to define the various qualities of a device. There are three types of objects: Required Objects, which define attributes such as device identifiers, routing identifiers, and other attributes of a device such as the manufacturer, serial number, date of manufacture, etc.; Application Objects, which define input and output profiles for devices; and Vendor-specific Objects, which enable vendors to add proprietary objects to a device. Objects (other than vendor-specific objects) are standardized by device type and function, to facilitate interoperability: if one brand of pump is exchanged for another brand, for example, the application objects will remain compatible, eliminating the need to build custom drivers. The wide adoption and standardization of CIP has resulted in an extensive library of device models, which can facilitate interoperability but can also aid in control network scanning and enumeration (see Chapter 6, “Vulnerability and Risk Assessment”).

While the Required Objects provide a common and complete set of identifying values, the Application Objects contain a common and complete suite of services for control, configuration, and data collection that includes both implicit (control) and explicit (information) messaging.28

Ethernet Frames

Figure 5.13 shows the makeup of an Ethernet frame. A frame holds one packet of data. The first 8 bytes are the preamble. Some Ethernet systems don't transmit continuously, so the preamble is used to synchronize a receive clock before data is transmitted. In other Ethernet systems, data transmission is continuous, but the preamble has been retained to keep the frame structure.

The next 6 bytes are the destination address — the MAC address of the intended recipient of the packet. Next is the source address, the MAC address of the sender. This is needed to allow the recipient to respond to the source and also to allow switches to learn the MAC address on each port, for efficient packet routing. Following the address fields is the type/length field, which is used for several purposes. It can identify the higher-layer network protocol carried in the data field, as described next. It also identifies the length of the packet. Unlike ATM cells, Ethernet packets are of variable length, so something must tell the receiver when a packet ends.

Next is the data, the thing we want to transmit. It may have headers for higher-layer protocols embedded in it. The length of the data is between 46 and 1,500 bytes. Following the data is the frame check sequence, a cyclical redundancy code used for error checking but not correction. Error checking is described briefly in Chapter 3.

The IEEE 802.11 Frame

Although the IEEE 802.11 frame shares a lot with the Ethernet frame (which is one reason some packet sniffers can parse wireless frames as if they were Ethernet), there are a number of unique fields in 802.11. There are nine main fields, and the frame control (FC) field has 10 fields. The nine major fields of the IEEE 802.11 MAC frame are shown in Figure 3.14. The only fields in the two FC bytes that we will talk about are the From DS and To DS fields. (In some cases, the first three fields of the 802.11 MAC frame, the version, type, and subtype, are presented separately from the frame control flags, which are all bits.)

Frame control (FC)—This field is 2 bytes long and contains, among other things, two important flag bits: To DS (distribution system) and From DS.

Duration—This byte gives the duration of the transmission in all frame types except one. In one control frame, this “D” byte gives the ID of the frame.

Addresses—There are four possible address fields, each 6 bytes long and structured the same as Ethernet MAC addresses. The fourth field is only present when multiple APs are in use in an ESS. The meaning of each address field depends on the value of the DS flags in the FC field, discussed later.

Sequence control—This 2-byte field gives the sequence number of the frame and is used in flow control.

Payload—This field can be from 0 to 2312 bytes long. Usually it is fewer than 1500 bytes and holds an IP packet, but there are other types of payloads. The precise type and subtype of the content is determined by the content of the FC field.

CRC—The frame cyclical redundancy check is a 4-byte CRC-32, used to determine the nature of the acknowledgement sent.

Why does the wireless frame need to define four address fields? Mainly because the arrangements of wireless stations can be complicated. Is there an AP in the BSS? Is there more than one AP? What type of frame is being sent? Data? Control? Management? The number of address fields present, and what they represent, depend on the answers to these questions.

How do receivers know exactly how many addresses are used and what they represent? That’s where the two DS flags in the FC field come in. The meaning of the address fields (and possible presence of the Address 4 field) depends on the values of these two bits. Actually, there are five types of MAC addresses used in wireless LANs:

BSSID—This is usually the MAC address of the AP, but it is generated randomly in an IBSS or ad hoc network.

Transmitter Address (TA)—The TA is the MAC address of the individual station that has just sent the frame.

Receiver Address (RA)—The RA is the MAC address of the immediate receiver of the frame. This can be a group or broadcast address.

Source Address (SA)—The SA is the MAC address of the individual station that originated the frame. Due to the possible role played by the AP, the SA is not necessarily the same as the TA.

Destination Address (DA)—The DA is the MAC address of the final destination of the frame, and can also be a group or broadcast as well as an individual station. Again, due to the AP(s), this address might not match the RA.

The interplay among these address types and the meaning of the two DS flags for data frames is shown in Table 3.3.

Table 3.3. DS Bits and Wireless LAN Data Frame Address Fields

A look back at Figures 3.6 and 3.7 will show that these address patterns are reflected in the screen captures. The last two bits of the frame control flags are the DS bits, which are 01 (To AP) and 10 (From AP), respectively. The Proxima AP is passing the frame between the Cisco and Farallon wireless stations.

The Address 4 field appears only when there are multiple APs. Usually, data frames in a simple BSS with AP use DS bit combinations 01 and 10 to make their way through the AP from one wireless station to another.

VNTag

The VNTag is a 6-byte Ethernet tag inserted into the Ethernet frame immediately after the destination and source MAC address pair (MAC-DA and MAC-SA). Traditional Ethernet switches do not support the forwarding of frames where the source and destination MAC are on the same port, thus they do not forward frames between two VMs connected on the same switch port. VNTag resolves this issue by creating a virtual Ethernet (vEth) interface for each VM on the switch.

Note:

The IEEE MACsec (authentication and encryption) tag can precede the VNTag.

In other words, the VNTag binds a vNIC to a vEth interface and the reverse applies too. A “VNTag-aware” switch is capable of forwarding between vEth interfaces so frames are forwarded between VMs connected on the same physical port. These VMs are identified by the destination virtual interface identifier (dst_vif [14 bits]) and source virtual interface identifier (src_vif [12 bits]) fields in the VNTag. The implementation of VNTag can be done either as a VNTag-capable NIC or in the software by the hypervisor. It can also be implemented as a separate box commonly referred as a fabric extender that acts as a remote multiplexer toward an Ethernet switch. Figure 8.3 illustrates two fabric extenders connected to two Ethernet switches. Each fabric extender has 4 × 10GE uplinks to the Ethernet switches and 48 × 1GE down-facing ports toward the servers. The uplinks from the fabric extenders to the Ethernet switches use the VNTag header, and 48 virtual interfaces (vifs) are used to identify each down-facing 1GE port.

Note:

Palo, a CNA developed by Cisco, supports VNTag.

9.6 Virtual Leased-Line Service

VLL services are point-to-point services for the carriage of common Layer 2 protocols such as Ethernet, Frame Relay, Asynchronous Transfer Mode (ATM), Point to Point Protocol (PPP), and High Level Data Link Control (HDLC). Each of these link layer protocols are in ubiquitous use in global data and voice communication systems. In an attempt to provide a common transport for these protocols, a series of IETF RFCs was developed to encapsulate them in MPLS Label packets. This encapsulation is commonly referred to as the Martini Encapsulation, after Luca Martini, the original author.

From a QoS perspective, each of these protocols requires a particular service level. For example, ATM can be deployed in one of five modes: Constant Bit Rate (CBR), Real-time Variable Bit Rate (RT-VBR), Non-Real-time Variable Bit Rate (NRT-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). Each of these modes requires a different treatment, both at the edge and on the core of an MPLS network.

In general, these link layer protocols have the QoS attribute tolerances shown in Table 9.4.

Table 9.4. Virtual Leased-Line Protocol QoS Attributes

Note that Table 9.4 is not taking into account the type of information being carried in each of the link layer protocols and assumes that the correct service type is used in the right context and can only be used as a general guide.

Service delineation on HDLC/PPP links is per physical link; Ethernet, Frame Relay, and ATM, however, have the ability to multiplex multiple services on a single physical interface. Cisco IOS provides a command-line interface to support multiple subinterfaces on a single physical interface. A typical example of marking QoS at the edge is shown next. In the illustration, we notice that policy maps are attached to individual subinterfaces for various encapsulation types. In our illustration, we look at Ethernet, ATM, and Frame Relay encapsulation types, and each of them represent a Layer 2 point-to-point VPN.

Virtual Leased-Line Configuration

!

interface GigabitEthernet11/4

!

interface GigabitEthernet11/4.100

 encapsulation dot1Q 150

 xconnect 1.1.1.1 100 encapsulation mpls

 service-policy input <policy-map)

!

!

interface Serial0

 encapsulation frame-relay

!

interface Serial0.1 point-to-point

 ip address 3.1.3.1 255.255.255.0

 frame-relay interface-dlci 140

 service-policy input <policy-map)

!

interface ATM2/0

!

interface ATM2/0.1 point-to-point

 ip address 1.1.0.13 255.255.255.0

 no ip directed-broadcast

 pvc 0/100

 service-policy input <policy-map)

!

End

More sample configurations follow to help the reader understand this concept in more detail. In our “ATM-over-MPLS Configuration” illustration, we create a policy map named ATMoMPLS with a policer to enforce a CIR and appropriately mark traffic with an MPLS Experimental value of 5. This policy map is further attached to an ATM interface, which hosts an ATM-over-MPLS Layer 2 VPN.

ATM-over-MPLS Configuration

!

!

 class-map match-any ATMoMPLS

  match input-interface ATM6/0 ← All traffic on Main interface/Subinterface is matched

!

policy-map ATMoMPLS

 class ATMoMPLS ← Common policy for all traffic on interface/sub interfaces

  police cir 128000 bc 16000 be 16000

   conform-action set-mpls-exp-transmit 5

   exceed-action drop

!

interface ATM6/0

 service-policy input ATMoMPLS

 xconnect 192.168.2.1 20000 encapsulation mpls

!

End

In our “EoMPLS Port-Based Configuration” illustration, a policy map named REALTIME-Ingress is created to mark all traffic with an MPLS Experimental value of 5. This policy map is further attached to an Ethernet interface, which hosts an Ethernet-over-MPLS Layer 2 VPN.

EoMPLS Port-Based Configuration

!

!

!

Mls qos

!

mls qos marking ignore port-trust

!

class-map match-any REALTIME-Ingress

  description ### Matching Any ###

  match any

!

policy-map REALTIME-Ingress

  class REALTIME-Ingress

   set mpls experimental imposition 5 -------- Set MPLS EXP 5!

!

!

interface GigabitEthernet1/3

 description ### Link to CE – EWS Layer2 VPN Customer ###

 no ip address

 xconnect 3.3.3.3 1001 encapsulation mpls

 service-policy input voice-customer

!

End

4.2 The “one for one” strategy

The more straightforward encapsulation strategy is to put each global CAN frame in a separate Ethernet frame and to transmit it as soon as possible. The expected benefit is a minimal delay. This strategy has been evaluated by a Simulation model (queueing network implemented in QNAP2). We consider an Ethernet link at 100 Mbs and TB = 0.05 ms (considering a modern microprocessor). The non-CAN Ethernet traffic is equally distributed between frames of 500, 1000 and 1500 bytes. There are two traffic sources for each frame length, one generating 40 % of the corresponding traffic and the other one the remaining 60 %. The curve n = 1 of figure 5 shows the results for the example application of table 1 and 2.

We notice that there are missed deadlines for CAN frames as soon as non-CAN Ethernet load is greater than or equal to 20 Mbs. When this load is 35 Mbs, 4 % of CAN frames miss their deadline. Above 35 Mbs, the percentage of temporal faults on CAN frames increases dramatically.