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

Understanding Frame Relay

During the late 1980s, there was a rapid increase in demand for high-bandwidth WAN services. The proliferation of LAN-based end devices and growth in high-bandwidth applications fueled the need for higher speeds, low delay, and low-cost LAN interconnection.

Frame Relay was developed as a Layer 2 protocol that avoided some of the drawbacks of WAN services at the time, as follows:

The increased availability of error-free transmission lines reduces the need for protocols such as X.25 that perform hop-by-hop error correction. Instead, Frame Relay relies on higher level protocols to perform end-to-end error correction and flow control.

Whereas X.25 requires packet processing at Layer 3, Frame Relay strictly operates at Layer 2. This reduces the switching requirements drastically and reduces per-hop delay.

Unlike time-division multiplexing (TDM)based circuits, which provide fixed point-to-point connectivity, Frame Relay provides network connectivity via packet switching over logical virtual circuits that are similar to X.25. Frame Relay accomplishes this by using a data-link connection identifier (DLCI) to uniquely distinguish virtual circuits on a physical link. This allows for more flexibility and more efficient data transmission through statistical multiplexing.

Frame Relay has subsequently been extended further in the Frame Relay Forum (FRF) standards body to support multiple features such as MultiLink Frame Relay (MLFR), defined in FRF.16, and Frame Relay Fragmentation, defined in FRF.11 and FRF.12.

As you will learn in subsequent chapters that explore L2TPv3 and AToM transport of Frame Relay, both pseudowire protocols interact with three aspects of Frame Relay:

Frame Relay encapsulation to transport the Frame Relay frame on the pseudowire

Control Management/Protocol such as Operation, Administration, and Maintenance (OAM) to properly reflect attachment circuit and pseudowire state

Traffic management to emulate Frame Relay's inherent traffic management capabilities

This section explores these aspects of Frame Relay as a reference for later chapters.

Encapsulation

To better understand how Frame Relay provides its functionality, this section examines Frame Relay Frame structure. The Frame Relay frame format is standardized in two separate standard bodies:

Internationally via the ITU-T (formerly known at the CCITT) Q.922 Annex A specification

Domestically in the United States via the ANSI T1.618 specification

Figure 5-6 illustrates the basic Frame Relay encapsulation per the Q.922 Annex A specification.

The Frame Relay fields are described as follows:

Flag Like HDLC and PPP, the beginning and end of every Frame Relay frame is delimited with a 01111110 (0x7E).

Address The Address field is a 2-byte header that contains several subfields:

DLCI The DLCI is a 10-bit field that uniquely represents a virtual connection on the physical channel. If extended addressing is used, a 17- and 23-bit DLCI address is supported.

CR The Command/Response bit is not defined and not used.

EA The Extended Address bit is the last bit in each header byte. A value of 0 indicates that another header byte follows, whereas a value of 1 indicates that this is the last header byte. This definition allows Frame Relay to support larger DLCI values.

FECN (FE) The forward explicit congestion notification bit is set to 1 to indicate to the receiver that the frame encountered network congestion. The FECN is set on traffic sent from the sender to the receiver.

BECN (BE) The backward explicit congestion notification bit is set to 1 to indicate to the sender that the frame encountered network congestion. Because the BECN bit is set on frames traveling in the opposite direction of the frames that experienced congestion, there must be return traffic toward the sender from the receiver to accomplish this feedback loop. Both FECN and BECN bits should signify to upper layer protocols to perform some action upon indication of congestion.

DE The discard eligible bit indicates whether this frame can be dropped in response to network congestion. A value of 0 indicates a higher priority frame versus a frame marked with a DE value of 1.

Information The Information field is a variable length field from 5 to 4096 octets that contains upper layer protocol data.

FCS The FCS is a 16-bit CRC calculated against the Frame Header and Data fields to detect errors.

One of the items lacking in the ITU-T Q.922 Annex A and ANSI T1.618 Frame Relay frame structure is a field indicating the type of Layer 3 data stored in the Information field. In RFC 1490 (made obsolete by RFC 2427), the IETF extended the Frame Relay structure that was defined in previous standards to support a method of multiprotocol transport on Frame Relay. The Frame Relay format was extended, as illustrated in Figure 5-7.

In addition to the Flag, Address, Information, and FCS fields, RFC 2427 defines the following fields:

Control The Control field contains a value of 0x03 to indicate that this is an Unnumbered Information (UI) frame unless it is negotiated otherwise.

Padding You can add an optional 1-byte pad to alter the frame size to an even value.

Network Layer Protocol Identifier (NLPID) The NLPID identifies the Layer 3 protocol that is stored in the Information field. ISO/IEC TR 9577 defines the NLPID values. The NLPID is only 1-byte long, so the number of protocols that this field can represent is limited.

In those cases in which the NLPID is not defined for a protocol, the NLPID is set to 0x80 and an additional Subnetwork Access Protocol (SNAP) is added. Figure 5-8 illustrates the SNAP header format.

The SNAP fields are described as follows:

OUI The Organizationally Unique Identifier is a 3-octet field identifying the organization that administers the succeeding 1-byte Protocol Identifier (PID). Routed PDUs use an OUI of 0x000000 whereas Bridged PDUs use OUI of 0x0080C2.

Protocol Identifier (PID) PID is a 1-octet field managed by the organization identified in the preceeding OUI. The OUI and PID values together represent a unique protocol.

Cisco has an alternative Frame Relay encapsulation method to identify the Layer 3 payload. Instead of using an NLPID, Cisco uses a Protocol field to perform a similar function. Figure 5-9 illustrates the Cisco format. The Protocol field is a 2-byte field that is equal to the IEEE Ethertype or Cisco-invented codes to represent the protocol that is stored in the Information field.

Frame Relay Link Management Interface Protocol

The initial Frame Relay standards by ANSI and ITU-T failed to provide a means to allow the Frame Relay network and the Frame device to communicate their status. In 1990, Cisco, Nortel, DEC, and StrataCom (known as the Gang of Four) developed an interim specification known as Local Management Interface (LMI) to meet this requirement. The goal of LMI was to primarily allow for the exchange of information regarding the link/device status and the notification of logical circuit status. LMI accomplishes this goal by having the Frame Relay end device (data terminal equipment, or DTE) send polls while the Frame Relay network (data communication equipment, or DCE) responds to these polls over a predetermined DLCI. Although LMI refers to the Gang of Four specification, it is also the general term for this data-link mechanism. The ITU-T (Annex A Q.933A) and ANSI (Annex-D T1.617) developed and standardized subsequent variations of LMI.

This section explores the Gang of Four LMI implementation, sometimes referred to as Cisco LMI, and later addresses the differences when compared to the ANSI and ITU-T standards.

The LMI message contains a 5-byte header, a 1-byte message type, one or more information elements of variable length, and a 2-byte CRC as illustrated by Figure 5-10.

The first two bytes of the header are the same as the standard Frame Relay header shown in Figure 5-9. They contain the DLCI, CR, FECN, BECN, DE, and EA bits. However, the Gang of Four implementation uses a fixed DLCI value of 1023 to communicate.

The LMI Message Format fields are described as follows:

Control The Control field is fixed at 0x03 to indicate that this is an unnumbered frame.

Protocol The Protocol field is fixed at 0x09 to indicate that this is an LMI frame.

Call Reference The Call Reference field is unused and is fixed at 0x00.

Message Type The Message Type field is a 1-byte value corresponding to the category of message that is being sent.

The three common message types are as follows:

Status Enquiry 0x75

Status 0x7D

Update Status 0x7B

Information Element The Information Element is a variable length field that is composed of three additional fields:

One Byte Information Element Identifier

One Byte Length field

A variable length Information Element Data field

The type of Information Element passed depends on the preceding message type.

The type of Frame Relay interface determines the LMI messages and the order of the message exchange. Two types of interfaces exist:

User-to-Network Interface (UNI) A UNI connects a Frame Relay end device (DTE) to the Frame Relay network device (DCE).

Network-to-Network Interface (NNI) An NNI connects two distinct Frame Relay network devices (DCEs).

In a UNI environment, the DTE periodically sends status enquiry messages, and the DCE end responds with status messages. In an NNI environment, both devices send status enquiry and status messages. An update status message is an optional message that the Frame Relay network sends to the Frame Relay device. The next sections describe each message frame and compare the Gang of Four LMI with the Annex A and Annex D formats.

Status Enquiry Message Frame

A status enquiry message requests two types of information from the Frame Relay network:

A link integrity verification record request, which requests a sequence number exchange

A full status record request, which requests a status report on all logical permanent virtual circuits (PVC) on this port, in addition to a sequence number exchange

Figure 5-11 shows the format for a status enquiry message.

Regardless of whether the status enquiry message is a link integrity verification or a full status record, the message contains the following three components:

Message Type This byte field indicates the type of message that is sent. In the case of a status enquiry, this value is 0x75.

Report Information Element The first information element identifies the type of request: link integrity verification (0x01) or full status record (0x00).

Keepalive Information Element The second information element exchanges the sequence number values. The Send Sequence octet should contain the sender's current sequence number, whereas the Receive Sequence octet contains the last sequence number that the sender received. The Frame Relay end device increments its sequence number with every status enquiry message that is sent. Similarly, the Frame Relay network device increments its sequence number with every status message that is sent.

Status Message Frame

Status messages have a similar format to status enquiry messages; however, the number of information elements differs depending on the type of report information element. In response to a link integrity verification request, the status message consists of a message type, a report information element, and a keepalive information element. However, in response to a full status record, PVC status information elements are also sent:

Message type This 1-byte field indicates the type of message that is sent. In the case of a status message, this value is 0x7d.

Report information element The first information element identifies the type of request: link integrity verification (0x01) or full status record (0x00).

Keepalive information element The second information element exchanges the sequence number values and contains the same information as described earlier in the status enquiry message.

PVC status information element In a full status record, an additional PVC status information element is sent for each PVC on the port. In addition to the two octets after the length, which dictate the DLCI that this information element is reporting on, an additional octet indicates the PVC status. The first 4 bits indicating PVC state are as follows:

N New bit. The New bit indicates if the PVC was newly added since the last full status report (1) or if the PVC was provisioned (0) since the last full status report.

D Deleted bit. The Deleted bit is not used in a status message.

A Active bit. The Active bit indicates whether the PVC is active (1) or failed (0).

R Receiver bit. The Receiver bit is an optional implementation that provides a simple flow control mechanism to signal the end device to stop sending traffic to this particular PVC.

The latter three octets of the PVC status information element are optional. They indicate the bandwidth of the PVC and are specific to Gang of Four LMI.

Figure 5-12 shows the format of a status message containing a full status record.

Update Status Message Frame

Unlike a status message, which is sent in response to a status enquiry, an update status message (sometimes referred to as an asynchronous status update) can be sent from the Frame Relay network device to the Frame Relay end device to convey changes in the interface's PVC state.

The format of an update status message is similar to a status message with a few minor differences (see Figure 5-13). The update status message consists of a message type, report type information element, and a PVC status information element for only those PVCs that have changed state. No keepalive information element exchanges sequence numbers. The Delete bit in the PVC Status octet is set in this message to indicate PVC removal; however, the New bit cannot be set in the update status.

Comparing Gang of Four LMI with Annex A and Annex D

Several notable differences distinguish the Gang of Four LMI and Annex A and Annex D LMI:

The Gang of Four LMI uses DLCI 1023, whereas both Annex D and Annex A uses DLCI 0.

Reserved DLCI ranges differ among Annex A, Annex D, and the Gang of Four implementation. For a 10-bit DLCI address, Annex A and Annex D define a DLCI user range from 16991, whereas the Gang of Four range is 161007. Annex A and Annex D are supported in an NNI environment, whereas the Gang of Four LMI is supported only on UNI.

Annex A and Annex D update status messages can contain only a single PVC status information element. When multiple PVC states change, a separate update status message must be sent for each PVC that is affected.

Gang of Four LMI supports optionally carrying the PVC bandwidth in the PVC status information element.

The Gang of Four LMI utilizes a lower error threshold timer of 2, compared to the Annex D and Annex A threshold timer value of 3 for failed status message replies. A full description of the different timers and their standard defined values for each LMI type is listed in Table 5-3.

Title

Description

Cisco LMI

Annex D

Annex A

Managing Traffic

Frame Relay services typically provide traffic throughput guarantees per PVC. To meet those guarantees, it is critical that a mechanism be in place to provide traffic management capabilities. Frame Relay employs Frame Relay policing to determine ingress traffic admission policy and Frame Relay shaping for egress traffic management.

Frame Relay Traffic Policing

Frame Relay traffic policing is a quality of service (QoS) mechanism that is applied on ingress into the network as a means of admission control to limit the amount of traffic that an end device can send into the network.

Frame Relay policing can be represented as a token-based abstraction known as a leaky bucket model. Essentially, the leaky bucket model determines whether a frame is compliant or noncompliant based on the fate of a frame's associated token. The leak rate of these buckets represents the admission rate of traffic.

To check for compliancy, every incoming frame has an associated token that is placed in the bucket. If the incoming rate exceeds the leak rate, the total number of tokens will eventually exceed the depth of the bucket. Nonconforming traffic occurs when the frame's associated token exceeds this bucket depth. Noncompliant traffic is either dropped or tagged appropriately. If the token is allowed to pass, the associated frame is admitted. Frame Relay policing employs a similar model with dual buckets, known as a dual leaky bucket model. This model utilizes the following parameters:

CIR The time-averaged leak rate that the Frame Relay network agrees to support a logical connection. In the dual leaky bucket model, this is the leak rate of the first bucket.

Excess information rate (EIR) The average excess rate allowed above CIR. In the dual leaky bucket model, this is the leak rate of the second bucket.

Committed Rate Measurement Interval (Tc) The time interval in which the leaky bucket is replenished with committed burst (Bc)/CIR worth of tokens: Tc=Bc/CIR.

Bc The amount of committed traffic allowed during a Tc interval. This is represented in the dual leaky bucket model as part of the depth of the first leaky bucket: Bc= CIR*Tc.

Excess burst (Be) The amount of excess traffic allowed during a Tc interval. This is represented in the dual leaky bucket model as part of the depth of the second leaky bucket. Be can be set to 0 to cause all noncompliant frames in the second bucket to be discarded: Be=Tc*EIR.

In the dual leaky bucket model, Bc and Be tokens are replenished at every Tc interval for the first and second bucket respectively. When receiving a frame without the DE bit set, Frame Relay policing checks the frame for compliancy by determining whether the associated token of the frame is admitted through the first bucket. If the DE bit is set to 1, Frame Relay policing checks the frame for compliancy against the second bucket.

Frames that conform to the CIR of the first bucket are admitted into the network. Frames that are not CIR conformant (that is, the associated token exceeds the depth of the first bucket) are marked to be DE and are sent to the second bucket for EIR conformance.

Frames with the DE bit set are checked for EIR conformance in the second bucket. If the frame is EIR rate compliant, it is queued for transmission; otherwise, the frame is discarded.

Figure 5-14 shows the Frame Relay policing model and illustrates the different outcomes based on compliancy and token availability at the time.

Frame Relay Traffic Shaping

Frame Relay traffic shaping is a traffic management capability offered on a per-PVC basis on egress. Whereas Frame Relay traffic policing is an ingress admission policy, Frame Relay traffic shaping is intended to smooth outgoing traffic to a mean rate and, if necessary, queue traffic for transmission.

In Frame Relay traffic policing, the incoming rate of traffic was never adjusted and the packets were never queued; instead, packets were admitted at their incoming rate based on token availability. In the Frame Relay traffic policing case of noncompliancy, the traffic is potentially dropped. Frame Relay traffic shaping, on the other hand, buffers packets for later transmission in the case of noncompliancy to enforce an average egress rate over time. Frame Relay traffic shaping can be modeled as a leaky bucket, as shown in Figure 5-15.

Frames are sent through the shaper only if an associated token is available. If no tokens are available, the shaping function queues the frame for later transmission. Tokens are leaked out of the bucket at the CIR. At every Tc (Bc/CIR) interval, Bc/CIR worth of tokens is replenished. The maximum size of the bucket is Bc + Be. The Be component allows a burst capability above the CIR rate. The result of a potentially bursty ingress rate is a smoothed output stream of traffic.

Frame Relay traffic shaping can also adapt its traffic rates based on network conditions. For example, based on indicators of network congestion such as BECNs, the adaptive Frame Relay traffic shaping can reduce the token replenish rate to similarly reduce its outgoing traffic rate.