Frame Relay
View on Wikipedia
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|

Frame Relay (FR) is a standardized wide area network (WAN) technology that specifies the physical and data link layers of digital telecommunications channels using a packet switching methodology.
Frame Relay was originally developed as a simplified version of the X.25 system designed to be carried over the emerging Integrated Services Digital Network (ISDN) networks. X.25 had been designed to operate over normal telephone lines that were subject to noise that would result in lost data, and the protocol featured extensive error correction to address this. ISDN offered dramatically lower error rates, in effect zero, and the extensive error correction overhead was no longer needed. The new protocol suite was essentially a cut-down X.25 with no error correction, leading to lower overhead, better channel efficiency, and often significantly overall higher performance than X.25.
Like X.25, Frame Relay is normally used in a circuit switched layout, where connections between two endpoints are long-term (in computer terms at least). This matches the normal use of the telephone network, which X.25 was designed to run on top of. This contrasts with protocols design to be short-term, like the internet Protocol, where every packet might go to a different endpoint. In practice, Frame Relay was often used as a bridging mechanism to link together local area network (LAN) systems or devices with dedicated links to back-end systems. Users are provided with a connection that encapsulates their data (in some cases including voice in VoFR) and sends that to a Frame Relay node which then forwards that to another endpoint where it is injected into the remote network, appearing as if it were local traffic. It is less expensive than using leased lines for this purpose and that is one reason for its popularity. The extreme simplicity of configuring user equipment in a Frame Relay network offers another reason for Frame Relay's popularity.
With the advent of Ethernet over fiber optics, MPLS, VPN and dedicated broadband services such as cable modem and DSL, Frame Relay has become less popular in recent years.
The Frame Relay standards were promoted by the Frame Relay Forum (FRF).
Technical description
[edit]The designers of Frame Relay aimed to provide a telecommunication service for cost-efficient data transmission for intermittent traffic between local area networks (LANs) and between end-points in a wide area network (WAN). Frame Relay puts data in variable-size units called "frames" and leaves any necessary error-correction (such as retransmission of data) up to the end-points. This speeds up overall data transmission. For most services, the network provides a permanent virtual circuit (PVC), which means that the customer sees a continuous, dedicated connection without having to pay for a full-time leased line, while the service-provider figures out the route each frame travels to its destination and can charge based on usage.
An enterprise can select a level of service quality, prioritizing some frames and making others less important. Frame Relay can run on fractional T-1 or E1, or full T-carrier or E-carrier system carriers. Frame Relay complements and provides a mid-range service between basic rate ISDN, which offers bandwidth at 128 kbit/s, and Asynchronous Transfer Mode (ATM), which operates in somewhat similar fashion to Frame Relay but at speeds from 155.520 Mbit/s to 622.080 Mbit/s.[1]
Frame Relay has its technical base in the older X.25 packet-switching technology, designed for transmitting data on analog voice lines. Unlike X.25, whose designers expected analog signals with a relatively high chance of transmission errors, Frame Relay is a fast packet switching technology operating over links with a low chance of transmission errors (usually practically lossless like PDH), which means that the protocol does not attempt to correct errors. When a Frame Relay network detects an error in a frame, it simply drops that frame. The end points have the responsibility for detecting and retransmitting dropped frames. (However, digital networks offer an incidence of error extraordinarily small relative to that of analog networks.)
Frame Relay often serves to connect local area networks (LANs) with major backbones, as well as on public wide-area networks (WANs) and also in private network environments with leased lines over T-1 lines. It requires a dedicated connection during the transmission period. Frame Relay does not provide an ideal path for voice or video transmission, both of which require a steady flow of transmissions. However, under certain circumstances, voice and video transmission do use Frame Relay.
Frame Relay originated as an extension of integrated services digital network (ISDN). Its designers aimed to enable a packet-switched network to transport over circuit-switched technology. The technology has become a stand-alone and cost-effective means of creating a WAN.
Frame Relay switches create virtual circuits to connect remote LANs to a WAN. The Frame Relay network exists between a LAN border device, usually a router, and the carrier switch. The technology used by the carrier to transport data between the switches is variable and may differ among carriers (i.e., to function, a practical Frame Relay implementation need not rely solely on its own transportation mechanism).
The sophistication of the technology requires a thorough understanding of the terms used to describe how Frame Relay works. Without a firm understanding of Frame Relay, it is difficult to troubleshoot its performance.
Frame-relay frame structure essentially mirrors almost exactly that defined for LAP-D. Traffic analysis can distinguish Frame Relay format from LAP-D by its lack of a control field.[2]
Protocol data unit
[edit]Each Frame Relay protocol data unit (PDU) consists of the following fields:
- Flag Field. The flag is used to perform high-level data link synchronization which indicates the beginning and end of the frame with the unique pattern 01111110. To ensure that the 01111110 pattern does not appear somewhere inside the frame, bit stuffing and destuffing procedures are used.
- Address Field. Each address field may occupy either octet 2 to 3, octet 2 to 4, or octet 2 to 5, depending on the range of the address in use. A two-octet address field comprises the EA=ADDRESS FIELD EXTENSION BITS and the C/R=COMMAND/RESPONSE BIT.

Address field (2 octets) - DLCI-Data Link Connection Identifier Bits. The DLCI serves to identify the virtual connection so that the receiving end knows which information connection a frame belongs to. Note that this DLCI has only local significance. A single physical channel can multiplex several different virtual connections.
- FECN, BECN, DE bits. These bits report congestion:
- FECN=Forward Explicit Congestion Notification bit
- BECN=Backward Explicit Congestion Notification bit
- DE=Discard Eligibility bit
- Information Field. A system parameter defines the maximum number of data bytes that a host can pack into a frame. Hosts may negotiate the actual maximum frame length at call set-up time. The standard specifies the maximum information field size (supportable by any network) as at least 262 octets. Since end-to-end protocols typically operate on the basis of larger information units, Frame Relay recommends that the network support the maximum value of at least 1600 octets in order to avoid the need for segmentation and reassembling by end-users.
- Frame Check Sequence (FCS) Field. Since one cannot completely ignore the bit error-rate of the medium, each switching node needs to implement error detection to avoid wasting bandwidth due to the transmission of erred frames. The error detection mechanism used in Frame Relay uses the cyclic redundancy check (CRC) as its basis.
Congestion control
[edit]The Frame Relay network uses a simplified protocol at each switching node. It achieves simplicity by omitting link-by-link flow-control. As a result, the offered load has largely determined the performance of Frame Relay networks. When offered load is high, due to the bursts in some services, temporary overload at some Frame Relay nodes causes a collapse in network throughput. Therefore, Frame Relay networks require some effective mechanisms to control the congestion.
Congestion control in Frame Relay networks includes the following elements:
- Admission Control. This provides the principal mechanism used in Frame Relay to ensure the guarantee of resource requirement once accepted. It also serves generally to achieve high network performance. The network decides whether to accept a new connection request, based on the relation of the requested traffic descriptor and the network's residual capacity. The traffic descriptor consists of a set of parameters communicated to the switching nodes at call set-up time or at service-subscription time, and which characterizes the connection's statistical properties. The traffic descriptor consists of three elements:
- Committed information rate (CIR). The average rate (in bit/s) at which the network guarantees to transfer information units over a measurement interval T. This T interval is defined as: T = Bc/CIR.
- Committed burst size (BC). The maximum number of information units transmittable during the interval T.
- Excess burst size (BE). The maximum number of uncommitted information units (in bits) that the network will attempt to carry during the interval.
Once the network has established a connection, the edge node of the Frame Relay network must monitor the connection's traffic flow to ensure that the actual usage of network resources does not exceed this specification. Frame Relay defines some restrictions on the user's information rate. It allows the network to enforce the end user's information rate and discard information when the subscribed access rate is exceeded.
Explicit congestion notification is proposed as the congestion avoidance policy. It tries to keep the network operating at its desired equilibrium point so that a certain quality of service (QoS) for the network can be met. To do so, special congestion control bits have been incorporated into the address field of the Frame Relay: FECN and BECN. The basic idea is to avoid data accumulation inside the network.
FECN means forward explicit congestion notification. The FECN bit can be set to 1 to indicate that congestion was experienced in the direction of the frame transmission, so it informs the destination that congestion has occurred. BECN means backwards explicit congestion notification. The BECN bit can be set to 1 to indicate that congestion was experienced in the network in the direction opposite of the frame transmission, so it informs the sender that congestion has occurred.
Origin
[edit]Frame Relay began as a stripped-down version of the X.25 protocol, releasing itself from the error-correcting burden most commonly associated with X.25. When Frame Relay detects an error, it simply drops the offending packet. Frame Relay uses the concept of shared access and relies on a technique referred to as "best-effort", whereby error-correction practically does not exist and practically no guarantee of reliable data delivery occurs. Frame Relay provides an industry-standard encapsulation, utilizing the strengths of high-speed, packet-switched technology able to service multiple virtual circuits and protocols between connected devices, such as two routers.
Although Frame Relay became very popular in North America, it was never very popular in Europe. X.25 remained the primary standard until the wide availability of IP made packet switching almost obsolete.
It was used sometimes as backbone for other services, such as X.25 or IP traffic. Where Frame Relay was used in the USA also as carrier for TCP/IP traffic, in Europe backbones for IP networks often used ATM or PoS, later replaced by Carrier Ethernet[3]
Relationship to X.25
[edit]| OSI model by layer |
|---|
X.25 was an important early WAN protocol, and is often considered to be the grandfather of Frame Relay as many of the underlying protocols and functions of X.25 are still in use today (with upgrades) by Frame Relay.[5]
X.25 provides quality of service and error-free delivery, whereas Frame Relay was designed to relay data as quickly as possible over low error networks. Frame Relay eliminates a number of the higher-level procedures and fields used in X.25. Frame Relay was designed for use on links with error-rates far lower than available when X.25 was designed.
X.25 prepares and sends packets, while Frame Relay prepares and sends frames. X.25 packets contain several fields used for error checking and flow control, most of which are not used by Frame Relay. The frames in Frame Relay contain an expanded link layer address field that enables Frame Relay nodes to direct frames to their destinations with minimal processing. The elimination of functions and fields over X.25 allows Frame Relay to move data more quickly, but leaves more room for errors and larger delays should data need to be retransmitted.
X.25 packet switched networks typically allocated a fixed bandwidth through the network for each X.25 access, regardless of the current load. This resource allocation approach, while apt for applications that require guaranteed quality of service, is inefficient for applications that are highly dynamic in their load characteristics or which would benefit from a more dynamic resource allocation. Frame Relay networks can dynamically allocate bandwidth at both the physical and logical channel level.
Virtual circuits
[edit]As a WAN protocol, Frame Relay is most commonly implemented at Layer 2 (data link layer) of the Open Systems Interconnection (OSI) seven layer model. Two types of circuits exist: permanent virtual circuits (PVCs) which are used to form logical end-to-end links mapped over a physical network, and switched virtual circuits (SVCs). The latter are analogous to the circuit-switching concepts of the public switched telephone network (PSTN), the global phone network.
Local management interface
[edit]Initial proposals for Frame Relay were presented to the Consultative Committee on International Telephone and Telegraph (CCITT) in 1984. Lack of interoperability and standardization prevented any significant Frame Relay deployment until 1990, when Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom formed a consortium to focus on its development. They produced a protocol that provided additional capabilities for complex inter-networking environments. These Frame Relay extensions are referred to as the local management interface (LMI).
Datalink connection identifiers (DLCIs) are numbers that refer to paths through the Frame Relay network. They are only locally significant, which means that when device-A sends data to device-B it will most likely use a different DLCI than device-B would use to reply. Multiple virtual circuits can be active on the same physical end-points (performed by using subinterfaces).
The LMI global addressing extension gives Frame Relay data-link connection identifier (DLCI) values global rather than local significance. DLCI values become DTE addresses that are unique in the Frame Relay WAN. The global addressing extension adds functionality and manageability to Frame Relay internetworks. Individual network interfaces and the end nodes attached to them, for example, can be identified by using standard address-resolution and discovery techniques. In addition, the entire Frame Relay network appears to be a typical LAN to routers on its periphery.
LMI virtual circuit status messages provide communication and synchronization between Frame Relay DTE and DCE devices. These messages are used to periodically report on the status of PVCs, which prevents data from being sent into black holes (that is, over PVCs that no longer exist).
The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves bandwidth by allowing routing updates and address-resolution messages to be sent only to specific groups of routers. The extension also transmits reports on the status of multicast groups in update messages.
Committed information rate
[edit]Frame Relay connections are often given a committed information rate (CIR) and an allowance of burstable bandwidth known as the extended information rate (EIR). The provider guarantees that the connection will always support the C rate, and sometimes the PRa rate should there be adequate bandwidth. Frames that are sent in excess of the CIR are marked as discard eligible (DE) which means they can be dropped should congestion occur within the Frame Relay network. Frames sent in excess of the EIR are dropped immediately.
Market reputation
[edit]
Frame Relay aimed to make more efficient use of existing physical resources, permitting the over-provisioning of data services by telecommunications companies to their customers, as clients were unlikely to be using a data service 45 percent of the time. In more recent years, Frame Relay has acquired a bad reputation in some markets because of excessive bandwidth overbooking.[citation needed]
Telecommunications companies often sell Frame Relay to businesses looking for a cheaper alternative to dedicated lines; its use in different geographic areas depended greatly on governmental and telecommunication companies' policies. Some of the early companies to make Frame Relay products included StrataCom (later acquired by Cisco Systems) and Cascade Communications (later acquired by Ascend Communications and then by Lucent Technologies).
As of June 2007, AT&T was the largest Frame Relay service provider in the US, with local networks in 22 states, plus national and international networks.[citation needed]
FRF.12
[edit]When multiplexing packet data from different virtual circuits or flows, quality of service concerns often arise. This is because a frame from one virtual circuit may occupy the line for a long enough period of time to disrupt a service guarantee given to another virtual circuit. IP fragmentation is a method for addressing this. An incoming long packet is broken up into a sequence of shorter packets and enough information is added to reassemble that long frame at the far end. FRF.12 is a specification from the Frame Relay Forum which specifies how to perform fragmentation on frame relay traffic primarily for voice traffic. The FRF.12 specification describes the method of fragmenting Frame Relay frames into smaller frames.[6][7][8][9][10]
See also
[edit]References
[edit]- ^ "Definition of "Frame Relay" on SearchEnterpriseWAN". Archived from the original on 9 April 2012. Retrieved 9 April 2012.
- ^ US 7333508, Rabie, Sameh; Magd, Osama Aboul & Abdullah, Bashar et al., "Method and system for Ethernet and frame relay network interworking", published 2008-02-19, issued 2004-12-09, assigned to Nortel Networks Ltd.
- ^ The Network Encyclopedia about Frame Relay, visited 14 July 2012
- ^ "X.225 : Information technology – Open Systems Interconnection – Connection-oriented Session protocol: Protocol specification". Archived from the original on 1 February 2021. Retrieved 10 March 2023.
- ^ "Frame relay". techtarget.com.
- ^ "Frame Relay Fragmentation for Voice". Cisco. Archived from the original on 13 August 2016. Retrieved 17 June 2016.
- ^ "How to use FRF.12 to improve voice quality on Frame Relay networks - Cisco Community". community.cisco.com. 18 June 2009.
- ^ "VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority)". Cisco. Retrieved 17 June 2016.
- ^ Malis, Andrew G. (ed.). "Frame Relay Fragmentation Implementation Agreement FRF.12" (PDF). Broadband Forum. Retrieved 19 June 2025.
- ^ "FRF.12 Frame Relay Fragmentation section in Frame Relay". www.rhyshaden.com. Retrieved 17 June 2016.
External links
[edit]- RFC 1490 – Multiprotocol Interconnect over Frame Relay
- RFC 1973 – PPP in Frame Relay
- RFC 2427 – Multiprotocol Interconnect over Frame Relay
- Technical Library | Broadband Forum - includes Frame Relay Forum documents
- Cisco Frame Relay Tutorial Archived 2012-11-06 at the Wayback Machine
- Frame Relay animation
- CCITT I.233 ISDN Frame Mode Bearer Services
Frame Relay
View on GrokipediaOverview
Definition and Purpose
Frame Relay is a standardized Layer 2 protocol operating at the data link layer of the OSI model, designed for transporting data across wide area networks (WANs) using virtual circuits to enable efficient packet switching.[1] It functions as an industry-standard, switched data link layer protocol that handles multiple virtual circuits, typically encapsulated with High-Level Data Link Control (HDLC) for reliable transmission over digital telecommunications channels.[1] This protocol emerged as a high-performance WAN technology in the late 1980s, providing a streamlined alternative to earlier protocols by minimizing overhead associated with extensive error handling.[1] The primary purpose of Frame Relay is to facilitate cost-efficient, high-speed data transfer for connecting local area networks (LANs) over public or private networks, particularly suited for bursty traffic patterns common in business applications.[7] It bridges the gap between the reliability-focused but slower X.25 protocol and the demands for faster, modern networking needs by combining statistical multiplexing with reduced latency.[8] Developed as a cost-effective substitute for dedicated leased lines, Frame Relay allows organizations to share bandwidth dynamically, reducing expenses for intermittent data flows without the need for constant full utilization.[9] At its core, Frame Relay relies on statistical multiplexing to allocate and share bandwidth among multiple users efficiently, enabling flexible use of network resources on a shared infrastructure.[1] Unlike more robust protocols, it does not provide guaranteed delivery or perform error correction at the protocol level, instead delegating such functions to higher-layer protocols and assuming a relatively error-free underlying network.[8] This approach results in lower processing overhead and higher throughput, making it ideal for environments where speed and efficiency outweigh the need for built-in reliability mechanisms.[10] Standardization efforts by organizations such as the ITU-T (e.g., Q.922) and ANSI (e.g., T1.618) ensured interoperability across diverse network implementations.[11][4]Key Characteristics
Frame Relay operates at the data link layer (Layer 2) of the OSI model, where it provides multiplexing and switching functions using variable-length frames addressed by Data Link Connection Identifiers (DLCIs).[11] DLCIs serve as locally significant labels to identify virtual circuits, enabling efficient multiplexing of multiple logical connections over a single physical link without requiring global addressing.[8] As a connection-oriented protocol, Frame Relay establishes end-to-end communication through permanent virtual circuits (PVCs) for dedicated paths or switched virtual circuits (SVCs) for on-demand connections, allowing reliable data transfer across wide area networks while sharing physical resources among multiple users.[12] This approach supports statistical multiplexing, where bandwidth is dynamically allocated based on traffic demands, making it particularly efficient for bursty data patterns typical of local area network interconnections.[8] Unlike earlier protocols, Frame Relay includes no built-in mechanisms for error correction or flow control at the data link layer, relying instead on the inherent reliability of underlying physical media and delegating such responsibilities to higher-layer protocols like TCP.[12] It performs basic error detection via a Frame Check Sequence but discards erroneous frames without retransmission, which minimizes processing overhead in the network.[8] The protocol's bandwidth efficiency stems from its support for access rates ranging from 56 kbit/s to 1.544 Mbit/s (T1) or higher, such as up to 45 Mbit/s on T3 lines, with statistical sharing that reduces costs for intermittent traffic by avoiding dedicated circuit reservations.[8] This design achieves low latency and high throughput, as frames experience minimal delay in transit.[12] Frame Relay's simplicity arises from its streamlining of X.25, eliminating the Link Access Procedure Balanced (LAPB) and extensive error-checking routines to reduce protocol overhead and enhance performance on modern digital networks.[12] By focusing solely on core framing and switching, it delivers a lightweight alternative suited to high-speed environments.[8]History
Origins and Development
Frame Relay originated from initial proposals submitted to the Consultative Committee for International Telephone and Telegraph (CCITT, now ITU-T) in 1984, where it was envisioned as a streamlined packet-switching protocol designed specifically for use over Integrated Services Digital Network (ISDN) interfaces.[1][13] This early conceptualization positioned Frame Relay as a faster alternative to the established X.25 protocol, which had become increasingly inefficient for emerging high-speed applications.[1] The core motivations for its creation stemmed from the limitations of X.25, including its substantial processing overhead from error correction and flow control mechanisms, which introduced significant latency unsuitable for integrating voice and data traffic in evolving digital telecommunications networks.[1] By simplifying these elements and relying on higher-layer protocols or physical layer reliability for error handling, Frame Relay aimed to support bursty data traffic more effectively, particularly for interconnecting local area networks (LANs) across wide area networks (WANs) at speeds up to T1 levels.[1][12] Development efforts gained momentum through collaboration among key industry players, including Digital Equipment Corporation, Northern Telecom, and StrataCom, whose work laid the groundwork for the technology; this was further propelled in 1990 when these companies, joined by Cisco Systems, formed a consortium to refine specifications and promote interoperability via the Local Management Interface (LMI).[13] Concurrently, the ANSI-accredited T1S1 committee in the United States began contributing to Frame Relay's technical framework in the late 1980s, with an initial service description approved in 1988.[14][1] Early adoption was limited by interoperability issues during the late 1980s, but U.S. carriers such as MCI and Sprint conducted pilots to test its viability for public networks.[1] These efforts culminated in the first commercial deployments around 1990, exemplified by Sprint's nationwide public Frame Relay service announcement that year, addressing the surging demand for affordable, scalable WAN solutions amid rising internetworking requirements from businesses.[15][1]Standardization and Evolution
The American National Standards Institute (ANSI) approved standard T1.618 in June 1991, which defined the core aspects of the frame protocol for use with the Frame Relay bearer service, establishing the foundational data link layer specifications for North American deployments.[4] This standard outlined essential functions such as frame delimiting, alignment, and transparency using a simplified subset of the Link Access Procedure for Frame mode bearer services (LAPF).[16] In 1992, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) incorporated these elements into Recommendation Q.922, adopting the LAPF core for international harmonization and ensuring compatibility across global networks. This ITU-T adoption facilitated broader interoperability by aligning Frame Relay with Integrated Services Digital Network (ISDN) frameworks. To accelerate adoption and ensure vendor interoperability, the Frame Relay Forum (FRF) was incorporated in 1991 by leading companies including Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation.[8] The FRF focused on developing implementation agreements beyond core standards, with FRF.1 serving as the initial specification for the User-to-Network Interface (UNI) supporting permanent virtual circuits (PVCs), released as a baseline document in the early 1990s and revised in subsequent versions.[17] These efforts addressed practical deployment challenges, such as signaling and management interfaces, promoting widespread commercial use. Frame Relay continued to evolve in the 1990s through FRF extensions that enhanced its capabilities for emerging applications. FRF.11, finalized in May 1997, introduced support for voice over Frame Relay by defining subframe multiplexing to combine voice, data, and signaling within PVCs, enabling cost-effective transport of real-time traffic.[18] FRF.12, approved in December 1997, added fragmentation procedures to break large data frames into smaller units, allowing interleaving with delay-sensitive traffic like voice.[19] Parallel to these, integration with Asynchronous Transfer Mode (ATM) backbones advanced via FRF.5 in December 1994, which specified network interworking for PVCs between Frame Relay and ATM domains, bridging the technologies in hybrid wide-area networks.[20] Compared to its predecessor X.25, Frame Relay simplified operations by replacing X.25's full LAPB framing with the streamlined LAPF core, omitting modulo-8 sequence numbering and automatic retransmission for error recovery.[12] This reduction in protocol overhead eliminated acknowledgments and windowing at the data link layer, enabling higher throughput on reliable modern transmission facilities while assuming upper-layer or physical-layer error handling.[21]Technical Architecture
Protocol Data Unit
The Frame Relay Protocol Data Unit (PDU), commonly referred to as the frame, is a variable-length unit that encapsulates upper-layer data for transmission over a Frame Relay network. It adheres to a simplified HDLC-like structure defined in ITU-T Recommendation Q.922, which provides core data link layer functions such as frame delimiting, transparency, and error detection without built-in flow or error control mechanisms.[11] The frame begins and ends with a flag sequence of 0x7E (binary 01111110), which is used for synchronization and delimiting; bit stuffing is applied to the payload to prevent false flags within the data.[12] The address field, which serves as the header, is typically 2 octets long but can extend to 3 or 4 octets for larger addressing spaces. It contains the Data Link Connection Identifier (DLCI), a 10-bit field in the basic format that uniquely identifies the virtual circuit between the data terminal equipment (DTE) and the network.[11] Additional bits within the address field include the Command/Response (C/R) indicator (1 bit), which distinguishes between command and response frames, though it is rarely used in practice; the Forward Explicit Congestion Notification (FECN) bit (1 bit), signaling congestion to downstream devices; the Backward Explicit Congestion Notification (BECN) bit (1 bit), indicating congestion to upstream devices; and the Discard Eligibility (DE) bit (1 bit), marking frames that can be discarded during congestion to protect higher-priority traffic.[12] For extended addressing, the Extended Address (EA) bits (1 bit per octet) allow the address field to expand beyond 2 octets, enabling a 23-bit DLCI in the 4-octet format to support up to approximately 8 million virtual circuits, though implementations often limit it to fewer for practicality.[11] The following table illustrates the bit layout for the standard 2-octet address field:| Octet 1 | Bit 8 (EA=0) | Bits 7-6 (DLCI 9-8) | Bit 5 (C/R) | Bits 4-1 (DLCI 7-4) |
|---|---|---|---|---|
| Octet 2 | Bit 8 (EA=1) | Bits 7-4 (DLCI 3-0) | Bit 3 (FECN) | Bit 2 (BECN) |
