White Paper and -Based : A Comparison of Technologies Larry Greenstein Nuera Communications VP, Technology, Forum June 1995 June 27, 1995 i
TABLE OF CONTENTS 1. PREFACE...1 2. INTRODUCTION...1 3. INTERWORKING WITH FRAME-BASED DEVICES...1 3.1 What s in a?... 1 3.2 Service... 3 3.3 FUNI -based... 3 3.4 DXI -based... 5 3.5 / Interworking... 5 3.5.1 The Interworking Function...5 3.5.2 The Service Interworking Function...6 4. CONCLUSION...8 5. REFERENCES...8 6. GLOSSARY...8 June 27, 1995 ii
1. Preface This white paper describes the basic capabilities and functional differences between frame relay,, frame relay/ interworking functions [1,2], the Forum s Data Exchange Interface [3] (DXI), and the Forum s -based -to- Interface [4] (FUNI). The DXI and FUNI are access protocols which take advantage of existing low cost frame-based user equipment. Thus, the DXI and FUNI allow the user equipment to send traffic in frames (as opposed to cells) and require another piece of equipment to perform the function of segmenting the traffic into cells. The segmenting is performed in a data service unit in the case of the DXI, and in the switch in the case of the FUNI. DXI and FUNI software can run on the same hardware that supports frame relay and X.25. On the surface, DXI and FUNI look a lot like frame relay. But when examined closely, there are many differences. Those who wish to know in depth technical details are referred to the Forum DXI and FUNI, and the Relay Forum FRF.1 UNI [5], FRF.5 / Interworking [1], and FRF.8 / Service Interworking [2] documents. 2. Introduction is growing in activity and interest at an unprecedented pace. While there are not many networks and users in place when compared to the widely available infrastructure of frame relay, most observers agree that this will change over the next five years. service is based on switching fixed length packets of data which are known as cells. Cell switching is popular for a variety of reasons, one of which is that switch architectures can be optimized to switch cells at much higher speeds than variable length packets. Another is that multiple services requiring a variety of quality of service guarantees can be provided simultaneously. user traffic must be segmented into cells, transmitted, and then reassembled back into its original form. This process is done in a standardized way and the hardware which provides this interface capability is relatively new and typically more expensive than frame relay hardware. relay service from public carriers is available worldwide. Its reliability and effectiveness have been demonstrated since the first networks were established in 1992. Estimated service revenue in 1994 was $350 million and was forecast to be over $700 million in 1995 [6]. relay evolved from X.25 packet switching and uses variable length frames to transport the user traffic across the interface. relay is popular for a variety of reasons. It is very efficient as it has less overhead and wastes less bandwidth as compared to. Also, many types of existing user equipment (e.g., routers) can be upgraded to frame relay without hardware changes. It is a relatively inexpensive way to interconnect multiple LANs when compared to leased lines, yet it provides good performance for LAN applications. And, it is less process intensive than X.25, resulting in higher network throughput with lower delay than X.25. 3. Interworking with -based Devices The market for low cost frame relay and frame-based user equipment is expected to continue to grow at a strong pace. Therefore, interworking with is an important issue. 3. 1 What s in a? DXI and FUNI allow frame-based access to an network, while frame relay allows frame-based access to a frame relay network. DXI, FUNI and frame relay have similar frame structures. As shown in Figure 1, the DXI header and FUNI header within the frame are identical to each other, but are different from the frame relay header. Note that the DXI/FUNI frame address bits fall into the same position in the header as the frame relay address (which is composed of the upper and lower DLCI). June 27, 1995 1
structure of DXI, FUNI and Flag Header SDU (user traffic) FCS Flag Header structure of DXI and FUNI Address Address RSVD CN RSVD CLP 1 0 Header structure of DLCI upper DLCI lower C/R FECN BECN DE 1 0 BECN = backward explicit congestion notification CLP = cell loss priority CN = congestion notification C/R = command / response DE = discard eligibility DLCI = data link connection identifier FCS = frame check sequence FECN = forward explicit congestion notification RSVD = reserved SDU = service data unit Figure 1 Comparison of s When the frame is segmented into cells, the DXI frame address and the FUNI frame address both map to the VPI/VCI (virtual path identifier/virtual connection identifier) using identical procedures. relay interworking functions may use these same address mapping procedures, but the frame relay/ interworking function is permitted to use other mappings as well. Flag Header SDU (user traffic) FCS Flag address bits map to VCI/VPI bits Cell Header Payload Header Payload Header Payload Figure 2 FUNI Segmented Into Cells in the Switch The CN bit performs the same function as the frame relay FECN bit. The network sets this bit during periods of network congestion, in the same direction as the traffic affected by the congestion. The frame relay BECN bit does not have a similar function in the FUNI or DXI (or in general). BECN is a notification back to a frame relay transmitter indicating that traffic it is sending has encountered congestion. BECN allows the network (as opposed to the destination user equipment) to provide congestion indications directly to the sending user equipment. FECN and CN, however, rely on the destination user equipment upper layer protocol(s) to participate in congestion management by sending an indication back to the offending user equipment within the upper layer protocol(s). As June 27, 1995 2
interface speed increases, the effectiveness of FECN and CN decreases due to the round trip delay involved in notifying the user of the congestion. The CLP bit performs the same function as the frame relay DE bit. CLP/DE = 1 indicates a cell/frame which is more likely to be discarded in the event a discard is necessary due to congestion. The frame relay C/R bit is passed transparently between frame relay users. The DXI/FUNI does not have a bit in the header which corresponds to the frame relay C/R bit. 3. 2 Service relay provides a user with multiple independent data links to one or more destinations. Traffic on these data links is statistically multiplexed to provide efficient use of access lines and network resources. Since the multiplexing is at the link layer, end-to-end delay is minimized. relay networks transfer the user traffic within the frame without regard to its contents, thereby providing service which is effectively as transparent as a leased line. relay service is commonly available at fractional T1/E1 and full T1/E1 rates. Some vendors offer it at rates up to T3 (45 Mbps). Relay UNI s s Figure 3 Service 3. 3 FUNI -based There are differing views of interworking. One way to interwork is to add software to user equipment which contain HDLC (high level data link control) frame-based protocol interfaces, thus providing a new protocol known as FUNI. The FUNI specification was approved by the Forum in 1995 and implementations may become available in the fourth quarter of 1995. The FUNI requires software in the user equipment and a complementary frame-based interface and FUNI software in the switch to which the user equipment connects. Within the switch interface, the frames are segmented into cells and sent into the network. Cells coming from the network are reassembled into frames and sent to the user. Thus, the cost of the segmentation and reassembly hardware is moved from the user equipment to the switch. There are two key functional differences between FUNI and DXI. One difference is that FUNI provides improved efficiency of access line bandwidth when compared to the cell based access of DXI. This is because when the frame size increases and overhead stays constant, efficiency increases. Cell based access efficiency stays relatively constant with large payloads and can be extremely inefficient when payloads get very small (i.e., less than 48 bytes). Another difference is that FUNI supports fractional T1/E1 rates and DXI does not. Additional important differences are discussed in the following section. June 27, 1995 3
Customer Premises s Figure 4 -based UNI (FUNI) Cells FUNI Segmentaion and Reassembly The FUNI is not intended to provide interoperability between users and frame relay users. Other than having a frame structure similar to frame relay and the ability to operate on the same type of hardware as frame relay, the FUNI has little else in common with frame relay. One cannot simply connect frame relay user equipment to an network s FUNI and expect it to function. The FUNI consists of more than just a frame-based interface for transporting user traffic. It includes SVC signaling, a simple network management protocol (SNMP) and management information base (MIB), and optional support of operations, administration, and management (OAM) cells/frames. The FUNI MIB is a subset of the DXI MIB. The above capabilities are important as they are required for the user equipment to obtain cell-based services. However, not all services are available over the FUNI. The FUNI mandates the support of AAL5 (in the switch), while AAL3/4 is optional. Services requiring the use of other adaptation layers (AALs) are not supported over the FUNI (e.g., circuit emulation) and support of some quality of service classes (e.g., Available Bit Rate) is not possible. DXI FUNI s CSU Cells UNI Cells Figure 5 FUNI Interoperability When a FUNI user wishes to establish a switched virtual circuit (SVC) to a destination, it does not matter if the destination is another FUNI, a DXI, or an user-to-network interface (UNI) [7]. To establish an SVC, it uses the same signaling procedures as the UNI. And when the FUNI user sends traffic to the network, it does not matter if the traffic terminates at another FUNI or at an UNI. All of these service aspects are transparent. Equally transparent are the procedures for layer 3 protocol encapsulation over. Routers which support multiple protocols over follow specific procedures defined in RFC-1483 [8] and RFC-1577 [9] by the Internet Engineering Task Force (IETF). Since the FUNI is an protocol, the multiprotocol encapsulation procedures used at the UNI (and DXI) are used at the FUNI, therefore no new interoperability issues are introduced. June 27, 1995 4
3. 4 DXI -based Another way of implementing a function similar to the FUNI is to provide the segmentation and reassembly function in an external piece of equipment and place it at the customer premises. In the case of the DXI, this external piece of equipment is integrated with a Channel Service Unit (CSU). Additionally, the user equipment must be configured with the DXI software and an HDLC interface. Customer Premises s DXI CSU Cells Segmentaion and Reassembly Figure 6 Data Exchange Interface (DXI) Other key differences between the DXI and FUNI are: The DXI supports full T1/E1 access rates, but not fractional T1/E1 rates. Cells traverse the user-to-network access line and therefore bandwidth utilization is less efficient than the FUNI. The DXI also has a defined SNMP management protocol and MIB. 3. 5 / Interworking Beyond providing a means for frame-based user equipment to access networks at the user-to-network interface, an important consideration is how to interwork frame relay networks with networks, and thereby interwork the network users. This leads to two frame relay/ interworking scenarios; Interworking and Service Interworking. These two interworking functions provide a means by which the two technologies can interoperate. Simply stated, Interworking provides a transport between two frame relay devices (or entities). Service Interworking enables an user to transparently interwork with a frame relay user, and neither one knows that the far end uses a different technology. These topics are covered in depth in the implementation agreements FRF.5 and FRF.8 published by the Relay Forum. These implementation agreements define the frame relay/ network and service interworking procedures jointly agreed upon by the Forum and the Forum. These implementation agreements currently support only PVC interworking. SVC support is for further study. 3. 5. 1 The Interworking Function The Interworking function facilitates the transparent transport of frame relay user traffic and frame relay PVC signaling (sometimes called LMI protocol) traffic over. This is sometimes referred to as tunneling. This means that multiprotocol encapsulation (and other higher layer procedures) are transported transparently as they would over leased lines. An important application for this interworking function (IWF) is connecting two frame relay networks over an backbone network. June 27, 1995 5
IWF IWF Relay NNI Relay NNI NNI = network-to-network interface IWF = interworking function Figure 7 Example of / Interworking As shown in the figure above, the network is used in place of a transmission facility (leased line) to connect the two frame relay networks. The IWF can be external to the networks as shown, but is more likely to be integrated into the network switch or frame relay switch. Each frame relay PVC can be carried over an PVC, or all of the frame relay PVCs can be multiplexed onto a single PVC. This method of connecting frame relay networks may provide economic savings when compared to leased lines. This is especially true when the frame relay NNI is operating at a low percentage utilization. Interworking also includes a scenario in which an host computer emulates frame relay in the service specific convergence sublayer. For more details, refer to the Interworking Implementation Agreement FRF.5 [1]. 3. 5. 2 The Service Interworking Function The Service IWF does not transport traffic transparently. It functions more like a protocol converter in that it facilitates communication between dissimilar equipment. Relay UNI SERVICE SERVICE IWF IWF FUNI UNI DXI Figure 8 Example of / Service Interworking June 27, 1995 6
As shown in the figure above, a frame relay user sends traffic on a PVC through the frame relay network to the Service IWF which then maps it to an PVC. The frame relay PVC address-to- PVC address mapping and other options are configured by the network management system associated with the IWF. Again, the Service IWF can be external to the networks as shown, but is more likely to be integrated into the network switch or frame relay switch. Note that in the case of Service Interworking, there is always one PVC per frame relay PVC. Flag Header RFC-1490 Header SDU FCS Flag DLCI upper C/R 0 DLCI lower FECN BECN DE 1 Mapping / Conversion SERVICE IWF IWF GFC VPI VPI VCI Cell VCI VCI PT HEC RFC-1483 Header Cell Payload (first segment of SDU) CLP GFC = generic flow control VPI = virtual path identifier VCI = virtual connection identifier PT = payload type CLP = cell loss priority HEC = header error checksum CLP = cell loss priority Figure 9 Service IWF Header Function Mapping relay PVC status signaling is converted to OAM cells. Likewise, OAM cells are converted to frame relay status signaling. Therefore, if a failure occurs in one network, the user of the other network will be notified. Other indications such as congestion indication and discard eligible/cell loss priority are also mapped between networks per PVC. The Service IWF maps the frame relay DLCI to the VPI/VCI, the FECN bit maps to the PT field in which congestion indication is encoded, and the DE bit maps to the CLP bit. The frame relay multiprotocol encapsulation procedures (RFC-1490 [10] ) are not identical to the multiprotocol encapsulation procedures (RFC-1483 [8] and RFC-1577 [9] ). When providing frame relay/ Service Interworking for multiprotocol routers, it is necessary for the IWF to convert the multiprotocol protocol data unit headers from frame relay to and vice versa. This header processing can be turned on or off per PVC as some applications do not require it. June 27, 1995 7
4. Conclusion Applications of frame relay and technologies overlap. Making a choice between the technologies must be driven by business considerations. This includes consideration of: availability of equipment and service from multiple suppliers, cost of network and user equipment, existing installed base of user and network equipment, recurring cost of service, cost of managing the network (including complexity and required manpower), efficiency of bandwidth utilization, service classes provided by the network, performance (interface speed, delay, throughput), interoperability between vendors. The above considerations are key elements to the selection of network technology. An informed business decision can be made when the above considerations are properly weighed and evaluated. relay and each have fundamentally unique characteristics. One cannot provide all the features of the other. Therefore, the use of both technologies will continue to grow to keep pace with the applications for which they are best suited. 5. References [1] / PVC Interworking Implementation Agreement (FRF.5), Forum, December 20, 1994 [2] / PVC Service Interworking Implementation Agreement (FRF.8), Forum, April, 1995 [3] Data Exchange Interface Specification Version 1.0, Forum, August 4, 1993 [4] -based -to- Interface Specification Version 1.0, Forum, 1995 [5] -to- Interface Implementation Agreement (FRF.1), Forum, 1992 [6] Vertical Systems Group, May 1995 [7] -to- Interface Specification Version 3.1, Forum, 1994 [8] Multiprotocol Encapsulation over AAL 5 (RFC-1483), IETF, July, 1993 [9] Classical IP and ARP over, (RFC-1577), IETF January, 1994 [10] Multiprotocol Interconnect over, (RFC-1490), IETF July, 1993 6. Glossary AAL = adaptation layer AAL3/4 = adaptation layer optimized for connectionless service over AAL5 = adaptation layer optimized for connection oriented service over ABR = Available Bit Rate = asynchronous transfer mode BECN = backward explicit congestion notification CLP = cell loss priority CN = congestion notification C/R = command / response CSU = channel service unit June 27, 1995 8
DE = discard eligibility DLCI = data link connection identifier DSU = data service unit DXI = data exchange interface FCS = frame check sequence FECN = forward explicit congestion notification FUNI = frame-based user-to-network interface GFC = generic flow control HDLC = high level data link control (a frame-based protocol) HEC = header error checksum IETF = Internet engineering task force IWF = interworking function LAN = local area network LMI = local management interface Mbps = million bits per second MIB = management information base NNI = network-to-network interface OAM = operations, administration, and management PT = payload type PVC = permanent virtual connection QOS = quality of service RFC = request for comment (a document issued by IETF) RSVD = reserved SDU = service data unit SNMP = simple network management protocol SVC = switched virtual circuit TCP/IP = telecommunications protocol/internet protocol UNI = user-to-network interface VCI = virtual connection identifier VPI = virtual path identifier X.25 = a packet switching protocol End of Document June 27, 1995 9