| Most modern Wide Area Network (WAN) protocols including TCP/IP, X.25, and Frame Relay are based on packet-switching technologies. In contrast, normal telephone service is based on a circuit-switching technology, in which a dedicated line is allocated for transmission between two parties. Circuit switching is ideal when data must be transmitted quickly and must arrive in the same order in which it's sent. This is the case with most real-time data, such as live audio and video. Packet switching is more efficient and robust for data that can withstand some delays in transmission, such as email messages and Web pages. Each packet is transmitted individually and can even follow different routes to its destination. Once all the packets forming a message arrive at the destination, they are recompiled into the original message. 23.1.1 Frame Relay Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI seven-layer model. Frame Relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well. Frame Relay is an example of a packet-switched technology. Packet-switched networks enable end stations to dynamically share the network medium and the available bandwidth. Two techniques are used in packet-switching technology: -
Variable-length packets -
Statistical multiplexing Variable-length packets are used for more efficient and flexible data transfers. These packets are switched between the various segments in the network until the destination is reached. Statistical multiplexing techniques control network access in a packet-switched network. The advantage of this technique is that it accommodates more flexibility and more efficient use of bandwidth. Most of today's popular LANs, such as Ethernet and Token Ring, are packet-switched networks. Frame Relay is often described as a streamlined version of X.25, offering fewer of the robust capabilities, such as windowing and retransmission of last data that are offered in X.25. This is because Frame Relay typically operates over WAN facilities that offer more reliable connection services and a higher degree of reliability than the facilities available during the late 1970s and early 1980s that served as the common platforms for X.25 WANs. Frame Relay is strictly a Layer 2 protocol suite, whereas X.25 provides services at Layer 3 (the network layer) as well. This enables Frame Relay to offer higher performance and greater transmission efficiency than X.25, and makes Frame Relay suitable for current WAN applications, such as LAN interconnection. Devices attached to a Frame Relay WAN fall into two general categories: -
Data terminal equipment (DTE) DTEs generally are considered to be terminating equipment for a specific network and typically are located on the premises of a customer. In fact, they may be owned by the customer. Examples of DTE devices are terminals, personal computers, routers, and bridges. -
Data circuit-terminating equipment (DCE) DCEs are carrier-owned inter-networking devices. The purpose of DCE equipment is to provide clocking and switching services in a network, which are the devices that actually transmit data through the WAN. In most cases, these are packet switches. One of the most commonly used physical layer interface specifications is the recommended standard (RS)-232 specification. The link layer component defines the protocol that establishes the connection between the DTE device, such as a router, and the DCE device, such as a switch. Frame Relay provides connection-oriented data link layer communication. This means that a defined communication exists between each pair of devices and that these connections are associated with a connection identifier. This service is implemented by using a Frame Relay virtual circuit , which is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN). Virtual circuits provide a bidirectional communication path from one DTE device to another and are uniquely identified by a data-link connection identifier (DLCI). A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network. This capability often can reduce the equipment and network complexity required to connect multiple DTE devices. A virtual circuit can pass through any number of intermediate DCE devices (switches) located within the Frame Relay PSN. Frame Relay virtual circuits fall into two categories: Switched virtual circuits (SVCs) are temporary connections used in situations requiring only sporadic data transfer between DTE devices across the Frame Relay network. A communication session across an SVC consists of the following four operational states: -
Call setup : The virtual circuit between two Frame Relay DTE devices is established. -
Data transfer : Data is transmitted between the DTE devices over the virtual circuit. -
Idle : The connection between DTE devices is still active, but no data is transferred. If an SVC remains in an idle state for a defined period of time, the call can be terminated . -
Call termination : The virtual circuit between DTE devices is terminated. After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged. It is expected that SVCs will be established, maintained , and terminated using the same signaling protocols used in ISDN. Few manufacturers of Frame Relay DCE equipment support switched virtual circuit connections. Therefore, their actual deployment is minimal in today's Frame Relay networks. Previously not widely supported by Frame Relay equipment, SVCs are now the norm. Companies have found that SVCs save money in the end because the circuit is not open all the time. Permanent virtual circuits (PVCs) are permanently established connections that are used for frequent and consistent data transfers between DTE devices across the Frame Relay network. Communication across PVCs does not require the call setup and termination states that are used with SVCs. PVCs always operate in one of two operational states: -
Data transfer : Data is transmitted between the DTE devices over the virtual circuit. -
Idle : The connection between DTE devices is active, but no data is transferred. Unlike SVCs, PVCs will not be terminated under any circumstances when in an idle state. DTE devices can begin transferring data whenever they are ready because the circuit is permanently established (Figure 23-1). Figure 23-1. Frame Relay. 
Up to 976 DLCI (Permanent Virtual Circuits) per port provide the ability to establish a large number of user sessions. The frame size can be tuned up to 4096 bytes, enabling efficient data transfer. Support of IP access over Frame Relay (RFC 1490) enables IP applications to run over frame relay networks. For each DLCI, the Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS) Traffic Management parameters can be configured, allowing tuning for optimum throughput. Frame Relay provides no explicit flow control per DLCI, but instead very simple congestion notification mechanisms, namely FECN and/or BECN (Forward and/or Backward Explicit Congestion Notification). Integration with HP-UX utilities such as SAM ensures easy installation and configuration. Monitoring and statistics are provided to help tuning and troubleshooting. Frame Relay allows communications between an HP 9000 system and other equipment (HP or non-HP) over Frame Relay (WAN) networks, using the TCP/IP services. The MTU size is configurable within the range 260 to 4000 bytes. HP-UX J3529A Frame Relay software runs on HP 9000 server systems and workstations (EISA or PCI bus) running HP-UX 11i, as seen in Table 23-1. Table 23-1. HP Frame Relay Supported Adapters | Adapter | Ports | Bus Type | RS -232 | V.35/V.36 | X.21 | RS -449 | RS -530 | | J2792A | 1 | HP-PB | 64 Kbps | 64 Kbps | 256Kbps | 256Kbps | N/A | | J2794A | 1 | EISA | 64 Kbps | 64 Kbps | N/A | 1.5 Mbps | N/A | | J2185A | 2 | EISA | 64 Kbps | N/A | 256Kbps | N/A | N/A | | J3525A | 2 | PCI | 64 Kbps | 64 Kbps | 2 Mbps | 2 Mbps | 2 Mbps | | J3526A | 4 | PCI | 64 Kbps | 64 Kbps | 2 Mbps | 2 Mbps | 2 Mbps |
23.1.2 Asynchronous Transfer Mode (ATM) Asynchronous Transfer Mode is a network technology based on transferring data in cells or packets of a fixed size. The cell used with ATM is relatively small compared to units used with older technologies. The small, constant cell size allows ATM equipment to transmit video, audio, and computer data over the same network, and assures that no single type of data hogs the line. ATM creates a fixed channel , or route, between two points whenever data transfer begins. This differs from TCP/IP, in which messages are divided into packets and each packet can take a different route from source to destination. This difference makes it easier to track and bill data usage across an ATM network, but it makes it less adaptable to sudden surges in network traffic. When purchasing ATM service, you generally have a choice of four types of service: -
Constant Bit Rate ( CBR ) specifies a fixed bit rate so that data is sent in a steady stream. This is analogous to a leased line . -
Variable Bit Rate ( VBR ) provides a specified throughput capacity, but data is not sent evenly. This is a popular choice for voice and videoconferencing data. -
Available Bit Rate ( ABR ) provides a guaranteed minimum capacity, but allows data to be bursted at higher capacities when the network is free. -
Unspecified Bit Rate ( UBR ) does not guarantee any throughput levels. This is used for applications, such as file transfer, that can tolerate delays. An ATM cell is the smallest item an ATM network ever deals with. ATM cells may then pass into Multiplexed channels in a trunk (or backplane). TDM (Time Division Multiplexing) has been used in the past, but ATM recognizes that traffic is usually bursty in each of the multiplexed channels and so does not time slice. Instead, it adds a header to each cell in order and takes them on a first-come, first-serve basis. Bandwidth is allocated only to channels that have data to transmit, therefore, sharing the full bandwidth among the remainder. ATM is useful to implement where the traffic is packet orientated and so will often be used not only by packet-switch manufacturers but also in intelligent ( multi-function ) hubs as well. ATM is also the technology that B-ISDN is based on and will be used to provide many WAN services. ATM at OSI Layer 2, like Frame Relay, uses 5 bytes (octets) for the header; add 48 bytes (384 bits) of payload data and you have a cell size of 53 bytes. ATM also has an upper level 2 layer known as the AAL (ATM Adaptation layer). It is used to determine the type of data, Constant or Variable length and Connectionless or Connection oriented. At present, there are five different classes. Because this is a cell-switching technology, it also uses Virtual Connections , which are either Permanent (PVC) or Switched (SVC). A virtual path identifier (VPI) and virtual channel identifier (VCI) in the header identifies each cell. -
Permanent Virtual Connections (PVC) : A PVC is a connection set up by some external mechanism, typically network management, in which a set of switches between an ATM source and destination ATM system are programmed with the appropriate VPI/VCI values. As is discussed later, ATM signaling can facilitate the setup of PVCs, but by definition PVCs always require some manual configuration. As such, their use can often be cumbersome. -
Switched Virtual Connections (SVC) : An SVC is a connection that is set up automatically through a signaling protocol. SVCs do not require the manual interaction needed to set up PVCs and, as such, are likely to be much more widely used. All higher layer protocols operating over ATM primarily use SVCs. Like Frame Relay, there are two different cell structures depending on whether it is a User Network Interface (UNI) cell or a Network Node Interface (NNI) cell. Both have a 5-byte (octet) header; the difference is what's in these 5 bytes. A UNI connects ATM end systems ( hosts , router, and so on) to an ATM switch, while an NNI is a physical or logical link across which two ATM switches communicate. The physical layer of ATM is divided into two sublayers . The TC or TCS (Transmission Convergence Sublayer) sits on top of the PMD (Physical Medium Dependant sublayer). TCS looks after cell delineation (how to identify the start and end of each cell) and cell rate decoupling (inserting empty cells during idle periods). Many of the TC standards also define some form of enveloping a number of cells so that it can check overall clocks and errors, and so on. At present, there are four main groups defined in the TCS: -
SONET/SDH (normally at 155Mbits/sec) : SONET (Synchronous Optical NETwork) is now an ANSI standard defining interface standards at the physical layer of the OSI seven-layer model. SDH (Synchronous Data Hierarchy) is a North American equivalent of SONET. -
PDH (Plesiochronous Digital Hierarchy) : The standard that controls the variance a data stream can take from its nominal speed. For a DS1/T1 link, this equates to 100 bits per second either side of 2Mbps. See http://www.dis.port.ac.uk/~earlyg/dins/l11/Lec11_98.html for a good talk on PDH. -
Cell based (same coding as Fibre Channel): -
A replacement for FDDI : This is the same coding and fibre, although obviously the FDDI card will still have to be replaced for an ATM card, and the actual physical connectors are different (FDDI uses a MIC, while ATM normally uses SC connectors in this situation). PMD looks after the physical medium, line coding, and bit timing. The ATM Forum (http://www.atmforum.com) has tried to use existing standards wherever possible. There are numerous physical layer connections available for ATM, although HP-UX currently supports only a few. If you browse to http://www.atmforum.com/standards/approved.html and click "Physical Layer." you will find all of the possibilities currently defined. HP's current offering include the solutions listed in Table 23-2. Table 23-2. HP ATM Solutions | Adapter | Link Speed | Cable | | A5483A | 622Mbps | Multi-mode Fibre with SC connectors | | A5513A | 155 Mbps | Multi-mode Fibre with SC connectors | | A5515A | 155 Mbps | UTP Cat5 | | J2469A | 155 Mbps | Multi-mode Fibre with SC connectors Single-mode Fibre with SC connectors UTP Cat5 | | J2499A | 155Mbps | Multi-mode Fibre with SC connectors UTP Cat5 | | J3575A | 622Mbps | Multi-mode Fibre with SC connectors |
Where ATM fits into the OSI seven-layer model is a bit of a controversy. Most people would agree that it fits snuggly into Layer 2, but some would argue that it is quite happy as a Layer 3 product as well. This is true because the addressing scheme used by ATM exhibits all the characteristics of a Layer 3 protocol, including a hierarchical addressing scheme and a complex routing protocol. This leads to issues surrounding support of IP over ATM. If ATM has a complex routing protocol, how does IP interact with it? This is resolved by ATMARP software running on nodes that resolves ATM 40-bit hardware addresses to IP addresses. RFC 1577 covers the support of IP over ATM. Each interface card supports one Classical IP (CIP) address and up to 32 Emulate LAN (ELAN) interfaces configured as LAN Emulation Clients (LEC), each with a different subnet address. Nodes connected via an ATM switch that have LAN interfaces configured on the same subnet will form a Logical IP Subnet (LIS) with one node acting as the ATMARP Server, resolving ATM addresses to IP addresses, and the other acting as ATMARP Clients. ATMARP replaces the functionality of the ARP protocol. To communicate with other IP devices, the LIS will have to communicate via an ATM/IP edge device that can interface between an ATM network and a traditional Ethernet/Token Ring network. Figure 23-2. ATM with CIP and ELAN interfaces. 
23.1.2.1 SERIAL LINK SPEEDS ATM has many physical interfaces that it can utilize. The buzzwords in the industry are sometimes misleading, misunderstood, or used just to baffle us with science. In the end, they are a measure of the investment made by telecom companies in the quality of the infrastructure they support. We pay for available capacity. Most of the solutions these days utilize fibre optic cabling. Big numbers are used to try to impress us. As mentioned previously, only certain interface cards are supported by HP-UX. These equate to certain physical interface standards at Layer 2 of the OSI seven-layer model. While there are only a couple of interface standards supported for native ATM interfaces, these transmission speeds are not the only speeds available. It is not uncommon to have site-to-site ATM communications utilizing a "big fat pipe" with multiple edge devices giving access to existing 10/100/1000-BaseT networks. Ultimately, we need to consider what our overall solution is trying to accomplish. For example, if we are simply providing login capabilities for users in one site to another, we might not need as much bandwidth as if we are replicating data from one high performance disk array to another. Bandwidth is a fundamental part of a solution. If we know how much data we are likely to shift from site to site, we can start to focus on a particular solution. Table 23-3 shows links speed commonly used for serial communications. Table 23-3. Serial Link Speeds | Service (US) | Link Speed | Service (Europe) | Link Speed | | DS1/T1 | 1.544 Mb/second | E1 | 2.048 Mb/second | | DS3/T3 | 54 Mb/second | E3 | 34 Mb/second | | OC-3c | 155 Mb/second | STM-1 | 155 Mb/second | | OC-12c | 622 Mb/second | STM-4 | 622 Mb/second | | OC-48c | 2.5 Gb/second | STM-16 | 2.5 Gb/second | | OC-192c | 10 Gb/second | STM-64 | 10 Gb/second |
These names are derived from international standards such as the Synchronous Data Hierarchy (SDH), which has a North American equivalent known as SONET (Synchronous Optical NETwork: now an ANSI standard defining interface standards at the physical layer of the OSI seven-layer model). It is for historical (or is it hysterical?) reasons that the standards are different on either side of the Atlantic. Let's look at an example of where we need to backup 6TB of data overnight. Which solution would we go for? First, the answer is not entirely clear from a pure bandwidth measurement. We would need to establish the sustainable data rate that excludes any network headers, and so on, that will decrease the amount of pure data being transmitted over the link. Talk to your telecom supplier about this. Putting that aside, we need to transform our 6TB in 24 hours into a bandwidth figure we see above. It's a case of understanding the math in the end: | OC-12c/STM-4 | = | 622 Mb/second | | | = | 77.75 MB/second | | | = | 279,900 MB/ hour (  273 GB/hour) | | | | 6.4 TB/day | | *OC = Optical Carrier *STM = Synchronous Transport Mode |
If this is the requirement, then we need to consider how we are going to achieve this. With a current native ATM solution for HP-UX, we can sustain 622 Mb/second. This solution is within our grasp (just). One of the questions we need to ask ourselves is this: Can our servers sustain 622 Mb/second for the length of an entire backup? For a backup solution, it is not uncommon to have our disk arrays ( assuming that it is a disk array holding our data) communicating with the other device (another disk array possibly) on a remote site to perform our offsite backups . Such a solution would require intelligent disk arrays able to perform server-less backups . This solution is within the grasp of products such as DataProtector. This is where a program module is loaded on the disk array to communicate (usually over Fibre Channel) to another disk array without sending data via the server that initiated the backup. In this solution, we are using ATM, not as an IP-driven network but purely as an ATM backbone able to deliver packets of data, quickly and reliably. The edge device in this situation is not interfacing with an Ethernet/Token Ring network but with an ATM/Fibre channel bridge, converting FC frames to ATM frames and transmitting them on the ATM network. While some administrators would venture that this is not technically a network solution, I think we can now say that it is most definitely a network solution. ATM is more than capable at networking. The fact that it has been made to support IP is more through necessity than design. Currently, I would venture to say that ATM is used more in support of a Fibre Channel SAN than an IP network. I may be wrong, but in my experience that is where the investment is being made in ATM: long-haul, high bandwidth data replication. The cost of such a solution will depend on the telecom supplier you choose. When we think about it, the cost of lost data does not bear thinking about. I was privy to a solution in the UK where a financial institution was looking at laying 40 miles of fibre optic cable to support an ATM backbone. The cost? On average, the cost would have been 4 million to lay the cable alone. This sounds like lots of money, but in the total cost of the solution, 4M is not really that much. Think of the cost of losing IT functionality in a financial organization it doesn't bear contemplating. & pound ;4M would be recouped in a matter of months, if not weeks. ATM is commonly used in a SAN environment to support SAN solutions over long distances. We take our discussions on other network technologies on to a discussion of basic SAN functionality and the role of WAN solutions in the context of long-haul data replication. This discussion also follows the train of thought regarding available bandwidth of a given ATM solution. While bandwidth is an important part of a solution, we must always consider propagation delays; how long does it take for a light signal to travel form London to New York? If you don't consider these types of questions, your overall solution may suffer. |
