The WAN Access Challenge for Small and Branch Offices
Advancements in dial-up, switched, and routing access, as well as the need for real-time voice and video, have presented an even greater challenge to equipment
designers in overcoming the WAN bottleneck.
By Nabil G. Damouny
Early data WAN access was confined to private, leased-line connections interconnecting major corporate offices. These connections were based on private lines (such as T1 time division multiplexed [TDM] connections). Such connections were expensive, inefficient, and required dedicated back-up circuits to improve reliability and fault-tolerance. As a result, smaller offices did not have a viable way to communicate over the WAN.
The dial-up model emerged in the late 1980s to meet the needs of smaller businesses, branch offices, and emerging telecommuters. This model used 19.2-kbps WAN connections,and eventually evolved into the V.90, 56-kbps connections used today. The dial-up model remains the only alternative available for mobile users, due to the ubiquitous PSTN and worldwide service availability. More importantly, the advent of the Internet in the early 1990s reinforced the 56-kbps dial-up model for connecting to the
ISP.
At the same time, the 1990s have seen rapid technological advancements in both the office LAN and the WAN backbone. In the office LAN, switched Ethernet provides dedicated 10-Mbps connections to the desktop, in addition to Fast Ethernet (100 Mbps) and Gigabit Ethernet connections to the workgroup and the corporate servers, respectively (see
Figure 1
). In the WAN backbone, the infrastructure has been built around high-speed ATM switches interconnected with
gigabit SONET connections, and most recently terabit routers connected over SONET links.
These advancements, coupled with the need to communicate real-time applications (such as voice and video), have presented an even greater challenge to equipment and service providers in overcoming the WAN access bottleneck — how to capitalize on new WAN services in a graceful and timely manner.
The dial-up model
The increasing need for telecommuting and Internet access has given the
dial-up WAN access method a big boost (see
Figure 1
). Dial-up access can be either analog or digital. A V.90 connection at 56 kbps is an asynchronous analog connection. An ISDN basic rate interface (BRI) at 128 kbps is a synchronous digital dial connection. In the dial-up model, a dial-up router at the CPE is connected to the local Ethernet and to one or more wide-area analog connections. Multiple wide-area connections can be inverse multiplexed to form an aggregate
WAN connection to the same destination (for example, using the two B channels of an ISDN connection to form a single 128-kbps connection). At the receiving end, a remote access server (RAS) terminates the dial connection, both analog and digital, and the associated point-to-point (PPP) session. The RAS is located at the headquarters office or at the ISP’s point of presence (PoP).
A plethora of accesses and services
By examining the available spectrum of bandwidths and services, a
collection of access speeds, access technologies, and services can be found. For example, dial-up access (such as V.90 and ISDN) is in the narrowband spectrum. Narrowband is below the T1 rate of 1.5 Mbps (as shown in
Figure 2
). Frame Relay service is usually offered at narrowband speed, such as 256 kbps. DSL access, on the other hand, is in the broadband spectrum because it spans all the way up to 8 Mbps, (such as in the case of ADSL).
Access bandwidth over
existing copper is usually limited to 8 Mbps. This bandwidth can be achieved by using ADSL or by inverse multiplexing four T1 or four E1 lines.
The need for PPP
The point-to-point protocol (PPP) is a data link layer (DLL) protocol, based on the traditional high-level data link control (HDLC) protocol. PPP was first used in router-based data networks as a protocol running on top of T1 access lines, to ensure multivendor router interoperability. PPP was given a big shot in the arm when it was
endorsed as the successor for serial line Internet protocol (SLIP) for asynchronous access. With its security provisioning, multiprotocol support, IP address dynamic assignment, and support for asynchronous and synchronous connections, PPP became the de facto standard for Internet access.
PPP provides an evolutionary way to migrate existing ISP infrastructure. New services would only replace the underlying layers carrying the PPP session. As a result, autoconfiguration of IP addresses and domain
names is preserved. The challenge here is for equipment designers to preserve graceful service migration when implementing PPP in their products.
PPP frame format is based on HDLC framing (see
Figure 3
). The address field is set to ‘FF’ and the control field is set to ‘03’. The protocol ID (PID) field indicates the protocol type (such as IP or IPX) that the PPP frame is carrying. The information field is large enough to accommodate the
largest Ethernet packet’s information (1,500 bytes) and type/length (2) fields, or 1,502 bytes. A cyclic redundancy check 32 (CRC 32) (also known as the frame check sequence [FCS]) is generated for the information field.
WAN service-specific challenges
A WAN service dictates a specific physical cable plant/line coding, a specific DLL, and an optional PPP sub-layer. WAN services such as ISDN and Frame Relay demand specific requirements from equipment designers, both at the access and
at the service provisioning ends. Focused industry forums have been formed to address these specific needs. For example, the ADSL Forum has chosen ATM as the transport layer for ADSL and G.Lite (a form of asymmetric DSL).
Figure 4
depicts a simplified version of the Open Systems Interconnect (OSI) model. Certain layers of this model need to perform specialized functions based on the particular WAN service being addressed. These layers are WAN
service-specific. For example, the WAN service will demand one or more transport mechanisms for the DLL: TDM for leased lines, packets for Frame Relay, or cells for ATM.
Higher layers are more generic and are not service-specific. Examples of higher-layer functions are the inclusion of an HTTP server function for remote web-based management, SNMP for network management, and content-specific applications such as H.323 for voice and video.
The net effect is that an equipment designer, who currently has a
traditional ISDN-service CPE implementation can easily migrate to DSL by replacing the service-specific layers, without having to learn about ATM and other new protocols.
The DSL model
First, the equivalent dial-up model for DSL and its CPE requirements will be examined (see
Figure 5
). It should be noted that DSL service is an always-on service, connecting the user to a DSL access multiplexer (DSLAM) located in the serving CO, or the serving
digital loop carrier (DLC) of the network access provider (NAP). The NAP is the administrative entity that terminates the CO end of an ADSL line. The network service provider (NSP) is the administrative entity that provides access to higher-level network services.
DSL provisioning requires a DSL access device to use RFC1483 bridging (multiprotocol encapsulation over ATM adaptation Layer 5 [AAL5]) as specified by the IETF, or the most recent RFC2364 encapsulation of PPP packets over ATM AAL5. The resulting
DSL access device can then be used as a bridge only, a router only, or a combined bridging router (see Figure 6). The ISP’s RAS then terminates the PPP session.
The ADSL Forum specifies that PPP is to be carried over ATM using AAL5 and virtual circuit (VC) multiplexing. Each (VC) carries only one PPP session, and multiplexing PPP with other protocols is not allowed. In addition, mapping PPP over AAL5 uses null encapsulation as there is no need for cell delineation and checksum components. The
resulting system supports multiple VCs (each carrying an independent PPP session) and allows simultaneous connectivity to the public Internet and corporate LAN. This is referred to as VC multiplexing, and has the following advantages:
-
Per VC/session quality of service (QoS)
— consistent with the ATM paradigm to configure each VC with application-specific traffic and QoS characteristics.
-
Security
— ATM VC carries only PPP. PPP authentication and
authorization functions apply to this ATM connection.
-
Lower overhead
— ATM VC is dedicated to PPP. An additional multiplexing layer between AAL5 and PPP is not necessary.
Architecture and design of DSL CPE
In the late 1980s, equipment designers used general-purpose RISC processors to develop stand-alone bridges and routers. These bridges and routers were first targeted at high-end, performance-conscious LAN connectivity. Later, designs for remote bridging/routing
requiring WAN connectivity for branch offices migrated toward the use of off-the-shelf communication processors with an on-chip CPU. In the late 1990s, network processors emerged to address performance-intensive LAN switches.
Although network processors are optimized for networking applications, they have become general purpose in nature due to the ever-growing and diversified networking market. Spanning the LAN, the WAN, and the myriad of other services offered by public carriers, the networking
market is no longer a niche market.
Early network processors focused on accelerating Layer 2 (DLL), and later, Layer 3 (Network Layer) of the 7-Layer OSI model, for the LAN environment. This has been done in the same way digital signal processors (DSPs) have been used to implement the Layer 1 physical layer (PHY).
Service-specific network processors
Service-specific network processors extend the network processor concept one major step forward to form personalized network processors
targeted at specific WAN services. Service-specific network processors are integrated hardware/software products that implement all of the necessary functions required for a specific WAN service such as ADSL. In this context, ADSL is considered a service, as it requires specific protocols to run on top of the DSL access (such as PPP and ATM).
Service-specific network processors address many of the WAN service needs, such as avoiding WAN access bottlenecks, capitalizing on existing infrastructure,
capitalizing on existing access methods (such as using PPP), and targeting a specific transport mechanism (such as TDM, packets, or cells).
DSL network processor
Applying the service-specific concept to DSL produces the DSL network processor. This platform needs to include the following key components:
-
DSL network processor IC
— highly integrated communication processor with on-chip RISC engine and CPU peripherals
-
DSL network processor OS
— industry-standard RTOS kernel with preemption and multitasking capabilities, generic TCP/IP stacks, and targeted drivers
-
DSL network processor stacks
— industry-standard ATM encapsulation and signaling stack, plus a PPP stack, which includes IP control protocol (IPCP) and challenge handshake authentication protocol (CHAP).
Figure 6
depicts the internal details of these three major components. In addition, an application
programming interface (API) needs to be included so an equipment designer can add higher-layer value-add and differentiation to the equipment. The API can simply be the IP layer for higher-layer IP applications such as dynamic host configuration protocol (DHCP), network address translation (NAT), and SNMP. The DSL network processor IC has standard interfaces to connect to the Ethernet side and to the DSL side. On the Ethernet side, an integrated media access control (MAC)/PHY chip for a 10-Mbps Ethernet is
used. On the DSL side, an off-the-shelf DSL chipset executing the specific DSL algorithm flavor is used.
The voice factor
The voice and data convergence revolution has heated up in the last year, fueled by the promise of cost savings and the proliferation of the Internet. Carrying voice over the data networks can take one of many flavors: voice over frame, voice over cells, and voice over IP (VoIP). Voice over frame uses Frame Relay service, where the digitized voice is encapsulated
in standard Frame Relay frames and is switched using Frame Relay switches. Voice over cells uses ATM transport, where the digitized voice is encapsulated in cells using AAL1 or AAL2. The voice travels over the ATM switch-based network. With VoIP, digitized voice is packetized in IP packets and is transported over a router-based network.
Adding voice support at the CPE
Analog voice requires the use of a subscriber line IC (SLIC) and a codec for conversion to a pulse code modulation
(PCM)-encoded 64-kbps stream, using 8-kHz sampling frequency and 8-bit sample size. This voice support occupies a single digital signal level 0 (DS0) time slot. The encoding process is known as the ITU G.711 digital encoding standard. Multiple encoded voice channels can interface to a PCM highway such as an H.100 bus. If all analog voice channels are simultaneously busy, the multiple encoded streams will occupy as many DS0 time slots as there are voice channels. Digital voice can be supported by providing an
interface to a channelized T1 trunk off a PBX. The interface supports the equivalent max of 24 x 64 kbps or twenty-four DS0 time slots.
CPE supporting analog and digital voice interfaces should have provisions to interface to a PCM highway. This capability allows the CPE to accept individual analog connections off a codec, or a digital T1 connection off a local PBX. On the wide area connection side, many CPE vendors are offering voice support over traditional T1 and Frame Relay connections, and the
current trend is to do the same using DSL.
Such voice-capable CPE may use a next-generation service-specific network processor providing an interface to a PCM highway. These processors will be bundled with higher-layer voice-specific stacks such as H.323.
New digital encoding schemes capitalize on state-of-the-art DSP technology. An example is the ITU G.729A where the resulting compressed voice channel requires only 8 kbps. When such a compressed voice is packetized in IP packets, the
resulting voice bit stream can be up to 30 kbps, due to the fact that VoIP uses an 8-byte IP header followed by a 20-byte user datagram protocol (UDP) header, which is in turn followed by a 12-byte real-time protocol (RTP) header. Some CPE vendors use proprietary header compression mechanisms bringing the additional 40-byte header down to around 4 bytes.
Looking ahead at VPNs
One major movement forward is the application of virtual private networks (VPNs) for the converged voice and data
networks serving the needs of small and branch offices. Today’s VPNs are built using the Internet or a service provider’s IP, Frame Relay, or ATM infrastructure. VPNs based on IP can naturally extend the ubiquitous nature of intranets. This extension can be over wide-area links to remote offices, mobile users, and telecommuters, creating enterprise-wide intranets. Furthermore, VPN can support extranets linking business partners, customers, and suppliers, providing better customer satisfaction and
reduced manufacturing costs.
DSL service offerings are emerging as an attractive alternative to T1 for constructing VPNs. In this case, ATM over DSL may be used to ensure rich QoS and security features.
It remains to be seen how security, authentication, and firewall functions for VPNs will be implemented. Additionally, the roles of the generic network processor, the service-specific network processor, and the DSP, in implementing these real-time, compute-intensive functions still need to be
determined.
Nabil G. Damouny is vice president of applications engineering for Basis Communications Corp. He holds three patents. He obtained a BSEE from IIT, Chicago and an MSEEfrom UCSanta Barbara. He can be reached at
nabil@basiscomm.com
.
Return to the
Table of Contents
Puzzled by a network processing design issue?