Frame Relay PVC Status Signaling

Figure 7-22 illustrates the basic concept of Frame Relay status signaling for a CPE device connected to a Frame Relay switch on the edge of an FR network.

Status signaling allows the end user as well as the network to detect failures between the end points of PVCs. Generally, each physical access line connecting an end user to the serving Frame Relay switch carries multiple DLCIs. The FR standards define a status sig-naling protocol running on a particular DLCI (e.g., zero) that reports on the status for all

Figure 7-21. Structure of Frame Relay User-to-Network Interface (UNI) standards

DLCIs carried by the physical FR UNI access line. The periodic exchange of status signal-ing messages also acts as a heartbeat and fault-detection mechanism for the physical access line connecting the user to the network. The status message also contains a field indicating that the network has provisioned a new PVC.

Originally, a groupof vendors defined a local management interface (LMI) standard for Frame Relay. The LMI with extensions defined a protocol to provide a keep-alive sig-nal between the FR CPE and the FR network access port. Also, the LMI simplified initial Frame Relay configuration by providing automatic notification of changes in PVC con-nectivity, as well as notification of the provisioning of new PVCs. Over time, incompati-ble standards arose between the LMI, ITU-T, and ANSI standards. For example, the LMI extension uses DLCI 1023 for status reporting, while T1.617 and ITU-T Q.933 Annex A employ DLC I 0, as shown in Figure 7-22. Fortunately, the ITU-T Q.933 Annex A standard is now closely aligned with ANSI T1.617, and the original proprietary LMI specification is falling out of use. Because of basic differences between the various local management interface standards, CPE and networks can automatically detect the status signaling pro-tocol employed by the end user and react appropriately. This removes one configurable item, and thus reduces the complexity of turning up a Frame Relay PVC for service.

ITU-T Recommendation Q.933 Annex A and ANSI Standard T1.617 Annexes B and D define the modern Frame Relay status signaling message formats and procedures covered in this chapter. ANSI Standard T1.617 Annex B defines additional status signaling proce-dures for interfaces carrying both PVCs and SVCs. These specifications define three main

Figure 7-22. Context for Frame Relay status signaling

areas of PVC management: PVC status signaling, DLCI verification, and the physical inter-face keep-alive heartbeat.

The PVC status signaling procedures utilize two messages: STATUS ENQUIRY and STATUS. Figure 7-23 shows the Q.933 STATUS ENQUIRY signaling message format and content. The message contains a signaling header common to all signaling messages, con-sisting of a protocol discriminator field, a call reference field, and the message type field (i.e., a string of bits indicating STATUS ENQUIRY, in this case). The report type informa-tion element indicates a choice of one of the following three opinforma-tions: a full status (FS) report on every provisioned PVC, link integrity verification only, or asynchronous reporting on sets of PVCs whose status has changed.

Figure 7-24 shows the format and content of a Frame Relay STATUS message from Q.933 Annex A. The STATUS message has the same format as the STATUS ENQUIRY message with the addition of one or more optional PVC status information elements. Of course, the value of the message type indicates that this is a STATUS message in response to a STATUS ENQUIRY. One or more optional PVC status information elements contain the DLCI of the connection that the status applies to, as defined by two bits: new and active. The new bit is set to 1 for a new PVC; otherwise, it is set to 0. The active bit indicates whether the PVC is opera-tional (1) or not (0). The primary benefits of PVC status signaling derive largely from these two simple bits of information, as expanded on in the example in the next section.

T1.617 Annex D differs slightly from the Q.933 Annex A formats, as it adds a one-octet locking shift to the codeset 5 information element after the common signaling header, to indicate that the link integrity verification and PVC status information elements are for national use (e.g., the United States for ANSI). Status messages contain a link integrity verification field useful for checking continuity as well as acknowledging and detecting lost signaling messages, using the send and receive sequence numbers in a manner analo-gous to the sliding window protocol of X.25.

The maximum number of usable DLCIs on a physical interface is limited by the maxi-mum frame size defined for that interface. This occurs because the maximaxi-mum frame size

154

Figure 7-23. Q.933 Annex A STATUS ENQUIRY signaling message content

dictates how many PVC status information elements fit within a frame used to signal the Full Status (FS) message, and thus limits the maximum number of DLCIs on that inter-face. With enhancements to the PVC management procedures in FRF.1.2, this limitation, inherited from Q.933 Annex A, is removed. When the number of PVCs exceeds the num-ber supported with the maximum frame size, these procedures add a status continued re-port type to the Rere-port type Information element carried in the STATUS message in order to segment the full status message. Upon receiving a STATUS message indicating a “full status continued” type, the user device responds by sending another STATUS ENQUIRY message containing a “full status continued” type; this repeats until all status informa-tion is received, as indicated by the final STATUS message not indicating a status contin-ued report type.

FRF.1.2 also enhances the LMI information included in the Full Status message to also report the link layer core parameters and the Priority and Service class parameters to the network or user. This will indicate the maximum frame size, the committed information rate, the committed burst size, the excess burst size, the transfer priority, and the service classes. In Q.933, the Full Status message is limited to reporting the status of the PVC, available or not. The reporting of availability is also enhanced in FRF.1.2 so that any change in the link layer core parameters or Service class parameters will initiate a STATUS message. Recognizing the fact that an NNI will likely need to support more DLCIs than a UNI, the Frame Relay Forum adopted an event-driven procedure docu-mented in the FRF 2.2 implementation agreement. This procedure uses asynchronous status reporting to communicate only changed PVC status along with periodic updates for unchanged PVCs. This procedure overcomes the limit imposed by full status report-ing on the maximum number of PVCs supported by an interface.