Introducing HDLC Encapsulation

In 1974, IBM developed one of the first bit-oriented synchronous protocols, known as Synchronous Data Link Control (SDLC). After IBM submitted the protocol to the ISO for international standardization, the ISO adapted the protocol and renamed it HDLC. HDLC is covered under the ISO standards ISO 3309 and ISO 4335. During the same period, the Consultative Committee for Telegraph and Telephone (CCITT), now known as International Telecommunication Union (ITU-T), adopted HDLC for the X.25 Link Access Procedure when developing standards for X.25 Data Transmission.

The frame formats between the ISO and ITU-T versions of HDLC share many similarities and have also served as the basis for future protocols such as Frame Relay and PPP.

HDLC was defined to operate in the following three modes:

• Normal Response Mode (NRM) Employs a master/slave relationship, whereby secondary (slave) station(s) can transmit only when the primary (master) station permits.

• Asynchronous Response Mode (ARM) Is similar to NRM mode, but it differs in that the secondary station(s) does not have to wait for permission from the primary station to send data. The primary station is responsible for link initialization, link teardown, and error recovery.

• Asynchronous Balanced Mode (ABM) All stations have equal status and do not require instruction from their peers to perform a task.

In addition to the ITU-T and ISO standards, Cisco modified the HDLC encapsulation and adapted it for use as a serial line encapsulation protocol. The Cisco implementation is used in full duplex point-to-point links and operates in ABM mode. Unlike the standardized HDLC implementation, the nonstandard Cisco version does not perform windowing or retransmission and uses an Ethertype field to indicate the Layer 3 payload.

As Chapter 8, "WAN Protocols over MPLS Case Studies," and Chapter 12, "WAN Protocols over L2TPv3 Case Studies" highlight, both L2TPv3 and AToM interaction with HDLC are limited to HDLC frame transport when dealing with Layer 2 pseudowire emulation. As such, this HDLC section focuses on the HDLC frame format. Figure 5-1 illustrates the HDLC frame structure.

Each field is described as follows:

• Flag The beginning and end of every HDLC frame must contain a 1-byte Flag Sequence field to delimit the frame. The flag sequence used is 01111110 (0x7E). Because these flags must be unique, it is critical that a 0x7E does not show up in the Data field. To avoid this scenario on synchronous links, HDLC uses a method known as bit stuffing, as defined in American National Standards Institute (ANSI) T1.618, to differentiate this sequence from a flag delimiter. If five consecutive 1s are detected, the bit stuffing technique inserts a 0 bit to avoid having six consecutive 1s in a row. Upon inspection of the frame, the receiving end removes the 0 bit when it detects five consecutive 1s to restore the original sequence. Two alternate flag fields include 0xFF to indicate an IDLE flag and 0x7F for an Abort flag.

• Address The Address field uniquely identifies each of the stations on the HDLC link. Depending on the operational mode (NRM, ARM, or ABM), the Address field could contain the primary or secondary station's address when sending command and response messages. ISO standard 3309 can be referenced for more detail on the use of the Address field.

  In Cisco HDLC encapsulation, instead of uniquely identifying a station, the Address field indicates the frame type.

  Valid values include these:

  0x0F for unicast frame

  0x80 for broadcast frame

  0x20 for compressed frame

  0x40 for padded frame

• Control The Control field contains sequence number information and command or response messages depending on the frame type. Three control frame types are defined in HDLC as follows:

  Information frame Figure 5-2 lays out the Control field octet for an information frame. The first bit of the control octet set to 0 indicates that the frame is an information frame. The N(S) and N(R) are 3-bit fields containing the transmitter's send and receive sequence numbers respectively. The P/F bit indicates whether this is a command request or response.

  Figure 5-2. Control Field FormatInformation Frame

  

  
  

  Supervisory frame Figure 5-3 lays out the Control field octet for a supervisory frame. The supervisory frame has a similar format to the information frame except that the first two bits are set to 0 and 1 to distinguish this frame as a supervisory frame, and bits 3 and 4 are supervisory function bits. The remaining fields have the same meaning as in the information frame.

  Figure 5-3. Control Field FormatSupervisory Frame

  

  
  

  Unnumbered frame Figure 5-4 lays out the Control field octet for an unnumbered frame. The first two bits are set to 1 to distinguish this frame as an unnumbered frame. The M bits convey different commands/responses. For information regarding the different M-bit encoding for various command/response message types, refer to the ISO 4335 standard. The P/F bit functions the same way as in other HDLC Control fields.

  Figure 5-4. Control Field FormatUnnumbered Frame

  

  
  

  Cisco HDLC encapsulation does not use the control octet. It sets it to 0.

  Protocol The Protocol field is specific to Cisco HDLC encapsulation. The value of the Protocol field identifies the upper-layer protocol stored in the succeeding Information field. Cisco adopted standard Ethertype values to identify most protocols (see Table 5-1), but it also developed additional protocol values for Layer 3 protocols that normally do not exist on Ethernet (see Table 5-2).

  Table 5-1. Ethernet Standard Values for Cisco HDLC Protocol Field

  Protocol Type	Protocol Field Value
  PARC Universal Protocol (PUP)	0x0200
  Xerox Network Systems (XNS)	0x0600
  IP	0x0800
  Chaos	0x0804
  RFC 826 Address Resolution Protocol (ARP)	0x0806
  Virtual Integrated Network Service (VINES) IP	0x0BAD
  VINES ECHO	0x0BAF
  DECnet Phase IV	0x6003
  Apollo Domain	0x8019
  Cisco SLARP	0x8035
  Digital Equipment Corporation (DEC) Bridge Spanning Tree Protocol	0x8038
  Apple Ethertalk	0x809b
  AppleTalk ARP	0x80f3
  Novell Internetwork Packet Exchange (IPX)	0x8137
  Multiprotocol Label Switching (MPLS) Unicast	0x8847

  
  

  Table 5-2. Cisco Invented Values for Cisco HDLC Protocol Field

  Protocol Type	Protocol Field Value
  Frame Relay ARP	0x0808
  IEEE Bridge Spanning Protocol	0x4242
  Bridged Ethernet/802.3	0x6558
  ISO Connectionless Network Protocol (CLNP)/International Organization for Standardization (ISO) End System-to-Intermediate System (ES-IS) destination service access point (DSAP)/SSAP	0xFEFE
  Novell IPX, Standard Form	0x1A58
  ES-IS	0xEFEF
  RSRB Raw	0x1996
  STUN Serial Tunnel	0x1997
  Compressed TCP	0x1999

  
  

• Information The Information field contains data that is to be transmitted and only appears when the Control field is set to be an information frame. The length of this field is variable and depends on the Layer 3 protocol to be carried.

• Frame check sequence (FCS) The FCS value contains a 2- or 4-octet cyclic redundancy check (CRC). If the receiver's CRC calculation differs from the value in the frame, the frame is flagged in error.