Frame relay makes a slight change to the HDLC frame in combining the Address and Control fields as illustrated on the Frame Relay Format Diagram. One of the primary changes is the DLCI (data link connection identifier), which replaces the Address field to indicate to which virtual circuit the frame is destined. Notice there is no Control field that would normally be used to contain send and receive counts for keeping track of the frames. Frame relay leaves recovery of lost or corrupted frames to the higher layers. It does, however, make some accommodations for flow control with the use of congestion indicators. These are turned on by the frame relay network switches to indicate the link is experiencing congestion, but the frame relay network itself does not throttle the data. That is left to other components such as access routers that are capable of sending an ICMP Source Quench message to the feeder nodes.

The Frame Relay header can be 2, 3, or 4 bytes long, depending on the number of DLCIs that are desired. The "EA" bit (Extended Address) is used to indicate additional bytes in the header. The way it does this is that, in a 4-byte Frame Relay header, the first 3 bytes will have their EA bit set to 0, and the last byte's EA bit will be set to 1, indicating the last header byte.

The DLCI value (10 bits--6 bits in Byte 1 and 4 bits in Byte 2), can either have local significance or global significance. If globally significant, the total number of frame relay connections in the network is restricted. For example, with a 10-bit DLCI, only 1,022 connections can be established (DLCIs 0 and 1,023 are reserved for signaling and management functions). With local significance, each link remaps the DLCI such that the end-to-end connection is identified by a series of local DLCIs. This local significance allows a much larger number of connections to be maintained in the network at the cost of maintaining local DLCI mapping in each network element, such as the frame relay switch.

The C/R (command/response) bit is user-defined and is not set or changed by the frame relay network.

The forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN) bits are used for flow control on busy networks. The discard eligibility (DE) bit is set when the user goes over the committed information rate (CIR), which is the rate of information transfer that is being charged, such as 56 Kbps, by the frame relay provider. This does not necessarily mean that the frame will actually be discarded. It is simply a flag to indicate that it would be a first candidate to be dropped should buffer depletion start to occur across any of the network resources.

How is flow control accomplished on Frame Relay networks?

   NLPID and Frame Relay Encapsulation

Frame relay encapsulation uses Network Level Protocol Identifiers (NLPID) to identify the protocols. NLPIDs are reserved values and are administered by the International Organization for Standardization (ISO) and International Telecommunications Union (ITU) and are assigned for a variety of common Network Layer protocols, such as IP, Connectionless Network Protocol (CLNP) (ISO 8473), IPv6, and others. When an NLPID is not available, then special "escape" values can specify other forms of protocol identifiers. For example, they can specify a value using a SNAP header with an OUI and a Type field to identify the protocol. IP has an NLPID of 0xCC defined. The IP datagram includes the IP header but does not include the NLPID. The NLPID value directly follows the Control field, which is normally a 0x03. If IPv6 were being used, the NLPID would be 0x8E.

The following frame relay trace fragment is carrying an encapsulated IP datagram. It illustrates a frame relay header followed by an NLPID indicating IP. Link Access Procedure for Frame-Mode Bearer Services (LAPF) is the link access procedure for frame relay.

Frame = 2 at 0:00:37.734305   Len = 134
LAPF Information
  DLCI= 16
  Command/Response= 0 (Cmd User->Network; Rsp Network->User
  FECN= 0 (Fwd Explicit Congestion Notification is cleared)
  BECN= 0 (Bkwd Explicit Congestion Notification is cleared)
  Discard Elig.(DE)= 0 (Should not be discarded in a congested network)
  Type= 3 (Unnumbered)
  Function Modifier= UI
  Poll/Final= 0 (Unsolicited)
Multiprotocol Encapsulation over Frame Relay:
  NLPID= 0xCC (IP version 4)
Internet Protocol
      Version(MSB 4 bits): 4
      Header length(LSB 4 bits): 5 (32-bit word)
      Service type: 0x00
            000. .... = 0 - Routine
            ...0 .... = Normal delay
            .... 0... = Normal throughput
            .... .0.. = Normal reliability
      Total length: 44 (Octets)
      Fragment ID: 33289
      Flags summary: 0x40
            0... .... = Reserved
            .1.. .... = Do not fragment
            ..0. .... = Last fragment
            Fragment offset(LSB 13 bits): 0 (0x00)
      Time to live: 32 seconds/hops
      IP protocol type: TCP (0x06)
      Checksum: 0x68F0
      IP address 205.169.85.68 ->205.169.85.253
      No option
Transmission Control Protocol
      Port 2318 ---> 80 (World Wide Web HTTP)

ATM

Cell relay lies at Open Systems Interconnection (OSI) Layers 1 and 2 and uses a small, fixed-length cell of 53 bytes, or octets. Cell relay achieves the same goal as frame relay, asynchronous multiplexing, in a fundamentally different way. This is illustrated on the Cell Relay Diagram.

The cell relay element "A" (for example a router with an ATM interface), shows cells originating from a given source node and destined for multiple nodes. The information may be data, video, or voice. Each 53-byte cell contains 48 bytes of user information (payload) and a 5-byte header that indicates to which virtual circuit the cell belongs. Only data from a particular circuit can go in that cell. This is much simpler than the multiplexing required for frame relay.

The input shown coming into cell relay "B" comes from "A." "B" relays each cell, a cell at a time, to the channel assigned to the virtual circuit indicated by the header of the cell. Again, this is a very simple operation--no demultiplexing of the input is required.

Characteristics of ATM are:

Each ATM cell contains a 5-byte header and a 48-byte Information field, or payload. The ATM header contains six fields, as shown on the ATM Header Diagram.

The ATM header fields are:

   ATM Adaption Layer (AAL-5)

ATM Adaptation Layer 5 is used to interface an IP stack to an ATM network. At this layer, the entering (send side) IP packet has not yet been broken down into individual 53-byte cells. This is where the Segmentation and Reassembly (SAR) function takes place. The following ATM/SAR trace fragment illustrates IP encapsulation.

ATM/SAR:  VPI - 8
ATM/SAR:  VCI - 5
ATM/SAR:  CPCS PDU Length - 144 (Common Part Convergence Sublayer)
ATM/SAR:  AAL Type - 5
ATM/SAR:  Status - OK
ATM/SAR:  Length - 92
ATM/SAR:  LLC ENCAPSULATION	(AA AA 03)
ATM/SAR:  Routed non ISO protocol (00 00 00)
ATM/SAR:  Protocol Encapsulated: DOD IP (08 00)
IP:  Total Length = 84
IP:  Fragment ID = 40219
IP:  Flags: 0x0
IP:  			May Fragment
IP:			Last Fragment
IP:  Fragment Offset = 0 Bytes
IP:  Time to Live = 255 [Seconds/Hops]
IP:  Protocol: 0x01 ICMP

Note the SAR encapsulation using LLC, which is a standard SNAP header you saw in a previous lesson.

[ Previous Section ] [ Unit Contents ] [ Summary ]