Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

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.

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.

Note

On asynchronous links, HDLC uses byte stuffing (sometimes referred to as character stuffing or escaping) to transform illegal byte values into a set of legal characters. The receiving end reverses this mechanism to obtain the original values.

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.

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.

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.

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

Protocol Type

Protocol Field Value

Protocol Type

Protocol Field Value

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.

Note

The Cisco version of HDLC can optionally utilize a simple keepalive mechanism that tracks the sequence numbers of messages that the two endpoints generate locally. Although this control/management protocol exists, neither Layer 2 Tunnel Protocol Version 3 (L2TPv3) nor Any Transport over MPLS (AToM) interact with this keepalive mechanism; instead, they carry these messages across transparently.