Cisco devices support a large number of WAN and dialup technologies. We cover the most popular of these technologies in this chapter:
Like the LAN protocols we have considered in this chapter, these WAN protocols operate at the data link layer of the OSI reference model. The WAN protocols transfer data across an asynchronous or synchronous serial interface from one location to another.
Synchronous serial transmissions are digital signals that are transmitted with precise clocking from one device to another. In contrast, asynchronous transmission is not done with precise clocking and relies on control information (called start and stop bits) that signifies the beginning and the end of data.
The first of the synchronous protocols we consider, HDLC, works only in a point-to-point manner, connecting one device to another with minimal encapsulation and addressing. PPP, originally designed for point-to-point serial links, has evolved into working in both synchronous and asynchronous environments. The protocols X.25, Frame Relay, and ATM do not work in a strict point-to-point serial link environment, but instead use virtual circuits to pass data. DSL is a technology that provides encoding for high-speed serial connections over conventional copper wiring for limited distances. ISDN is a WAN technology that uses the telephone network to digitize data. It can operate in a point-to-point or multipoint (one-to-many) environment.
A virtual circuit (VC) is a communication mechanism in which the path for the transfer of information is established before the data is sent, a process known as placing a call. All data packets related to the call follow the same route through the network, ensuring that the data arrives at the destination in the same order in which it was sent. At the end of the data transfer, the call is closed. Switched virtual circuits (SVCs) are those that can be established and removed as required by the network. Permanent virtual circuits (PVCs) are permanently established by the network and are never removed.
As we will see, multiple virtual circuits (SVCs or PVCs) can reside on a single serial interface of a Cisco router. In this case, each virtual circuit can be treated as a separate interface, called a subinterface . Subinterfaces can be implemented for any WAN protocol that uses virtual circuits. We examine the advantages and details of subinterfaces in the configuration examples for Frame Relay later in this chapter.
A familiar system that is analogous to a VC is the phone system. Each phone call we make can be thought of as a virtual circuit. Nearly all phone calls we make are analogous to SVCs. But if we placed a call once and left the call active forever, it would be a PVC.
Cisco WAN protocols that use virtual circuits pass data in two different forms, packet switching and cell relay. Packet switching is a data transmission method that sends data in variable-length units, or packets. Packet switching on the data link layer takes packets from the network layer and encapsulates them with specific data link layer addressing. As the data-link packets traverse the network, each intermediate packet-switching node between the source and the destination reads the data-link address in the packet and forwards the packet. The packet travels the path of the previously established virtual circuit until the destination data-link address is reached. Frame Relay and X.25 use packet switching.
ATM and Switched Multimegabit Data Service (SMDS-not covered in this book) convert packet data into fixed-length cells and perform cell relay. Cell relay is a data transmission method that sends data in small, fixed- size units, or cells, that can be processed by hardware in a fast and efficient manner. The operation of cell relay is similar to packet switching except that the data from the source system is first converted into fixed-length cells rather than packets. Table 3-1 summarizes and compares the transmission methods of the WAN protocols covered in this chapter.
Table 3-1. WAN Protocol Transmission Characteristics
It's important to keep in mind the two layers of addressing that are at issue when packet switching or cell relay is transferring network-level data across the network. Packet switching and cell switching addresses are found on the data link layer of the OSI reference model. They should not be confused with network layer addresses, such as those found in IP, IPX, and AppleTalk, which are found on the network layer of the OSI reference model. It is common for Cisco routers to route network layer packets, such as IP packets, over a packet-switching network such as Frame Relay.
In routing these network packets over a packet-switching network, the router uses the IP addresses in the network layer to determine how to route the packet to the next router on the path to the final destination.
The router then encapsulates the entire IP packet in Frame Relay, adding Frame Relay addressing. The packet gets switched across switches in the Frame Relay network as it travels down a single virtual circuit. Each Frame Relay switch uses the packet's Frame Relay addressing to transfer the packet further along the circuit from source to destination router. The routers see themselves directly attached over the Frame Relay network; they do not see the Frame Relay switches as intermediary nodes for network layer traffic.
This same analogy can be used for LAN protocols. Replace the Frame Relay switches with Ethernet switches, and the example is still valid, with the exception that Ethernet does not use virtual circuits.
High-Level Data Link Control
The High-Level Data Link Control (HDLC) protocol is a bit-ordered synchronous protocol developed by the International Organization for Standardization (ISO). HDLC is used to directly connect one Cisco router to another. Cisco routers default to using HDLC encapsulation on all synchronous serial interfaces.
Cisco HDLC is a proprietary version of the protocol; it does not communicate over a serial link with any other vendor's HDLC protocol. The proprietary nature of Cisco HDLC is not unusual. All vendors ' HDLC implementations are proprietary because HDLC is a protocol derived from the proprietary Synchronous Data Link Control (SDLC) protocol, which was originally developed by IBM. The following output from the San Jose router on the ZIP network shows the interface serial0/0 using HDLC encapsulation:
San-Jose> show interface serial 0/0 Serial0/0 is up, line protocol is up Hardware is QUICC Serial MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:03, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/64/0 (size/threshold/drops) Conversations 0/6 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 28000 bits/sec, 2 packets/sec 5 minute output rate 1000 bits/sec, 2 packets/sec 4396629 packets input, 1382566679 bytes, 2 no buffer Received 518019 broadcasts, 0 runts, 0 giants, 0 throttles 1824 input errors, 661 CRC, 542 frame, 0 overrun, 0 ignored, 621 abort 4674425 packets output, 430814377 bytes, 0 underruns 0 output errors, 0 collisions, 10 interface resets 0 output buffer failures, 0 output buffers swapped out 2 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
In the previous output, notice that the serial interface encapsulation is HDLC (the default encapsulation for all Cisco serial interfaces), as shown in the fourth line. (Note also that we've used an unambiguous form of the show interfaces serial 0/0 command in the previous example.)
The Point-to-Point Protocol (PPP) is another data-link WAN protocol supported by Cisco devices. PPP was designed as an open protocol that would be used to work with several network layer protocols, such as IP, IPX, and AppleTalk. You can think of PPP as the nonproprietary version of HDLC, although the underlying protocol is significantly different. PPP works in both asynchronous and synchronous encapsulation because the protocol uses a flag to signify the beginning or end of a frame. This flag is used in asynchronous encapsulations to signify the start or stop of a frame and is used as a bit-oriented synchronous encapsulation.
PPP relies on the Link Control Protocol (LCP), which establishes, configures, and tests data-link connections for use by PPP. The Network Control Protocol (NCP) is a series of protocols ”one for each network layer supported by PPP ”for establishing and configuring different network layer protocols to operate over PPP. For IP, IPX, and AppleTalk, the NCP designations are IPCP, IPXCP, and ATALKCP, respectively.
PPP Interface Configuration Subcommands
You can use the IOS interface configuration subcommand encapsulation ppp to enable synchronous PPP on a serial interface. In the following example, we configure synchronous PPP on the San Jose router's serial1/1 interface:
San-Jose #configure Enter configuration commands, one per line. End with CTRL+Z. Configuring from terminal, memory, or network [terminal]? San-Jose(config) #interface serial 1/1 San-Jose(config-if) #encapsulation ppp San-Jose(config-if) #^Z
Note that we have used an unambiguous form of the interface serial1/1 major command and an unambiguous form of the encapsulation ppp interface subcommand in the preceding example.
The following output from the San Jose router on the ZIP network shows the interface serial1/1 using PPP encapsulation:
Serial1/1 is up, line protocol is up Hardware is HD64570 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive not set LCP Open Open: IPCP Last input 0:00:01, output 0:00:01, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/64/0 (size/threshold/drops) Conversations 0/4 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1433 packets input, 117056 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 714 packets output, 150299 bytes, 0 underruns 0 output errors, 0 collisions, 11 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
In the fifth line of the preceding output, you can see that LCP is open. The sixth line shows that IPCP is open as well. We can deduce from the fact that IPCP is open that PPP is configured to encapsulate IP packets across this interface.
X.25 is a packet-switching protocol that supports both SVCs and PVCs that were first developed in the 1970s. The International Telecommunications Union (ITU) is an agency of the United Nations that administers the X.25 protocol. Because of the international acceptance of X.25, it may be the most widely used WAN protocol in the world today.
Like all packet-switching protocols, X.25 essentially defines a network for data communications similar to that of the telephone network and passes data using virtual circuits. The communication between two devices begins with one device calling the other to establish an SVC or PVC, proceeds with data transfer, and then ends with call termination. The X.25 protocol defines a point-to-point communication between data terminal equipment (DTE) and data circuit-terminating equipment (DCE). DTEs (such as Cisco routers) connect to DCEs (such as modems), which connect to one or more X.25 WAN switches and, ultimately, to another DTE.
Data circuit-terminating equipment (DCE) is a device that makes up the network end of the user-to-network interface. The DCE provides a physical connection to the network, forwards traffic, and provides a clocking signal that is used to synchronize data transmission between DCE and DTE devices. Data terminal equipment (DTE) is a device at the user end of a user -network interface that serves as a data source, destination, or both. DTE connects to a data network through a DCE device (for example, a modem) and typically uses clocking signals generated by the DCE.
A call across an X.25 network begins with the origin DTE placing a call with the DCE to which it is connected. The X.25 switches in the network decide how to route the call from origin to destination. All data is then switched from the origin DTE to the destination DTE across the X.25 network, as shown in Figure 3-6.
Figure 3-6. An X.25 Network
The X.25 protocol uses an addressing scheme called X.121. ITU-T Recommendation X X.121. ITU-T Recommendation X.121 specifies the source and the destination address formats for the X.25 protocol on the data link layer. X.25 switches route calls along the path of a virtual circuit based on source and destination X.121 addresses.
X.121 addresses vary in length and can be up to 14 decimal digits long. The first four digits of the X.121 address are called the data network identification code (DNIC). After the DNIC, the remaining digits of the address can be used however the network administrator decides to utilize them.
X.25 Interface Configuration Subcommands
The first step to using X.25 on a Cisco serial interface is to set up the interface so that it can use X.25 encapsulation with the encapsulation x25 command.
The X.25 data link X.121 addresses are not burned into ROM as are LAN addresses. This means that the network administrator needs to tell a Cisco router the local X.121 address on an X.25 serial interface, which is accomplished with the interface configuration subcommand x25 address . Some vendors' X.25 switches require you to set a maximum packet size for input and output packets (the default is 128 bytes). You may need to configure your Cisco router with the proper input packet size (ips) and output packet size (ops) on the serial interface with the commands x25 ips and x25 ops to operate properly on your X.25 network.
X.25 networks have a default input and output window size for packets that are used by flow control mechanisms. You may need to set up the default input window size (win) and output window size (wout) for your X.25 network to work properly, just as you may need to set a maximum packet size. (The default input and output window size is 2 packets.) The IOS interface configuration subcommands x25 win and x25 wout set the input and output window size.
You should check with your X.25 switch vendor for recommendations for the maximum packet size and maximum window size parameters. Coordination of these parameters between the DTE and the DCE is often required to enable the X.25 data link layer to operate properly.
In the following example, we set up the San Jose router with X.25 encapsulation and an X.121 data link address of 537000000001. We also specify an input and output packet size of 256 bytes. We specify the input and output window size as 7 packets.
San-Jose #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. San-Jose(config) #interface serial 1 San-Jose(config-if) #encapsulation x25 San-Jose(config-if) #x25 address 537000000001 San-Jose(config-if) #x25 ips 256 San-Jose(config-if) #x25 ops 256 San-Jose(config-if) #x25 win 7 San-Jose(config-if) #x25 wout 7 San-Jose(config-if) #^Z
Notice the many interface configuration subcommands that are needed to configure the router in this example.
The following show interfaces output shows a router interface using X.25 encapsulation:
Serial 0 is up, line protocol is up Hardware is MCI Serial MTU 1500 bytes, BW 512 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation X25-DTE, loopback not set, keepalive set LAPB state is CONNECT, T1 3000, N1 12000, N2 20, K7, TH 3000 Window is closed IFRAMEs 12/28 RNRs 0/1 REJs 13/1 SABMs 1/13 FRMRs 3/0 DISCs 0/11 Last input 0:00:00, output 0:00:00, output hang never Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 261 packets input, 13212 bytes, 0 no buffer Received 33 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 238 packets output, 14751 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets, 0 restarts
In the previous output, notice that the interface encapsulation is X.25 DTE in the fourth line. The following three lines give Link Access Procedure, Balanced (LAPB) statistics. LAPB is the data link layer protocol used by the X.25 protocol stack that is based on HDLC. If you want to see the status of the X.25 virtual circuits on a Cisco device, you can use the EXEC command show x25 vc .
Frame Relay is a WAN packet-switching protocol that was first developed for use over Integrated Services Digital Network (ISDN, discussed later in this chapter). The initial proposals for Frame Relay standards were presented to CCITT in 1984. Although the standard existed, there were problems with vendor interoperability, and the technology received little industry support until late in the 1980s.
Like X.25, Frame Relay is a packet-switching protocol that has PVCs and SVCs. Most Frame Relay networks today use PVCs because SVCs are just beginning to be imple-mented. Frame Relay uses the call setup, data transfer, and call termination process, as discussed previously with X.25. End devices, such as routers, place calls across the Frame Relay network. After the call is established, the router transfers data and then closes the call. In the case of a PVC, the call is always active, allowing the router to send data without placing the call.
In the same way that X.25 uses X.121 addresses, Frame Relay uses addresses called data-link connection identifiers (DLCI). Each DLCI can have local or global significance throughout the Frame Relay network. The most common use today is for each DLCI to have local significance only. This means that to a device such as a router, the DLCI number on each side of a virtual circuit may be the same because Frame Relay maps a local DLCI number to a virtual circuit at each switch in the WAN. A Frame Relay network example is shown in Figure 3-7.
Figure 3-7. A Frame Relay Network with PVCs
In 1990, Cisco, Digital Equipment Corporation, Northern Telecom, and StrataCom formed a consortium to focus on Frame Relay development and interoperability. This group of vendors took the basic Frame Relay protocol from CCITT and added extensions to the protocol features that allow internetworking devices to communicate easily with a Frame Relay network.
These features, which are called Local Management Interface (LMI), allow Frame Relay DTE devices such as routers to communicate with Frame Relay DCE devices and to exchange the information that is used to pass internetwork traffic over a Frame Relay WAN. LMI messages provide information about the current DLCI values, the global or local significance of the DLCI values, and the status of virtual circuits.
The consortium LMI developed by Cisco, DEC, NT, and StrataCom is now known as the Gang-of-Four LMI, or Cisco LMI . In addition to the consortium LMI, the American National Standards Institute (ANSI) has developed a standard LMI called Annex-D that is used throughout the world on Frame Relay networks.
Frame Relay Interface Configuration Subcommands
To configure Frame Relay on a Cisco serial interface, you must begin by using the encapsulation frame-relay interface subcommand. You can then use the frame-relay interface-dlci subcommand to set the DLCI on the interface. Cisco devices default to using the Cisco LMI on Frame Relay interfaces. You can set the LMI type using the frame-relay lmi-type interface subcommand.
Using the ZIP network as an example, we can configure Frame Relay on the Singapore router as follows :
Singapore #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. Singapore(config) #interface serial 0 Singapore(config-if) #encapsulation frame Singapore(config-if) #frame-relay interface-dlci 100 Singapore(config-if) #frame-relay lmi-type ansi Singapore(config-if) #^Z
The preceding Frame Relay configuration is a basic configuration for a single virtual circuit on a Cisco serial interface. As mentioned earlier, you can also have multiple virtual circuits on a single serial interface and treat each as a separate interface, which is called a subinterface. Think of a subinterface as a hardware interface defined by the IOS software.
The advantage to using subinterfaces is that you can assign different network layer characteristics to each subinterface and virtual circuit, such as IP routing on one virtual circuit and AppleTalk routing on another. You can define virtual interfaces with the interface serial slot/port.number command. The number parameter specifies the subinterface number associated with the slot/port .
The two types of subinterfaces are point-to-point and multipoint . Point-to-point subinterfaces are used when a single virtual circuit connects one router to another. Think of a point-to-point subinterface as a virtual circuit that emulates a dedicated serial link. Multipoint subinterfaces are used when the router is the center of a star of virtual circuits, as shown in Figure 3-8.
Figure 3-8. Point-to-Point (a) and Multipoint (b) Frame Relay Networks
You can define a limitless number of subinterfaces on a given physical interface. (Router memory is the only exception.) In the following example, we define subinterface serial 0.100 on the Singapore router:
Singapore #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. Singapore(config) #interface serial 0 Singapore(config-if) #encapsulation frame Singapore(config-if) #interface serial 0.100 point-to-point Singapore(config-subif) #frame-relay interface-dlci 100 Singapore(config-subif) #frame-relay lmi-type ansi Singapore(config-subif) #^Z
We suggest that you adhere to a numbering scheme for the subinterface numbers you choose. We recommend making the subinterface number match the virtual circuit DLCI number.
To view the status of a Frame Relay interface, you can use the show interfaces command. Following is the output from the show interfaces s 0 command on the Singapore ZIP network router:
Serial0 is up, line protocol is up Hardware is HD64570 MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 459618, LMI stat recvd 459618, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 100 LMI type is CISCO frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 121505/0, interface broadcasts 121505 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/64/0 (size/threshold/drops) Conversations 0/9 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 1000 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 34278826 packets input, 2790079482 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 17 input errors, 7 CRC, 9 frame, 0 overrun, 0 ignored, 1 abort 29613202 packets output, 1145345093 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
You can see the encapsulation of the interface set to Frame Relay in the fourth line of the previous code. LMI information follows on subsequent lines. The following is the output of show interfaces s 0.100 , which examines subinterface status:
Serial0.100 is up, line protocol is up Hardware is HD64570 MTU 1500 bytes, BW 256 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation FRAME-RELAY
The previous output is much shorter than a normal show interfaces command because a subinterface inherits all the diagnostic counters of the major interface it is associated with ”in this case, interface serial0.
You can examine the status of the Frame Relay virtual circuits using the EXEC command show frame pvc or show frame svc maplist . SVCs require the maplist option, which lists the mapping from the current device to the other devices to call and establish SVCs. Sample output for the PVC with DLCI 100 on the Singapore ZIP network router is as follows:
PVC Statistics for interface Serial 0 (Frame Relay DTE) DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.100 input pkts 34263984 output pkts 29648752 in bytes 3135739012 out bytes 1083480465 dropped pkts 93 in FECN pkts 170 in BECN pkts 11741 out FECN pkts 0 out BECN pkts 0 in DE pkts 15741022 out DE pkts 0 pvc create time 7w5d, last time pvc status changed 1d10h
Asynchronous Transfer Mode
The Asynchronous Transfer Mode (ATM) is a standard defined by the ITU-T for cell relay. In the case of ATM, all cells are 53 bytes long.
Using cell relay, ATM is designed to handle multiple types of network services, including voice, video, and data. An ATM network comprises ATM switches (DCE devices) and ATM endpoints (DTE devices). The endpoints send information to the ATM switches, which segment the information into cells and switch the cells through the network. This process is the same for all three types of traffic handled by the ATM network.
The ITU-T based ATM on the Broadband Integrated Services Digital Network (BISDN) standard, which was initially designed for sending voice, video, and data over a public network. A coalition of companies formed the ATM Forum, which has released specifications for multiple vendor interoperability and extensions of ATM for public and private networks. To date, the ATM Forum has written three versions of User-Network Interface (UNI), a protocol similar in concept to Frame Relay LMI that standardizes communication between ATM devices and switches. The ATM Forum has also released documents defining standard communications between ATM switches (called the Private Network-to-Network Interface, or PNNI) and a method to emulate classic LAN architectures over an ATM network, which is called LAN Emulation (LANE).
Like the packet-switching technologies we have seen in previous sections of this chapter, ATM provides two types of connection-oriented virtual circuits: PVCs and SVCs. ATM also has a connectionless service that allows it to operate similarly to a LAN technology. ATM provides both connection-oriented and connectionless services using virtual channels. A virtual channel is similar to a virtual circuit in X.25 or Frame Relay.
The ATM network defines connections through the ATM network as virtual paths, which are identified by virtual path identifier (VPI) numbers. A virtual path is a bundle of virtual channels that are all switched across the ATM network based on the same VPI. You can think of a virtual path as a grouping mechanism to define the route for a series of virtual channels.
A virtual channel is identified by the combination of a VPI and a virtual channel identifier (VCI). The VPI defines the path that the virtual channel takes through the network, and the VCI is unique for each connection in the VPI. VPI and VCI numbers have only local significance, just as DLCI numbers for Frame Relay often have only local significance. ATM switches map the VPI/VCI numbers across a particular link to the next device in the connection (in the direction of the destination).
ATM networks bundle virtual paths into groups called transmission paths. A transmission path contains virtual paths, which in turn contain virtual channels, as shown in Figure 3-9.
Figure 3-9. The Relationship Between ATM Virtual Channels, Virtual Paths, and Transmission Paths
ATM networks can use two different types of addressing, one based on E.164 addressing (an addressing scheme similar to phone numbers) and another based on OSI network service access point (NSAP) addresses. The E.164 addressing scheme was developed by the ITU-T, and the NSAP addressing scheme was added by the ATM Forum. It is common to use E.164 addressing on public ATM networks that are provided by telecommunications carriers and to use NSAP addressing on private ATM networks, such as one connecting ATM switches and internetworking devices.
As noted earlier, ATM is designed to handle voice, video, and data services. To hide some of the complexities of the ATM protocol from these upper-layer services, ATM has defined three ATM adaptation layers. ATM adaptation layers (AAL) are protocols that sit on the OSI reference model at the top of the data link layer. These layers, each called an AAL, are responsible for providing the various ATM services to network layer protocols. AAL1 is a connection-oriented service that is commonly used to emulate dedicated circuits through the ATM network. Common AAL1 applications are voice or video connections. The next AAL, AAL3/4, supports both connection-oriented and connectionless data. Many AAL3/4 connections are used by network service providers for connectionless data. AAL3/4 is designed to integrate easily into a Switched Multimegabit Data Service (SMDS) network, another standard cell relay technology. AAL5, the third AAL, also supports both connection-oriented and connectionless service. AAL5 is used to transfer information that does not need to integrate easily with SMDS, such as data across a private LAN or WAN. Today, most ATM connections on private internetworks use AAL5.
Another feature of ATM is that it supports quality of service (QoS) guarantees across the network. Each ATM device interacts with the ATM network to provide a certain quality of service for each virtual path based on a traffic contract, traffic shaping, and traffic policing. A traffic contract specifies the requirements of the virtual channel, such as peak bandwidth, average sustained bandwidth, and burst size. Traffic shaping controls the flow of traffic to fit within the traffic contract by constraining data bursts, passing cells in a consistent flow, and limiting peak data rates. Traffic policing enforces the traffic contract by examining the actual traffic flow and comparing it to the traffic contract. Traffic policing procedures may enable switches to discard cells if they violate the traffic contract in a congestion situation. These QoS features of ATM make the protocol powerful in dealing with the various data requirements of a combined voice, video, and data network.
ATM Interface Configuration Subcommands
Cisco ATM interfaces are dedicated interface processors (or port adapters on a VIP card). This means that you do not need to specify the interface subcommand encapsulation for ATM interfaces; ATM encapsulation is all that is supported by the hardware. You do need to specify the virtual circuits that exist on a given interface using the atm pvc interface subcommand. The following output shows the configuration of PVC 1 using VPI 0 and VCI 100 for an AAL5 virtual channel:
Router #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. Router(config) #int atm2/0 Router(config-if) #atm pvc 1 0 100 aal5snap Router(config-if) #^Z
You can examine the status of an ATM interface using the show interfaces command. Following is the output from interface atm2/0 for the preceding configuration:
ATM2/0 is up, line protocol is up Hardware is cxBus ATM MTU 4470 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ATM, loopback not set, keepalive set (10 sec) Encapsulation(s): AAL5, PVC mode 256 TX buffers, 256 RX buffers, 1024 Maximum VCs, 1 Current VCs Signalling vc = 1, vpi = 0, vci = 100 ATM NSAP address: BC.CDEF.01.234567.890A.BCDE.F012.3456.7890.1234.13 Last input 0:00:05, output 0:00:05, output hang never Last clearing of "show interface" counters never Output queue 0/40, 0 drops; input queue 0/75, 0 drops Five minute input rate 0 bits/sec, 0 packets/sec Five minute output rate 0 bits/sec, 0 packets/sec 144 packets input, 3148 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 154 packets output, 4228 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets, 0 restarts
In the preceding output, you can see the ATM encapsulation set on the fourth line, the AAL5 encapsulation and PVC mode on the fifth line, and the VC, VPI, and VCI numbers on the seventh line. This interface is also configured for an ATM NSAP address, as you can see in the eighth line.
Digital Subscriber Line
Digital Subscriber Line (DSL) is a technology that has become popular in recent years and has the capability to provide dedicated high-capacity bandwidth to end users. DSL employs a star network topology, with the center of the star having dedicated connections to the leaf nodes with twisted-pair copper wire. The bandwidth between the leaf nodes and the center of the star can range from 64 Kbps to 8 Mbps, depending on the characteristics of the twisted-pair copper wire, the physical interconnections, the distance the signal travels, environmental conditions, and the specific DSL technology used. Shorter distances, minimum interconnections, and large-gauge copper wire can yield faster data transmission rates.
Many different DSL technologies are in use in the market today. In the industry, the term xDSL refers to a number of different forms of DSL, such as Asymmetric Digital Subscriber Line (ADSL), Symmetric Digital Subscriber Line (SDSL), and Very High Data Rate Digital Subscriber Line (VDSL).
ADSL technology provides asymmetrical bandwidth between the center of the star and a leaf node. Data transmission from the center of the star to the leaf node is faster (often at least three times as fast) than the opposite path. ADSL is an attractive service for an Internet service provider (ISP) to offer end users because Internet users typically download more data than they transmit. The ISP is the center of the DSL star topology, and users represent the leaf nodes in this configuration. The ISP connects the twisted-pair wire with an ADSL modem on each end to form a circuit. On the twisted-pair wire, an ADSL modem makes three separate channels: 1) the downstream channel, 2) the duplex channel, and 3) a basic telephone service channel. An ADSL service provider can use all three of these channels to provide data and telephone service to an end user.
Network equipment, such as routers and bridges, typically connects to an ADSL modem using WAN technology such as ATM or Frame Relay. Each end user, or sometimes each channel per end user, appears to the network equipment as a separate virtual circuit. On a high-speed WAN interface to an ADSL modem, a router may support a large number of virtual circuits and corresponding users, as shown in Figure 3-10.
Figure 3-10. An ADSL Network Connected to a Cisco ATM Interface with Separate Virtual Circuits for each DSL Device
In today's market, ISPs are offering only asymmetrical data services to end users using ADSL, but it is predicted that ISPs may begin to offer local telephone service in the near future. Many factors, including regulatory issues, may affect this future dramatically.
SDSL gives the same amount of bandwidth in both directions (similar to any other full-duplex circuit) between the center of the star and the leaf nodes. SDSL is a technology that many small businesses are using for interoffice connections and connections to the Internet. ISPs and other providers provision and connect to SDSL circuits in a similar manner to ADSL. The main difference is that the modems on either end of the twisted-pair wiring provide a symmetrical data channel.
VDSL, the Very High Data Rate Digital Subscriber Line, enables high-bandwidth connections over short distance of twisted-pair copper telephone lines. Like other forms of DSL, the actual speed varies with the length of the twisted-pair copper between the DSL modems. At this time, VDSL is still a technology being developed, but high data rates would enable a wealth of new services for DSL providers. The developers of VDSL envision that bandwidth rates between 13 Mbps and 55 Mbps are a possibility. Initial development of VDSL will most likely be asymmetrical like ADSL, with upstream bandwidth between 1.6 Mbps and 2.3 Mbps.
Cisco makes a series of routers, the 600 series, that have DSL interfaces. The Cisco 600 series routers can act as Ethernet to DSL bridges and routers or can be modems for both ADSL and SDSL connections. At this time, the Cisco 600 series operates using an IOS variant called the Operating System (CBOS). The configuration of the CBOS is different than configuring IOS, but Cisco plans to change the user interface of the CBOS to be compatible with the IOS. Using a combination of the IOS and CBOS products enables you to build a network in a variety of environments.
Integrated Services Digital Network
The Integrated Services Digital Network is a connection-oriented WAN technology that uses digital telephony to digitize voice, data, video, and other information over existing telephone wires. Currently, many telephone carriers throughout the world offer ISDN as a digital subscription service to users for Internet access, voice telephone calls, and videoconferencing. The result of setting up an ISDN network is the capability for ISDN devices to place phone calls over the telephone carrier network that carry many types of data. Conceptually, you may want to think of ISDN as a digital modem that can carry multiple types of data.
Devices that connect to the ISDN network are terminals. The two types of terminals are those that understand ISDN standards, which are called terminal equipment type 1 (TE1), and those that predate ISDN standards, which are called terminal equipment type 2 (TE2). TE2s connect to the ISDN network using a terminal adapter (TA). TE1s do not need a TA.
The next step in talking to the ISDN network is to connect to a network termination type 1 (NT1) or network termination type 2 (NT2) device. Both types of network termination devices convert wiring used within the telephone carrier (four-wire) network to the wiring most often found in homes and businesses throughout the world ( two-wire local loop).
In North America, it is common to find an NT1 at a user location and inside a networking device. Most ISDN connections in North America from ISDN cards in PCs or from ISDN routers use a built-in NT1. Elsewhere, the telephone carrier provides the NT1; it is not part of the ISDN device at the user location. The NT2, which adds data link layer and network layer functionality to an NT1, usually is used with connecting private branch exchange (PBX) devices. The relationship between these ISDN components is shown in Figure 3-11.
Figure 3-11. The Components of an ISDN Network
ISDN provides two types of services to devices: Basic Rate Interface (BRI) and Primary Rate Interface (PRI). An ISDN BRI interface offers two B channels and one D channel (2B+D). BRI B channel service, which operates at 64 Kbps, is used to carry user data. BRI D channel service, which operates at 16 Kbps, is normally used to transfer ISDN control information. The BRI D channel can be set up to carry user data under some circumstances. (It is often used to carry X.25 traffic in Europe.) Using a single B channel, a BRI interface can transfer data at 64 Kbps, but using both B channels, ISDN can achieve transfer rates of 128 Kbps.
An ISDN PRI offers 23 B channels at 64 Kbps each and one D channel, also operating at 64 Kbps, in North America and Japan. This means that a PRI interface can be used to place 23 different digital phone calls. In Europe, Australia, and other parts of the world, ISDN PRI provides 30 B channels and 1 D channel at 64 Kbps each.
A service profile identifier (SPID) is a number that some telephone carriers use to define the services available to an ISDN device. In many cases, the SPID number is the equivalent of the ISDN device's phone number. The ISDN device gives the SPID to the ISDN switch, which then allows the device to access the network for BRI or PRI service. Without providing a valid SPID, many ISDN switches do not allow an ISDN device to place a call on the network.
ISDN Interface Configuration Subcommands
The configuration of ISDN on Cisco IOS devices requires you to tell the device the ISDN switch type to which it is connected. This requirement is needed because the ISDN terminal needs to talk to each different vendor's ISDN switch in a proprietary manner.
You can find all the ISDN switch types available for the IOS device you are using by invoking the IOS Help system with the configuration command isdn switch-type ? . Your telephone carrier should tell you the switch type you are connected to when you order ISDN service.
You can configure the ISDN switch type to which the IOS device is connected with the isdn switch-type major command. The Cisco device needs to know the manufacturer of the ISDN switch it will talk to, because each manufacturer has a proprietary protocol for signaling. Without the proper ISDN switch type configured, the Cisco device cannot communicate with the ISDN switch at the telephone carrier facility.
For each ISDN BRI interface, you need to specify the SPIDs using the isdn spid1 and isdn spid2 interface subcommands. Each SPID identifies a unique B channel to the ISDN switch. We need to specify the two different SPIDs for a BRI interface.
To use ISDN PRI on a Cisco device, you need an ISDN PRI interface. Currently, this type of interface is supported on the high-end and midrange routers and access servers, such as the Cisco 3600, Cisco 4000, and Cisco 7000 series routers, and the Cisco 5300 access servers.
The PRI communicates with the ISDN switch via a T1 controller. A T1 controller is a set of data link software that handles the data link signaling on the interface. You need to specify the data link-specific information for the T1 controller, such as the framing method and line coding method. In the following example, we configure a T1 controller on interface serial 1/0 for Extended Superframe (ESF) framing, binary 8-zero substitution (B8ZS) line coding, and an ISDN PRI using 24 timeslots. ESF is a framing type used on T1 circuits. It consists of 24 frames of 192 data bits each, with the 193rd bit providing timing and other functions. B8ZS is a line-coding mechanism that guarantees ones density over a link by substituting a special code whenever 8 consecutive zeros are sent and then removes the special code at the remote end of the connection.
Router #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. Router(config) #controller T1 1/0 Router(config-if) #framing esf Router(config-if) #linecode b8zs Router(config-if) #pri-group timeslots 1-24 Router(config-if) #^Z
In the following example, we configure the interface BRI0 on the ZIP network access server in Seoul to talk to the Northern Telecom DMS100 switch to which it is attached. We also configure the ISDN interface to encapsulate data in PPP after the digital call is placed. We need to specify PPP encapsulation because ISDN specifies the method used to establish the digital phone call, not the data link layer encapsulation for packets across this technology:
Seoul-AS1 #configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CTRL+Z. Seoul-AS1(config) #isdn switch-type basic-dms100 Seoul-AS1(config) #interface bri0 Seoul-AS1(config-if) #encapsulation ppp Seoul-AS1(config-if) #isdn spid1 8864567832 Seoul-AS1(config-if) #isdn spid2 8864567833 Seoul-AS1(config-if) #^Z
You can view the status of an ISDN interface with the show interfaces command. In the following example, we examine the status of the BRI0 interface on the Seoul-AS1 access server:
BRI0 is up, line protocol is up (spoofing) Hardware is BRI with U interface and external S bus interface MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Last input 00:00:02, output never, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 644807 packets input, 2938029 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 700200 packets output, 3329945 bytes, 0 underruns 0 output errors, 0 collisions, 5 interface resets 0 output buffer failures, 0 output buffers swapped out 3 carrier transitions
Note in the first line of this output that the interface BRI0 is shown as spoofing . Spoofing means that the ISDN interface always pretends to be up for routing packets, even though it may not have a valid digital call placed. The ISDN interface spoofs the routing protocol and other software in the IOS device into believing that the interface is up and running so that the ISDN interface receives packets and then places the digital call with the ISDN network. After the call is made, the interface stays up (and is not spoofing) for a period of time until the call is idle. The interface then hangs up the call and returns to the spoofing mode until it needs to place another digital call to route data. This mechanism-spoofing that the interface is up, dialing the digital call to pass the data, and then hanging up the call when idle-is called dial-on-demand routing . In the fourth line of the previous output, you can see that the ISDN interface is using PPP encapsulation.