Welcome to EdenFX Systems! EdenFX Systems Handbook

Chapter 3 Service EdenFX Systems

3.1.2 Networks EdenFX Systems (under construction)

Table of Contents
3.1.2.1 Introduction
3.1.2.1.1 The Internet Model
3.1.2.1.1.1 A Brief History of the Internet and IP Technologies
3.1.2.1.1.2 The Open Systems Interconnection (OSI) Model
3.1.2.1.1.3 The TCP/IP Model
3.1.2.1.1.4 The Need for Design in IP Networks
3.1.2.1.1.5 Designing an IP Network
3.1.2.1.2 Application Considerations
3.1.2.1.2.1 Bandwidth Requirements
3.1.2.1.2.1 Performance Requirements
3.1.2.1.2.1 Protocols Required
3.1.2.1.2.1 Quality of service/Type of Service (QoS/ToS)
3.1.2.1.2.1 Sensitivity to Packet Loss and Delay
3.1.2.1.2.1 Multicast
3.1.2.1.2.1 Proxy-Enabled
3.1.2.1.2.1 Directory Needs
3.1.2.1.2.1 Distributed Applications
3.1.2.1.2.1 Scalability
3.1.2.1.2.1 Security
3.1.2.1.3 Platform Considerations
3.1.2.1.4 Infrastructure Considerations
3.1.2.1.5 The Perfect Network
3.1.2.2 The Network Infrastructure
3.1.2.2.1 Technology
3.1.2.2.1.1 The Basics
3.1.2.2.1.2 LAN Technologies
3.1.2.2.1.3 WAN Technologies
3.1.2.2.1.4 Asynchronous Transfer Mode (ATM)
3.1.2.2.1.5 Fast Internet Access
3.1.2.2.1.6 Wireless IP
3.1.2.2.2 The Connecting Devices
3.1.2.2.2.1 Hub
3.1.2.2.2.1 Bridge
3.1.2.2.2.1 Router
3.1.2.2.2.1 Switch
3.1.2.2.3 ATM Versus Switched High-Speed LAN
3.1.2.2.4 Factors That Affect a Network Design
3.1.2.2.4.1 Size Matters
3.1.2.2.4.2 Geographies
3.1.2.2.4.3 Politics
3.1.2.2.4.4 Types of Application
3.1.2.2.4.5 Need For Fault Tolerance
3.1.2.2.4.6 To Switch or Not to Switch
3.1.2.2.4.7 Strategy
3.1.2.2.4.8 Cost Constraints
3.1.2.2.4.9 Standards
3.1.2.3 Address, Name and Network Management
3.1.2.3.1 Address Management
3.1.2.3.1.1 IP Addresses and Address Classes
3.1.2.3.1.2 Special Case Addresses
3.1.2.3.1.3 Subnets
3.1.2.3.1.4 IP Address Registration
3.1.2.3.1.5 IP Address Exhaustion
3.1.2.3.1.6 Classless Inter-Domain Routing (CIDR)
3.1.2.3.1.7 The Next Generation of the Internet Address IPv6, IPng
3.1.2.3.1.8 Address Management Design Considerations
3.1.2.3.2 Address Assignment
3.1.2.3.2.1 Static
3.1.2.3.2.2 Reverse Address Resolution Protocol (RARP)
3.1.2.3.2.3 Bootstrap Protocol (BootP)
3.1.2.3.2.4 Dynamic Host Configuration Protocol (DHCP)
3.1.2.3.3 Name Management
3.1.2.3.3.1 Static Files
3.1.2.3.3.2 The Domain Name System (DNS)
3.1.2.3.3.3 Dynamic Domain Name System (DDNS)
3.1.2.3.3.4 DNS Security
3.1.2.3.3.5 Does The Network Need DNS?
3.1.2.3.3.6 Domain Administration
3.1.2.3.3.7 A Few Words on Creating Subdomains
3.1.2.3.3.8 A Note on Naming Infrastructure
3.1.2.3.3.9 Registering An Organization’s Domain Name
3.1.2.3.3.10 Dynamic DNS Names (DDNS)
3.1.2.3.3.11 Microsoft Windows Considerations
3.1.2.3.3.12 Final Word On DNS
3.1.2.3.4 Network Management
3.1.2.3.4.1 The Various Disciplines
3.1.2.3.4.2 The Mechanics of Network Management
3.1.2.3.4.3 The Effects of Network Management on Networks
3.1.2.3.4.4 The Management Strategy
3.1.2.4 IP Routing and Design
3.1.2.4.1 The Need for Routing
3.1.2.4.2 The Basics
3.1.2.4.3 The Routing Protocols
3.1.2.4.3.1 Static Routing versus Dynamic Routing
3.1.2.4.3.2 Routing Information Protocol (RIP)
3.1.2.4.3.3 RIP Version 2
3.1.2.4.3.4 Open Shortest Path First (OSPF)
3.1.2.4.3.5 Border Gateway Protocol-4 (BGP-4)
3.1.2.4.4 Choosing a Routing Protocol
3.1.2.4.5 Bypassing Routers
3.1.2.4.5.1 Router Accelerator
3.1.2.4.5.2 Next Hop Resolution Protocol (NHRP)
3.1.2.4.5.3 Route Switching
3.1.2.4.5.4 Multiprotocol over ATM (MPOA)
3.1.2.4.5.5 VLAN IP Cut-Through
3.1.2.4.6 Important Notes about IP Design
3.1.2.4.6.1 Physical versus Logical Network Design
3.1.2.4.6.2 Flat versus Hierarchical Design
3.1.2.4.6.3 Centralized Routing versus Distributed Routing
3.1.2.4.6.4 Redundancy
3.1.2.4.6.5 Frame Size
3.1.2.4.6.6 Filtering
3.1.2.4.6.7 Multicast Support
3.1.2.4.6.8 Policy-Based Routing
3.1.2.4.6.9 Performance
3.1.2.5 Remote Access
3.1.2.5.1 Remote Access Environments
3.1.2.5.1.1 Remote-to-Remote
3.1.2.5.1.2 Remote-to-LAN
3.1.2.5.1.3 LAN-to-Remote
3.1.2.5.1.4 LAN-to-LAN
3.1.2.5.2 Remote Access Technologies
3.1.2.5.2.1 Remote Control Approach
3.1.2.5.2.2 Remote Client Approach
3.1.2.5.2.3 Remote Node Approach
3.1.2.5.2.4 Remote Dial Access
3.1.2.5.2.5 Dial Scenario Design
3.1.2.5.2.6 Remote Access Authentication Protocols
3.1.2.5.2.7 Point-to-Point Tunneling Protocol (PPTP)
3.1.2.5.2.8 Layer 2 Forwarding (L2F)
3.1.2.5.2.9 Layer 2 Tunneling Protocol (L2TP)
3.1.2.5.2.10 VPN Remote User Access
3.1.2.6 IP Security
3.1.2.6.1 Security Issues
3.1.2.6.1.1 Common Attacks
3.1.2.6.1.2 Observing the Basics
3.1.2.6.2 Solutions to Security Issues
3.1.2.6.2.1 Implementations
3.1.2.6.3 The Need for a Security Policy
3.1.2.6.3.1 Network Security Policy
3.1.2.6.4 Incorporating Security into Your Network Design
3.1.2.6.4.1 Expecting the Worst, Planning for the Worst
3.1.2.6.4.2 Which Technology To Apply, and Where?
3.1.2.6.5 Security Technologies
3.1.2.6.5.1 Securing the Network
3.1.2.6.5.2 Securing the Transactions
3.1.2.6.5.3 Securing the Data
3.1.2.6.5.4 Securing the Servers
3.1.2.6.5.5 Hot Topics in IP Security
3.1.2.7 Multicasting and Quality of Service
3.1.2.7.1 The Road to Multicasting
3.1.2.7.1.1 Basics of Multicasting
3.1.2.7.1.2 Types of Multicasting Applications
3.1.2.7.2 Multicasting
3.1.2.7.2.1 Multicast Backbone on the Internet (MBONE)
3.1.2.7.2.2 IP Multicast Transport
3.1.2.7.2.3 Multicast Routing
3.1.2.7.2.4 Multicast Address Resolution Server (MARS)
3.1.2.7.3 Designing a Multicasting Network
3.1.2.7.4 Quality of Service
3.1.2.7.4.1 Transport for New Applications
3.1.2.7.4.2 Quality of Service for IP Networks
3.1.2.7.4.3 Resource Reservation Protocol (RSVP)
3.1.2.7.4.4 Multiprotocol Label Switching (MPLS)
3.1.2.7.4.5 Differentiated Services
3.1.2.7.5 Congestion Control
3.1.2.7.5.1 First-In-First-Out (FIFO)
3.1.2.7.5.2 Priority Queuing
3.1.2.7.5.3 Weighted Fair Queuing (WFQ)
3.1.2.7.6 Implementing QoS
3.1.2.8 Internetwork Design Study
3.1.2.8.1 Small Sized Network (≤80 Users)
3.1.2.8.1.1 Connectivity Design
3.1.2.8.1.2 Logical Network Design
3.1.2.8.1.3 Network Management
3.1.2.8.1.4 Addressing
3.1.2.8.1.5 Naming
3.1.2.8.1.6 Connecting the Network to the Internet
3.1.2.8.2 Medium Size Network (≤500 Users)
3.1.2.8.2.1 Connectivity Design
3.1.2.8.2.2 Logical Network Design
3.1.2.8.2.3 Addressing
3.1.2.8.2.4 Naming
3.1.2.8.2.5 Remote Access
3.1.2.8.2.6 Connecting the Network to the Internet
3.1.2.8.3 Large Size Network (≥500 Users)
3.1.2.8 Internetwork Design Study

3.1.2.1 Introduction

We have seen dramatic changes in the business climate in the 1990s, especially with the growth of e-business on the Internet. More business is conducted electronically and deals are closed in lightning speed. These changes have affected how a company operates in this electronic age and computer systems have taken a very important role in a company’s profile. The Internet has introduced a new turf for companies to compete and more companies are going global at the same time to grow revenues. Connectivity has never been as important as it is today.

The growth of the Internet has reached a stage where a company has to get connected to it in order to stay relevant and compete. The traditional text-based transaction systems have been replaced by Web-based applications with multimedia contents. The technologies that are related to the Internet have become mandatory subjects not only for MIS personnel, but even the CEO. And TCP/IP has become a buzzword overnight.

3.1.2.1.1 The Internet Model

It has been estimated that there are currently 40,000,000 hosts connected to the Internet. The rapid rise in popularity of the Internet is mainly due to the World Wide Web (WWW) and e-mail systems that enable free exchanges of information. A cursory glance at the history of the Internet and its growth enables you to understand the reason for its popularity and perhaps, predict some trend towards how future networks should be built.

3.1.2.1.1.1 A Brief History of the Internet and IP Technologies

In the 1960s and 1970s, many different networks were running their own protocols and implementations. Sharing of information among these networks soon became a problem and there was a need for a common protocol to be developed. The Defense Advanced Research Projects Agency (DARPA) funded the exploration of this common protocol and the ARPANET protocol suite, which introduced the fundamental concept of layering. The TCP/IP protocol suite then evolved from the ARPANET protocol suite and took its shape in 1978. With the use of TCP/IP, a network was created that was mainly used by government agencies and research institutes for the purpose of information sharing and research collaboration.

In the early 1980s TCP/IP became the backbone protocol in multivendor networks such as ARPANET, NFSNET and regional networks. The protocol suite was integrated into the University of California at Berkeley′ s UNIX operating system and became available to the public for a nominal fee. From this point on TCP/IP became widely used due to its inexpensive availability in UNIX and its spread to other operating systems.

Today, TCP/IP provides the ability for corporations to merge differing physical networks while giving users a common suite of functions. It allows interoperability between equipment supplied by multiple vendors on multiple platforms, and it provides access to the Internet.

The Internet of today consists of large international, national and regional backbone networks, which allow local and campus networks and individuals access to global resources. Use of the Internet has grown exponentially over the last three years, especially with the consumer market adopting it.

So why has the use of TCP/IP grown at such a rate?

The reasons include the availability of common application functions across differing platforms and the ability to access the Internet, but the primary reason is that of interoperability. The open standards of TCP/IP allow corporations to interconnect or merge different platforms. An example is the simple case of allowing file transfer capability between an IBM MVS/ESA host and, perhaps, an Apple Macintosh workstation.

TCP/IP also provides transport for other protocols such as IPX, NetBIOS or SNA. For example, these protocols could make use of a TCP/IP network to connect to other networks of similar protocol.

One further reason for the growth of TCP/IP is the popularity of the socket programming interface, which is the programming interface between the TCP/IP transport protocol layer and TCP/IP applications. A large number of applications today have been written for the TCP/IP socket interface. The Request for Comments (RFC) process, overseen by the Internet Architecture Board (IAB) and the Internet Engineering Task Force (IETF), provides for the continual upgrading and extension of the protocol suite.

3.1.2.1.1.2 The Open Systems Interconnection (OSI) Model

Around the time that DARPA was researching into an internetworking protocol suite, which eventually led to TCP/IP and the Internet (see 1.1.1, “A Brief History of the Internet and IP Technologies” on page 1), an alternative standard approach was being led by the CCITT (Comité Consultatif International Telegraphique et Telephonique, or Consultative Committee on International Telegraph and Telephone), and the ISO (International Organization for Standardization). The CCITT has since become the ITU-T (International Telecommunication Union - Telecommunication).

The resulting standard was the OSI (Open Systems Interconnection) Reference Model (ISO 7498), which defined a seven-layer model of data communications, as shown in Figure 1 on page 3. Each layer of the OSI Reference Model provides a set of functions to the layer above and, in turn, relies on the functions provided by the layer below. Although messages can only pass vertically through the stack from layer to layer, from a logical point of view, each layer communicates directly with its peer layer on other nodes.

The seven layers are:

Application

The application layer gives the user access to all the lower OSI functions, and its purpose is to support semantic exchanges between applications existing in open systems. An example is the Web browser.

Presentation

The presentation layer is concerned with the representation of user or system data. This includes necessary conversations (for example, a printer control character), and code translation (for example, ASCII to EBCDIC).

Session

The session layer provides mechanisms for organizing and structuring interaction between applications and/or devices.

Transport

The transport layer provides transparent and reliable end-to-end data transfer, relying on lower layer functions for handling the peculiarities of the actual transfer medium. TCP and UDP are examples of a Transport layer protocol.

Network

The network layer provides the means to establish connections between networks. The standard also includes procedures for the operational control of internetwork communications and for the routing of information through multiple networks. The IP is an example of a Network layer protocol.

Data Link

The data link layer provides the functions and protocols to transfer data between network entities and to detect (and possibly correct) errors that may occur in the physical layer.

Physical

The physical layer is responsible for physically transmitting the data over the communication link. It provides the mechanical, electrical, functional and procedural standards to access the physical medium.

The layered approach was selected as a basis to provide flexibility and open-ended capability through defined interfaces. The interfaces permit some layers to be changed while leaving other layers unchanged. In principle, as long as standard interfaces to the adjacent layers are adhered to, an implementation can still work.

3.1.2.1.1.3 The TCP/IP Model

While the OSI protocols developed slowly, due mainly to their formal committee-based engineering approach, the TCP/IP protocol suite rapidly evolved and matured. With its public Request for Comments (RFC) policy of improving and updating the protocol stack, it has established itself as the protocol of choice for most data communication networks.

As in the OSI model and most other data communication protocols, TCP/IP consists of a protocol stack, made up of four layers.

The layers of the TCP/IP protocol are:

Application Layer

The application layer is provided by the user’s program that uses TCP/IP for communication. Examples of common applications that use TCP/IP are Telnet, FTP, SMTP, and Gopher. The interfaces between the application and transport layers are defined by port numbers and sockets.

Transport Layer

The transport layer provides the end-to-end data transfer. It is responsible for providing a reliable exchange of information. The main transport layer protocol is the Transmission Control Protocol (TCP). Another transport layer protocol is User Datagram Protocol (UDP), which provides a connectionless service in comparison to TCP, which provides a connection-oriented service. That means that applications using UDP as the transport protocol have to provide their own end-to-end flow control. Usually, UDP is used by applications that need a fast transport mechanism.

Internetwork Layer

The internetwork layer, also called the internet layer or the network layer, separates the physical network from the layers above it. The Internet Protocol (IP) is the most important protocol in this layer. It is a connectionless protocol that doesn't assume reliability from the lower layers. IP does not provide reliability, flow control or error recovery. These functions must be provided at a higher level, namely the transport layer if using TCP or the application layer if using UDP.

A message unit in an IP network is called an IP datagram. This is the basic unit of information transmitted across TCP/IP networks. IP provides routing functions for distributing these datagrams to the correct recipient for the protocol stack. Other internetwork layer protocols are ICMP, IGMP, ARP and RARP.

Network Interface Layer

The network interface layer, also called the link layer or the data link layer, is the interface to the actual network hardware. This layer does not guarantee reliable delivery; that is left to the higher layers, and may be packet or stream oriented.

TCP/IP does not specify any particular protocol for this layer. It can use almost any network interface available making it a flexible network while providing backwards compatibility with legacy infrastructure. Examples of supported network interface protocols are IEEE 802.2, X.25 (which is reliable in itself), ATM, FDDI and even SNA.

3.1.2.1.1.4 The Need for Design in IP Networks

If you do not take time to plan your network, the ease of interconnection through the use of TCP/IP can lead to problems. The purpose of this book is to point out some of the problems and highlight the types of decisions you will need to make as you consider implementing a TCP/IP solution.

For example, lack of effective planning of network addresses may result in serious limitations in the number of hosts you are able to connect to your network. Lack of centralized coordination may lead to duplicate resource names and addresses, which may prevent you from being able to interconnect isolated networks. Address mismatches may prevent you from connecting to the Internet, and other possible problems may include the inability to translate resource names to resource addresses because connections have not been made between name servers.

Some problems arising from a badly designed or an unplanned network are trivial to correct. Some, however, require significant time and effort to correct. Imagine manually configuring every host on a 3000-host network because the addressing scheme chosen no longer fits a business’ needs!

When faced with the task of either designing a new TCP/IP network or allowing existing networks to interconnect, there are several important design issues that will need to be resolved. For example, how to allocate addresses to network resources, how to alter existing addresses, whether to use static or dynamic routing, how to configure your name servers and how to protect your network are all questions that need to be answered. At the same time the issues of reliability, availability and backup will need to be considered, along with how you will manage and administer your network.

The following chapters will discuss these and other concerns, and provide the information you need to make your decisions. Where possible we will provide general guidelines for IP network design rather than discussing product-specific or platform-specific considerations. This is because the product-specific documentation in most cases already exists and provides the necessary details for configuration and implementation. We will not attempt to discuss TCP/IP applications in any depth due to the information also being available to you in other documents.

3.1.2.1.1.5 Designing an IP Network

Due to the simplicity and flexibility of IP, a network can be "hacked" together in an unordered fashion. It is common for a network to be connected in this manner, and this may work well for small networks. The problem arises when changes are required and documentation is not found. Worst of all, if the network design/implementation teams leave the organization, the replacements are left with the daunting task of finding out what the network does, how it fits together, and what goes where!

An IP network that has not been designed in a systematic fashion will invariably run into problems from the beginning of the implementation stage. When you are upgrading an existing network, there are usually legacy networks that need to be connected. Introducing of new technology without studying the limitations of the current network may lead to unforeseen problems. You may end up trying to solve a problem that was created unnecessarily. For example, the introduction of an Ethernet network in a token-ring environment has to be carefully studied.

The design of the network must take place before any implementation takes place. The design of the IP network must also be constantly reviewed as requirements change over time.

A good IP network design also includes detailed documentation of the network for future reference. A well designed IP network should be easy to implement, with few surprises. It is always good to remember the KISS principle: Keep It Simple, Stupid!

3.1.2.1.1.5.1 The Design Methodology

The design methodology recommended for use in the design of an IP network is a top-down design approach.

This technique of design loosely follows the TCP/IP stack. As seen in Figure 2 on page 4, at the top of the stack lies the application layer. This is the first layer considered when designing the IP network. The next two layers are the transport and network layers with the final layer being the data link layer.

The design of an application is dictated by business requirements. The rules of the business, the process flow, the security requirements and the expected results all get translated into the application’s specification. These requirements not only affect the design of the application but their influence permeates all the way down to the lower layers.

Once the application layer requirements have been identified, the requirements for the lower layers follow. For example, if the application layer has a program that demands a guaranteed two-second response time for any network transaction, the IP network design will need to take this into consideration and maybe place performance optimization as high priority. The link layer will need to be designed in such a manner that this requirement is met. Using a flat network model for the link layer with a few hundred Windows-based PCs may not be an ideal design in this case.

Once the design of the IP network has been completed with regard to the application layer, the implementation of the network is carried out.

The design for the network infrastructure plays an important part, as it ultimately affects the overall design. A good example of this is the modularity and scalability of the overall IP network. The following are some basic considerations in designing an IP network.

3.1.2.1.1.5.2 Overall Design Considerations

There are a few major points that you need to know:

3.1.2.1.1.5.3 Network Design Steps

Network Objectives

What are the objectives of this IP network? What are the business requirements that need to be satisfied? This step of the design process needs research and can be time consuming. The following, among other things, should be considered:

Collecting Design Information

The information that is required for building the network depends on each individual implementation. However, the main types of information required can be deduced from Part 1.1.5.2, “Overall Design Considerations” on page 8.

It is important to collect this information and spend time analyzing it to develop a thorough understanding of the environment and limitations imposed upon the design of the new IP network.

Create a Proposal or Specification

Upon analysis of the collected information and the objectives of the network, a design proposal can be devised and later optimized. The design considerations can be met with one goal overriding others. So the network can be:

Once the design priorities have been identified the design can be created and documented.

Review

The final stage in the design process is to review the design before it is implemented. The design can be modified at this stage easily, before any investment is made into infrastructure or development work. With this completed, the implementation stage can be initiated.

3.1.2.1.2 Application Considerations

As presented in chapter one, the TCP/IP model’s highest layer is the application layer. As the elements that populate this layer are defined by the business requirements of the overall system, these components must be considered the most important in the initial design considerations with a top-down design methodology.

The type of applications that the network needs to support and the types of network resources these applications require, must be taken into consideration when designing the IP network. There are a number of these issues that must be considered for the network design, some that are common to all applications, while others pertain to a subset of applications. These issues will be defined and elaborated.

Remember, building a complex ATM network to send plain text in a small workgroup of 10 users is a waste of time and resources, unless you get them for free!

3.1.2.1.2.1 Bandwidth Requirements

Different applications require varying amounts of network bandwidth. A simple SMTP e-mail application does not have the same bandwidth requirement as a Voice over IP application. Voice and data compression have not reached that level yet.

It is obvious that the applications your network will need to support determine the type of network you will finally design. It is not a good idea to design a network without considering what applications you currently require, and what applications your business needs will require your network to support in the future.

3.1.2.1.2.2 Performance Requirements

The performance requirements of the users of the applications must be considered. A user of the network may be willing to wait for a slow response from an HTTP or FTP application, but they will not accept delays in a Voice over IP application - it’s hard to understand what someone is saying when it’s all broken up.

The delay in the delivery of network traffic also needs to be considered. Long delays will not be acceptable to applications that stream data, such as video over IP applications.

The accuracy with which the network is able to provide data to the application is also relevant to the network design. Differing infrastructure designs provide differing levels of accuracy from the network.

3.1.2.1.2.3 Protocols Required

The TCP/IP application layer supports an ever increasing number of protocols.

The basic choice in protocol for applications is whether or not the application will use TCP or UDP. TCP delivers a reliable connection-oriented service. UDP delivers faster network response by eliminating the overhead of the TCP header however, it loses TCP’s reliability, flow control and error recovery features.

It is clear that it depends on the application’s service focus as to which protocol it will use. An FTP application, for example, will not use UDP. FTP uses TCP to provide reliable end-to-end connections. The extra speed provided by using UDP does not outweigh the reliability offered by TCP.

The Trivial File Transfer Protocol (TFTP), however, although similar to FTP, is based on a UDP transport layer. As TFTP transactions are generally small in size and very simple, the reliability of the TCP protocol is outweighed by the added speed provided by UDP. Then why use FTP? Although TFTP is more efficient than FTP over a local network, it is not good for transfers across the Internet as its speed is rendered ineffective due to its lack of reliability. Unlike FTP applications TFTP applications are also insecure.

3.1.2.1.2.4 Quality of service/Type of Service (QoS/ToS)

Quality of Service (QoS) and Type of Service (ToS) arise simply for one reason.

Some users’ data is more "important" then others. And there is a need to provide these users with "premium" service, just like a VIP queue at the airport.

The requirement for QoS and ToS that gets incorporated into an application also has implications for the network design. The connecting devices, the routers and switches, have to be able to ensure "premium" delivery of information so as to support the requirement of the application.

3.1.2.1.2.4.1 Real-Time Applications

Some applications, such as a Voice over IP or an ordering system, need to be real time. The need for real-time applications necessitates a network that can guarantee a level of service.

A real-time application will need to implement its own flow control and error checking if it is to use UDP as a transport protocol. The requirements of real-time applications will also influence the type of network infrastructure implemented. An ATM network can inherently fulfill the requirements, however, a shared Ethernet network will not fulfill the requirement.

3.1.2.1.2.5 Sensitivity to Packet Loss and Delay

An application’s sensitivity to packet loss and delay can have dramatic effects on the user. The network must provide reliable packet delivery for these applications.

For example, a real-time application, with little buffering, does not tolerate packet delivery delays, let alone packet loss! Voice over IP is one example of such an application, as opposed to an application such as Web browsing.

3.1.2.1.2.6 Multicast

Multicasting has been proven to be a good way of saving network bandwidth. That is true, if it has been implemented properly and did not break the network in the first place.

Getting multicasting to work involves getting all the connecting devices, such as routers and switches, the applications, the clients’ operating systems, and the servers to work hand in hand. Multicasting will not work if any of these subsystems cannot meet the requirement, or if they have severe limitations.

3.1.2.1.2.7 Proxy-Enabled

The ability of an application protocol to be proxyed has implications on the bandwidth requirements and the security of the network.

An HTTP application will be easily manageable when a firewall is installed for security, as a proxy service can be placed outside the firewall in a demilitarized zone to serve HTTP traffic through the firewall to the application.

An application based upon the TELNET protocol will not have such an easy time as the HTTP application. The TELNET protocol does not support proxying of its traffic. Thus, a firewall must remain open on this port, the application must use a SOCKS server or the application cannot communicate through the firewall. You either have a nonworking application, an added server or a security hole.

3.1.2.1.2.8 Directory Needs

Various applications require directory services with the IP network. Directory services include DNS, NIS, LDAP, X.500 and DCE, among others. The choice of Directory services depends on the application support for these services. An application based upon the ITU X.500 standard will not respond well to a network with only DNS servers.

Some applications, such as those based upon the PING and TFTP protocols, do not require directory services to function, although the difficulty in their use would be greatly increased. Other applications require directory services implicitly, such as e-mail applications based on the SMTP protocol.

3.1.2.1.2.9 Distributed Applications

Distributed applications will require a certain level of services from the IP network. These services must be catered for by the network, so they must be considered in the network design.

Take Distributed Computing Environment (DCE) as an example. It provides a platform for the construction and use of distributed applications that relies on services such as remote procedure call (RPC), the Cell Directory Service (CDS), Global Directory Service (GDS), the Security Service, DCE Threads, Distributed Time Service (DTS), and Distributed File Service (DFS). These services have to made available through the network, so that collectively, they provide the basic secure core for the DCE environment.

3.1.2.1.2.10 Scalability

Applications that require scalability must have a network capable to cater for their future requirements, or be able to be upgraded for future requirements. If an application is modular in design, the network must also be modular to enable it to scale linearly with the application’s requirements.

3.1.2.1.2.11 Security

The security of applications is catered for by the underlying protocols or by the application itself. If an application uses UDP for its transport layer, it cannot rely on SSL for security, hence it must use its own encryption and provide its own security needs.

Some applications that need to be run on the network do not have built-in security features, or have not implemented standard security concepts such as SSL. An application based on the TELNET protocol, for example, will invariably be unsecure. If the network security requirements are such that a TELNET application sending out unencrypted passwords is unacceptable, then either the TELNET port must be closed on the firewall or the application must be rewritten. Is it really worth rewriting your TELNET program?

3.1.2.1.3 Platform Considerations

An important step toward building an application is to find out the capabilities of the end user’s workstation - the platform for the application. Some of the basic questions that have to be answered include:

Of these questions, features and performance criteria are easy to understand and information is readily obtainable. The connectivity option is a difficult one to handle because it can involve many fact findings, some of which may not be easily available. Many times, these tasks are learned through painful experience. Take for example, the following questions that may need to be answered if we want to develop an application that runs on TCP/IP:

Depending on the type of application, the above questions may not be relevant, but they are definitely not exhaustive. You may say the above questions are trivial and unimportant, but the impact could be far more reaching than just merely the availability of functions. Here’s why:

3.1.2.1.4 Infrastructure Considerations

The applications need a transport mechanism to share information, to transmit data or to send requests for some services. The transport mechanism is provided by the underlying layer called the network infrastructure.

Building a network infrastructure can be a daunting task for the inexperienced. Imagine building a network for a company with 100,000 employees and 90 different locations around the world. How do you go about building it? And where do you begin?

As in the application consideration, building a network infrastructure involves many decision making processes:

The Internet as we have it today grew out of circumstances. In the beginning, it was not designed to be what it is today. In fact, there was not any planning or design work done for it. It is merely a network of different networks put together, and we have already seen its problems and limitations:

Work has begun on building the so-called New Generation Internet (NGI) and it is supposed to be able to address most, if not all, of the problems that we are experiencing with the Internet today. The NGI will be entirely different from what we have today, as it is the first time that a systematic approach has been used to design and build an Internet.

3.1.2.1.5 The Perfect Network

So, you may ask: Is there such a thing as a perfect network?

If a network manager is assigned to build a network for a company, he/she would have to know how to avoid all the problems we have mentioned above. He or she would use the best equipment and would have chosen the best networking technologies available, but may still not have built a perfect network. Why?

The truth is, there is no such thing as a perfect network. A network design that is based on today’s requirements may not address those of the future. Business environments change, and this has a spiraling effect on the infrastructure. Expectations of employees change, the users’ requirements change, and new needs have to be addressed by the applications, and these in turn affect how all the various systems tie up together, which means there is a change in the network infrastructure involved. At best, what the network could do is to scale and adapt to changes. Until the day it has reached its technical limitation, these are the two criteria for a network to stay relevant; after that, a forklift operation may be required.

Networks evolve over time. They have to do so to add value.

The above sections have highlighted that much work has to be done before an application gets to be deployed to support a business’ needs. From the network infrastructure to the various system designs, server deployments, security considerations and types of client workstations, they all have to be well coordinated. A minor error could mean back to the drawing board for the system designer, and lots of money for the board of directors.

3.1.2.2 The Network Infrastructure

The network infrastructure is an important component in IP network design. It is important simply because, at the end of the day, it is those wires that carry the information. A well thought-out network infrastructure not only provides reliable and fast delivery of that information, but it is also able to adapt to changes, and grow as your business expands.

Building a network infrastructure is a complex task, requiring work such as information gathering, planning, designing, and modeling. Though it deals mainly with bits and bytes, it is more of an art than a science, because there are no fast rules to building one.

When you build a network infrastructure, you look more at the lower three layers of the OSI model, although many other factors need to be considered. There are many technologies available that you can use to build a network, and the challenge that a network manager faces, is to choose the correct one and the tool that comes with it. It is important to know the implications of selecting a particular technology, because the network manager ultimately decides what equipment is required. When selecting a piece of networking equipment, it is important to know at which layer of the OSI model the device functions. The functionality of the equipment is important because it has to conform to certain standards, it has to live up to the expectation of the application, and it has to perform tasks that are required by the blue print - the network architecture.

The implementation of IP over different protocols depends on the mechanism used for mapping the IP addresses to the hardware addresses, or MAC address, at the data link layer of the OSI model. Some important aspects to consider when using IP over any data link protocol are:

Another parameter that should be considered in the IP implementation over different data link layer protocols is the maximum transmission unit (MTU) size. MTU size refers to the size of the data frame (in bytes) that has to be transmitted to the destination through the network. A bigger MTU size means one can send more information within a frame, thus requiring a lower total number of packets to transmit a piece of information.

Different data link layers have different MTU sizes for the operation of the network. If you connect two networks with different MTU sizes, then a process called fragmentation takes place and this has to be performed by an external device, such as a router. Fragmentation takes a larger packet and breaks it up into smaller ones so that it can be sent onto the network with a smaller MTU size. Fragmentation slows down the traffic flow and should be avoided as much as possible.

3.1.2.2.1 Technology

Besides having wires to connect all the devices together, you have to decide the way these devices connect, the protocol in which the devices should talk to each other. Various technologies are available, each different from one another in standards and implementation.

In this section, a few popular technologies are covered with each of their characteristics highlighted. These technologies cover the LAN, WAN as well as the remote access area.

3.1.2.2.1.1 The Basics

It is important to understand the fundamentals of how data is transmitted in an IP network, so that the difference in how the various technologies work can be better understood.

Each workstation connects to the network through a network interface card (NIC) that has a unique hardware address. At the physical layer, these workstations communicate with each other through the hardware addresses. IP, being a higher level protocol in the OSI model, communicates through a logical address, which in this case, is the IP address. When one workstation with an IP address of 10.1.1.1 wishes to communicate with another with the address 10.1.1.2, the NIC does not understand these logical addresses. Some mechanism has to be implemented to translate the destination address 10.1.1.2 to a hardware address that the NIC can understand.

2.1.1.1 Broadcast versus Non-Broadcast Network

Generally, all networks can be grouped into two categories: broadcast and non-broadcast. The mechanism for mapping the logical address to the hardware address is different for these two groups of networks. The best way of describing a broadcast network is to imagine a teacher teaching a class. The teacher talks and every student listens. An example of a non-broadcast network would be a mail correspondence - at any time, only the sender and receiver of the mail know what the conversation is about, the rest of the people don’t. Examples of broadcast networks are Ethernet, token-ring and FDDI, while examples of non-broadcast networks are frame relay and ATM.

It is important to differentiate the behaviors of both broadcast and non-broadcast networks, so that the usage and limitation can both be taken into consideration in the design of an IP network.

2.1.1.2 Address Resolution Protocol (ARP)

In a broadcast network, the Address Resolution Protocol (ARP) is used to translate the IP address to the hardware address of the destination host. Every workstation that runs the TCP/IP protocol keeps a table, called an ARP cache, containing the mapping of the IP address to the hardware address of the hosts with which it is communicating. When a destination entry is not found in the ARP cache, a broadcast, called ARP broadcast, is sent out to the network. All workstations that are located within the same network will receive this request and go on to check the IP address entry in the request. If one of the workstations recognizes its own IP address in this request, it will proceed to respond with an ARP reply, indicating its hardware address. The originating workstation then stores this information and commences to send data through the newly learned hardware address.

ARP provides a simple and effective mechanism for mapping an IP address to a hardware address. However, in a large network, especially in a bridged environment, a phenomenon known as a broadcast storm can occur if workstations misbehave, assuming hundreds of workstations are connected to a LAN, and ARP is used to resolve the address mapping issue. If the workstation’s ARP cache is too small, it means the workstation has to send more broadcasts to find out the hardware address of the destination. Having hundreds of workstations continuously sending out ARP broadcasts would soon render the LAN useless because nobody can send any data.

2.1.1.3 Proxy ARP

The standard ARP protocol does not allow the mapping of hardware addresses between two physically separated networks that are interconnected by a router. In this situation, when one is having a combination of new workstations and older workstations that do not support the implementation of subnetting, ARP will not work.

Proxy ARP or RFC 1027, is used to solve this problem by having the router reply to an ARP request with its own MAC address on behalf of the workstations that are located on the other side of the router. It is useful in situations when multiple LAN segments are required to share the same network number but are connected by a router. This can happen when there is a need to reduce broadcast domains but the workstation’s IP address cannot be changed. In fact, some old workstations may still be running an old implementation of TCP/IP that does not understand subnetting.

A potential problem can arise though, and that is when the Proxy ARP function is turned on in a router by mistake. This problem would manifest itself when displays of the ARP cache on the workstations show multiple IP addresses all sharing the same MAC addresses.

2.1.1.4 Reverse Address Resolution Protocol (RARP)

Some workstations, especially diskless workstations, do not know their IP address when they are initialized. A RARP server in the network has to inform the workstation of its IP address when an RARP request is sent by the workstation. RARP will not work in a non-broadcast network.

Typically in a non-broadcast network, workstations communicate in a one-to-one manner. There is no need to map a logical address to a hardware address because they are statically defined. Most of the WAN protocols can be considered as non-broadcast.

2.1.2 LAN Technologies

There are a few LAN technologies that are widely implemented today. Although they may have been invented many years ago, they have all been proven reliable and stood the test of time.

2.1.2.1 Ethernet/IEEE 802.3

Today, Ethernet LAN is the most popular type of network in the world. It is popular because it is easy to implement, and the cost of ownership is relatively lower than that of other technologies. It is also easy to manage and the Ethernet products are readily available.

The technology was invented by Xerox in the 1970s and was known as Ethernet V1. It was later modified by a consortium made up of Digital, Intel and Xerox, and the new standard became Ethernet (DIX) V2. This was later rectified by the IEEE, to be accepted as an international standard, with slight modification, and hence, IEEE 802.3 was introduced.

The Ethernet LAN is an example of a carrier sense multiple access with collision detection (CSMA/CD) network, that is, members of a same LAN transmit information at random and retransmit when collision occurs. The CSMA/CD network is a classic example of a broadcast network because all workstations "see" all information that is transmitted on the network.

The chance of a collision depends on the following:

Therefore, one important aspect of Ethernet LAN design is to ensure an adequate number of workstations per network segment, so that the length of the network does not exceed what the standard specifies, and that the correct frame size is used. While a larger frame means that a fewer number of them is required to transmit a single piece of information, it can mean that there is a greater chance of collisions. On the other hand, a smaller frame reduces the chance of a collision, but it then takes more frames to transmit the same piece of information.

It was mentioned earlier that the Ethernet and IEEE 802.3 standards are not the same. The difference lies in the frame format, which means workstations configured with Ethernet will not be able to communicate with workstations that have been configured with IEEE 802.3.

To implement Ethernet, network managers need to follow certain rules, and it can very much tie in with the type of cables being used. Ethernet can be implemented using coaxial (10Base5 or 10Base2), fiber optic (10BaseF) or UTP Category 3 cables (10BaseT). These different cabling types impose different restrictions and it is important to know the difference. Also, Ethernet generally follows the 5-4-3 rule. That is, in a single collision domain, there can be only five physical segments, connected by four repeaters. No two communicating workstations can be separated by more than three segments. The other two segments must be a link segment, that is, with no workstations attached to them.

Although it was once thought that Ethernet would not scale and thus would be replaced by other better technologies, vendors have made modifications and improvements to its delivery capabilities to make it more efficient.

The Ethernet technology has evolved from the traditional 10 Mbps network to the 100 Mbps network or Fast Ethernet, and now to the 1 Gbps network, or better known as Gigabit Ethernet.

The Fast Ethernet, or the IEEE 802.3u standard, is 10 times faster than the 10 Mbps Ethernet. The cabling used for Fast Ethernet is 100BaseTx, 100BaseT4 and the 100BaseFx. The framing used in Fast Ethernet is the same as that used in Ethernet. Therefore it is very easy for network managers to upgrade from Ethernet to Fast Ethernet. Since the framing and size are the same as that of Ethernet and yet the speed has been increased 10 times, the length of the network now has to be greatly reduced, or else the collision would not be detected and would cause problems to the network.

The Gigabit Ethernet, or IEEE 802.3z standard, is 10 times faster than the Fast Ethernet. The framing used is still the same as that of Ethernet, and thus reduces the network distance by a tremendous amount as compared to the Ethernet. Gigabit Ethernet is usually connected using the short wavelength (1000BaseSx) or the long wavelength (1000BaseLx) fiber optic cables, although the standard for the UTP (1000BaseT) is available now. The distance limitation has been resolved with the new fiber optic technologies. An offering called the Jumbo Frame implements a much larger frame size, but its use has been a topic of hot debate for network managers. Nonetheless, vendors are beginning to offer the Jumbo Frame feature in their products.

Gigabit Ethernet is mainly used for creating high speed backbones, a simple and logical choice for upgrading current Fast Ethernet backbones.

Note: It is generally agreed that the maximum "usable" bandwidth for Ethernet LAN is about 40%, after which the effect of collision is so bad that efficiency actually begins to drop.

Besides raw speed improvement, new devices such as switches now provide duplex mode operation, which allows workstations to send and receive data at the same time, effectively doubling the bandwidth for the connection. The duplex mode operation requires a Category-5 UTP cable, with two pairs of wire used for transmitting and receiving data. Therefore, the operation of duplex mode may not work on old networks because they usually run on Category-3 UTP cables.

Most of the early Ethernet workstations are connected to the LAN at 10 Mbps because they were implemented quite some time ago. It is still popular as the network interface card and 10 Mbps hubs are very affordable. At this point, it is important to note that in network planning and design, more bandwidth or a faster network does not mean that the user will benefit from the speed. Due to the development of higher speed networks such as Fast Ethernet and Gigabit Ethernet, a 10 Mbps network seems to have become less popular now. The fact is, it can still carry a lot of information and a user may not be able to handle the information if there is anymore available. With the introduction of switches that provides dedicated 10 Mbps connection to each individual user, this has become even more true.

Giving a user a 100 Mbps connection may not mean it would be utilized adequately. A 10 Mbps connection is still a good solution to use for its cost effectiveness. This may be a good option to meet certain budget constrains, while keeping an upgrade option open for the future.

Nowadays, with card vendors manufacturing mostly 10/100Mbps Ethernet cards, more and more workstations have the option of connecting to the network at 100Mbps. The Gigabit Ethernet is a new technology and it is positioned to be a backbone technology rather than being used to connect to the end users. As standards evolve, Gigabit Ethernet will see widespread usage in the data center and most of the servers that connect to the network at 100 Mbps today will eventually move to a Gigabit Ethernet.

Ethernet is a good technology to deploy for a low volume network or application that does not demand high bandwidth. Because it does not have complicated access control to the network, it is simple and can provide better efficiency in delivery of data. Due to its indeterministic nature of collision, response time in an Ethernet cannot be determined and hence, another technology has to be deployed in the event that this is needed.

Although Ethernet technology has been around for quite some time, it will be deployed for many years to come because it is simple and economical. Its plug-and-play nature allows it to be positioned as a consumer product and users require very little training to se up an Ethernet LAN. With the explosion of Internet usage and e-commerce proliferating, more companies, especially the small ones and the small office, home office (SoHo) establishment, will continue to drive the demand for Ethernet products.

2.1.2.2 Token-Ring/IEEE 802.5

The token-ring technology was invented by IBM in the 1970s and it is the second most popular LAN architecture. It supports speeds of 1, 4 or 16 Mbps. There is a new technology, called the High-Speed Token-Ring being developed by the IEEE and it will run at 100 Mbps.

The token-ring LAN is an example of a token-passing network, that is, members of the LAN transmit information only when they get hold of the token. Since the transmission of data is decided by the control of the token, a token-ring LAN has no collision.

As described, the token passing technique is different from Ethernet’s random manner of access. This important feature makes a token-ring LAN deterministic and allows delays to be determined. Besides this difference, token-ring also offers extensive network diagnostics and self-recovery features such as:

It is not surprising that with such extensive features, token-ring adapters are more expensive than the Ethernet ones because all of these functions are implemented in the adapter microcode.

The token-ring LAN is particularly stable and efficient even under high load conditions. The impact of an increase in the number of workstations on the same LAN does not affect token-ring as much as it would Ethernet. It guarantees fair access to all workstations on the same LAN and is further enhanced with an eight-level priority mechanism. With extensive features like self recovery and auto configuration at the electrical level, the token-ring LAN is the network of choice for networks that require reliability and predictable response times. Networks such as factory manufacturing systems and airline reservation systems typically use token-ring LANs for these reasons.

2.1.2.3 Fiber Distributed Digital Interface (FDDI)

FDDI was developed in the early 1980s for high speed host connections but it soon became a popular choice for building LAN backbones. Similar to the token-ring LAN, FDDI uses a token passing method to operate but it uses two rings, one primary and one secondary, running at 100 Mbps. Under normal conditions, the primary ring is used while the secondary is in a standby mode.

FDDI provides flexibility in its connectivity and redundancy and offers a few ways of connecting the workstations, one of which is called the dual attachment station ring.

In a dual attachment station ring, workstations are called Dual Attachment Stations (DAS).

It is easy to note the robustness of FDDI and appreciate its use in a high availability network. Since it is similar in nature to token-ring, FDDI offers capabilities such as self recovery and security. Because it mostly runs on fiber, it is not affected by electromagnetic interference. Due to its robustness and high speed, FDDI was being touted as the backbone of choice. But with the development of 100 Mbps Ethernet technology, network managers who are going for bandwidth rather than reliability have chosen to implement 100 Mbps Ethernet rather than FDDI.

Though it may not be as popular as Ethernet or token-ring, one can still find many networks operating on FDDI technology.

2.1.2.4 Comparison of LAN Technologies

It is appropriate, at this point, to compare the various LAN technologies that we have discussed. These technologies are the most popular ones deployed, each tend to be dominant in certain particular working environments.

Ethernet Token-Ring FDDI
Topology Bus Ring Dual Rings
Access Method CSMA/CD Token Passing Token Passing
Speed (in Mbps) 10/100/1000 1/4/16/100 100
Broadcast/Non- Broadcast Broadcast Broadcast Broadcast
Packet Size (Bytes) 64-1516 32-16K 32-4400
Self Recovery No Yes Yes
Data Path Redundancy No No Yes
Predictable Response Times No Yes Yes
Priority Classes No Yes Yes
Maximum Cable Length Yes Yes Yes
Cost of Deployment (relative to each other) Cheap Moderate Expensive
Typical Deployment Environment Small Offices, SoHo, Educational Institute, Most Corporate Offices, e-Commerce Airline, Manufacturing Floor, Banking, Most Mission-Critical Networks Backbone technology for medium and large networks

The above table shows the difference in characteristics of each of the technologies. From the comparisons, it shows that each of these technologies is more suitable than the rest for certain operating requirements.

The Ethernet technology tends to be deployed in networks where network response time is not critical to the functions of the applications. It is commonly found in educational institutes, mainly for its cost effectiveness, and e-commerce, for its simplicity in technical requirements. The token-ring is most suitable for networks that require predictable network response time. Airline reservation systems, manufacturing systems, as well as some banking and financial applications, have stringent network response time requirements. These networks tend to be token-ring, although there may be few exceptions. The FDDI is commonly deployed as a backbone network in a medium- to-large networks. It can be found in both an Ethernet or a token-ring environment. As mentioned, with the popularity of the Internet growing and the number of e-commerce setups is increasing at an enormous pace, Ethernet is the popular choice for building an IP network.

Thus, in deciding on which technology is most suitable for deployment, a network manager needs to ascertain the requirement carefully, and make the correct decision based on the type of environment he/she operates in, the type of applications to be supported, and the overall expectations of the end users.

2.1.3 WAN Technologies

WAN technologies are mainly used to connect networks that are geographically separated. For example, a remote branch office located in city A connecting to the central office in city B. Routers are usually used in WAN connectivity although switches may be deployed.

The requirements and choices of WAN technologies are different from LAN technologies. The main reason is that WAN technologies are usually a subscribed service offered by carriers, and they are very costly. WAN also differs from LAN technologies in the area of speed. While LAN technologies are running at megabits per second, the WANs are usually in kilobits per second. Also, WAN connections tend to be point-to-point in nature, while LAN is multiaccess.

The following table describes the differences between LAN and WAN technologies:

LAN WAN
Subscribed Service No Yes
Speed 4,10,16,100, 155, 622 Mbps, 1 Gbps 9.6, 14.4, 28.8, 56 64, 128, 256, 512 kbps 1.5, 2, 45, 155, 622 Mbps
Cost per kbps (relative to each other) Cheap Very expensive
Performance of major decision criteria Yes No
Cost of major decision criteria Maybe Yes
Cost of redundancy (as opposed to each) May be expensive Very expensive
Need specially trained personnel May not Definitely

It would seem obvious that the criteria for choosing a suitable WAN technology is different from that of a LAN. It is very much dependent on the choice of service offered by the carrier, the tariffs, the service quality of the carrier and availability of expertise.

2.1.3.1 Leased Lines

Leased lines are the most common way of connecting remote offices to the head office. It is basically a permanent circuit leased from the carrier and connects in a point-to-point manner.

The leased line technology has been around for quite some time and many network managers are familiar with it. With speed ranging from 64 kbps to as high as 45 Mbps, it usually runs protocol such as IP and IPX over a point-to-point protocol (PPP).

Routers are usually deployed to connect to leased lines to connect remote offices to a central site. A device called a data service unit/channel service unit (DSU/CSU) connects the router to the leased line, and for every leased line connection, a pair of DSU/CSU is required.

Due to its cost and the introduction of many other WAN technologies, network managers have begun to replace leased lines with some other technologies for reasons such as cost and features.

2.1.3.2 X.25

X.25 was developed by the carriers in the early1970s, and it allows the transport of data over a public data network service. The body that oversee its development is the International Telecommunication Union (ITU). Since ITU is made up of most of the telephone companies, this makes X.25 a truly international standard. X.25 is a classic example of a WAN protocol and a non-broadcast network.

The components that make up an X.25 network are:

X.25 end devices communicate just like how we use a telephone network. To initiate a communication path, called a virtual circuit , one workstation calls another and upon successful connection of the call, data begins to be transmitted. As opposed to the broadcast network, there is no facility such as ARP to map an IP address to an X.25 address. Instead, mappings are done statically and there is no broadcast required. In an X.25 network, there are two types of virtual circuit:

The encapsulation of IP over X.25 networks is described in RFC 1356. The RFC proposes larger X.25 maximum data packet size and the mechanism for encapsulating longer IP packets over the original draft.

When data is sent to an X.25 data communication equipment one or more virtual circuits are opened in the network to transmit it to the final destination. The IP datagrams are the protocol data units (PDUs) when the IP over X.25 encapsulation occurs. The PDUs are sent as X.25 complete packet sequences across the network. That is, PDUs begin on X.25 data packet boundaries and the M bit (more data) is used to fragment PDUs that are larger than one X.25 data packet.

There have been many discussions about performance in an X.25 network. The RFC 1356 specifies that every system must be able to receive and transmit PDUs up to 1600 bytes. To accomplish the interoperability with the original draft, RFC 877, the default value for IP datagrams should be 1500 bytes, and configurable in the range from 576 to 1600 bytes. This standard approach has been used to accomplish the default value of 1500-byte IP packets used in LAN and WAN environments so that one can avoid the router fragmentation process.

Typically, X.25 public data networks make use of low speed data links and a certain number of routes is incurred before data is transmitted to a destination. The way X.25 switches store the complete packet before sending it on the output link causes a longer delay with longer X.25 packets. If a small end-to-end window size is used, it also decreases the end-to-end throughput of the X.25 circuit. Fragmenting large IP packets in smaller X.25 packets can improve the throughput allowing a greater pipeline on the X.25 switches. Large X.25 packets combined over low speed links can also introduce higher packet latency. Thus, the use of larger X.25 packets will not increase the network performance but often it decreases it and some care should be taken in choosing the packet size.

It is also noted that some switches in the X.25 network will further fragment packets, so the performance of a link is also decided by the characteristics of the carrier’s network.

A different approach for increasing performance relies on opening multiple virtual channels, but this increases the delivering costs over the public data networks. However, this method can overcome problems introduced by the limitation of a small X.25 window size increasing the used shares of the available bandwidth.

The low speed performance of X.25 can sometimes pose problems for some TCP/IP applications that time out easily. In this manner, other connecting protocols would have to be deployed in place of X.25. With the advent of multiprotocol routers, you can find TCP/IP running on other WAN protocols while X.25 is used for other protocols. In fact, with the proliferation of TCP/IP networks, a new way transporting connections started to emerge: that of transporting X.25 networks across a TCP/IP network.

An example is the X.25 Transport Protocol (XTP) provided by the 221X Nways Multiprotocol routers family. This protocol works as a protocol forwarder, transferring the incoming X.25 packets to the final X.25 connection destination using the TCP/IP network. A common situation is depicted in the following diagram:

2.1.3.3 Integrated Services Digital Network (ISDN)

Integrated services digital network (ISDN) is a subscribed service offered by phone companies. It makes use of digital technology to transport various information, including data, voice and video, by using phone lines.

There are two types of ISDN interfaces, the basic rate interface (BRI) and the Primary Rate Interface (PRI). The BRI provides 2 x 64 kbps for data transmission (called the B channels) and 1 x 16 kbps for control transmission (called the D channel). The B channels are used as HDLC frame delimited 64 kbps pipes, while the D channel can also be used for X.25 traffic. The PRI provides T1 or E1 support. For T1, it supports 23 x 64 kbps B channels and 1 x 64 kbps D channel. The E1 supports 30 x 64 kbps for data and 1 x 64 kbps for control transmissions.

ISDN provides a "dial-on-demand" service that means a circuit is only connected when there is a requirement for it. The charging scheme of a fixed rate plus charges based on connections makes ISDN ideal for situations where a permanent connection is not necessary. It is especially attractive in situations where remote branches need to connect to the main office only for a batch update of records.

Another useful way of deploying ISDN is to act as a backup for a primary link. For example, a remote office may be connected to the central office through a leased line, with an ISDN link used as a backup. Under normal operation, traffic flows through the leased line and the ISDN link is idle. In the event of a leased line failure, the router at the remote site can use the ISDN connection to dial to the central office for connection.

X.31- Supports of X.25 over ISDN

The ITU standard X.31 is for transmitting X.25 packets over ISDN. This standard provides support for X.25 with unconditional notification on the ISDN BRI D channel.

X.31 is available from service providers in many countries. It gives the router a 9600 bps X.25 circuit. Since the D-channel is always present, this condition can be an X.25 PVC or SVC.

2.1.3.4 Frame Relay

Frame relay is a fast switching technique that can combine the use of fiber optic technologies (1.544 Mbps in the US and 2.048 Mbps in Europe) with the benefits of port sharing characteristics typical of networks such as X.25. The design point of frame relay is that networks are now very reliable and therefore leave the error checking to the DTE. Thus, frame relay does not perform link-level error checks and enjoys higher performance as compared to X.25.

The frame relay network consists of switches that are provided by the carrier and that are responsible for directing the traffic within the network to the final destination. The routers are connected to the frame relay network as terminal equipment, and connections are provided by standard-based interfaces.

The frame relay standards describe both the interface between the terminal equipment (router) and the frame relay network, called user-to-network interface (UNI), and the interface between adjacent frame relay networks, called network-to-network interface (NNI).

There are three important concepts in frame relay that you need to know:

It is interesting to note that although regarded as a non-broadcast network, frame relay supports the ARP protocol as well as the rest of TCP/IP routing protocols.

Frame Relay Congestion Management

Frame relay provides a mechanism to control and avoid congestion within the network. There are some basic concepts that need to be described:

The congestion control mechanism ensures that no stations can monopolize the network at the expense of others. The congestion control mechanism includes both congestion avoidance and congestion recovery.

The frame relay network does not guarantee data delivery and relies on the higher level protocol for error recovery. When experiencing congestion, the network resources will inform its users to take appropriate corrective actions. FECN/BECN bits will be set during mild congestion, while the network is still able to transfer frames. In the event of severe congestion, frames are discarded. The mechanism to prioritize the discarding process of frames relies on the discard eligibility (DE) bit in the address field of the frame header. The network will start to discard frames with the DE field set first. To avoid severe congestion from happening, a technique called traffic shaping, by the end user systems is deployed.

Traffic Management

For each PVC and SVC, a set of parameters can be specified to indicate the bandwidth requirement and to manage the burst and peak traffic values. This mechanism relies on:

Some of the features in LMI are standard implementations while some may be treated as an option. Besides the status checking for the circuits, the LMI can have optional features such as multicasting. Multicasting allows the network to deliver multiple copies of information to multiple destinations in a network. This is a useful feature especially when running protocols that use broadcast, for example ARP. Also routers such as the IBM 2212 provide features such as Protocol Broadcast which, when turned on, allows protocols such as RIP to function across the frame relay network.

IP Encapsulation in Frame Relay

The specifications for multiprotocol encapsulation in frame relay is described in RFC 2427. This RFC obsoletes the widely implemented RFC 1490. Changes have been made in the formalization of the SNAP and Network Level Protocol ID (NLPID) support, in the removed fragmentation process, address resolution in the SVC environment, source routing BPDUs support and security enhancements.

The NLPID field is administered by ISO and the ITU. It contains values for many different protocols including IP, CLNP, and IEEE Subnetwork Access Protocol (SNAP). This field tells the receiver what encapsulation or what protocol follows in a transmission.

Internet Protocol (IP) datagrams are sent over a frame relay network in encapsulated format. Within this context, IP can be encapsulated in two different ways: NLPID value indicating IP or NLPID value indicating SNAP. Although both of these encapsulations are supported under the given definitions, it is advantageous to select only one method as the appropriate mechanism for encapsulating IP data. Therefore, IP data should be encapsulated using the NLPID value of 0xCC indicating an IP packet. This option is more efficient because it transmits 48 fewer bits without the SNAP header and is consistent with the encapsulation of IP in an X.25 network.

The use of the NLPID and SNAP network layer identifier enables multiprotocol transport over the frame relay network, thus avoiding other encapsulation techniques either for bridged or for routed datagrams. This goal was achieved with the RFC 1490 specifications. This multiplexing of various protocols over a single circuit saves cost and looks attractive to network managers. But care has to be taken so that mission-critical data is not affected by other lesser important data traffic. Some implementations use a separate circuit to carry mission-critical applications but a better approach is to use a single PVC for all traffic and managing prioritization by a relatively sophisticated queuing system such as BRS.

MTU Size in Frame Relay Networks

Frame relay stations may choose to support the exchange identification (XID) specified in Appendix III of Q.922. This XID exchange allows the following parameters to be negotiated at the initialization of a frame relay circuit: maximum frame size, retransmission timer, and the maximum number of outstanding information (I) frames.

If this exchange is not used, these values must be statically configured by mutual agreement of data link connection (DLC) endpoints, or must be defaulted to the values specified in Q.922.

There is no commonly implemented minimum or maximum frame size for frame relay networks. Generally, the maximum will be greater than or equal to 1600 octets, but each frame relay provider will specify an appropriate value for its network. A frame relay data terminal equipment (DTE), therefore, must allow the maximum acceptable frame size to be configurable.

Inverse ARP

There are situations in which a frame relay station may wish to dynamically resolve a protocol address over a PVC. This may be accomplished using the standard ARP encapsulated within a SNAP-encoded frame relay packet. Because of the inefficiencies of emulating broadcasts in a frame relay environment, a new address resolution variation was developed. It is called Inverse ARP and describes a method for resolving a protocol address when the hardware address is already known. In a frame relay network, the known hardware address is the DLCI. Support for Inverse ARP function is not required, but it has proven to be useful for frame relay interface autoconfiguration.

At times, stations must be able to map more than one IP address in the same IP subnet to a particular DLCI on a frame relay interface. This need arises from situations involving remote access, where servers must act as ARP proxies for many dial-in clients, each assigned a unique IP address while sharing the bandwidth on the same DLC. The dynamic nature of such applications results in frequent address association changes with no effect on the DLC’s status.

As with any other interface that utilizes ARP, stations may learn the associations between IP addresses and DLCIs by processing unsolicited ARP requests that arrive on the DLC. If one station wishes to inform its peer station on the other end of a frame relay DLC of a new association between an IP address and that PVC, it should send an unsolicited ARP request with the source IP address equal to the destination IP address, and both set to the new IP address being used on the DLC. This allows a station to "announce" new client connections on a particular DLCI. The receiving station must store the new association, and remove any existing association, if necessary, from any other DLCI on the interface.

IP Routing in Frame Relay Networks

It is common for network managers to run an IP network across a frame relay network and there may be a need to deploy protocols that rely on a broadcast mechanism to work. In this case, some configuration is required so that these protocols continue to work across the frame relay network:

In most frame relay implementations, the topology is typically a star, or so-called hub and spoke. The router at the central site has all the branches connected to it with PVCs. Some products provide added features to simplify the configuration for OSPF in this setup. In the IBM Nways router family, you can use the OSPF point-to-multipoint frame relay enhancement. Network managers just need to configure a single IP subnet for all the entire frame relay network, instead of multiple subnets for every PVC connection. The central router is configured to have the highest router priority so that it is always chosen as the designated router.

IP Routing with SVCs

The use of SVCs in a frame relay network offers more flexibility and features such as dial-on-demand and data path cut-through. With SVCs, network design can be simplified and performance can be improved.

Bandwidth and cost have always been at odds when it comes to network design. It is important to strike a balance, whereby an acceptable performance is made available within a budget. In some cases, having permanent connectivity is a waste of resources because information exchange takes place only at a certain time of the day. In this case, having the ability to "dial on demand" when the connectivity is required saves cost. The IP address of the destination is associated with a DLCI and a call setup request is initiated when a connection to that IP address is required. After the originating workstation has sent its data, the circuit is taken down after a certain timeout period.

Usually, remote branches are connected to the central site and there is little requirement for them to have interconnection. Building a mesh topology using PVCs is costly and not practical. SVCs are more suitable here because they help to conserve network bandwidth, as well as reducing bandwidth cost. Moreover, in a star topology configuration, inter-branches communication has to go through the central site router, which increases the number of hops to reach the destination.

With SVCs, the following protocols can be implemented across the frame relay network:

2.1.3.5 Serial Line IP (SLIP)

Point-to-point connections have been the mainstay for data communication for many years. In the history of TCP/IP, the Serial Line IP (SLIP) protocol has been the de-facto standard for connecting remote devices and you can still find its implementation. SLIP provides the ability for two endstations to communicate across a serial line interface and it is usually used across a low bandwidth link.

SLIP is a very simple framing protocol that describes the format of packets over serial line interfaces and has the following characteristics:

There have been some modifications to make SLIP more efficient, such as Van Jacobson header compression, and many SLIP implementations use them.

2.1.3.6 Point-to-Point Protocol (PPP)

The Point-to-Point Protocol (PPP) is an Internet standard that has been developed to overcome the problems associated with SLIP. For instance, PPP allows negotiation of addresses across the connection instead of statically defining them. PPP is a network-specific standard protocol with STD number 51. Its status is elective and it is described in RFC 1661 and RFC 1662.

PPP implements reliable delivery of datagrams over both synchronous and asynchronous serial lines. It also implements data compression and can be used to route a wide variety of network protocols.

PPP has three main components:

The format of the PPP frame is similar to the HDLC one. The Point-to-Point Protocol provides a byte-oriented connection exchanging information and message packets in a single format frame. The PPP Link Control Protocol (LCP) is used to establish, configure, maintain and terminate the connection and goes through the following phases to establish a connection:

Authentication Protocols

PPP authentication protocols provide a form of security between two nodes connected via a PPP link. There are different authentication protocols supported:

The authentication mechanism starts at the LCP exchange, because if one of the end systems refuses to use an authentication protocol requested by the other the link setup fails. Also some authentication protocols, for instance CHAP, may require the end systems to exchange the authentication messages during connection setup.

The Network Control Protocol (NCP)

PPP has many network control protocols (NCP) for establishing and configuring different network layer protocols. They are used to individually set up and terminate specific network layer protocol connections. PPP supports many NCPs such as the following:

IPCP is described in RFC 1332 and specifies some features such as the Van Jacobson header compression mechanism or the IP address assignment mechanism.

An endstation can either send its IP address to the peer or accept an IP address. Moreover it can supply an IP address to the peer if the peer requests that address. The first situation you will handle an unnumbered interface. That is that both ends of the point-to-point connection will have the same IP address and will be seen as a single interface. This does not create problems in the IP routing algorithms. Otherwise the other end system of the link will be provided with its own address.

The router will automatically add a static route directed to the PPP interface for the address that is successfully negotiated, allowing data to be properly routed. When the IPCP connection is ended this static route is subsequently removed. This is a common configuration used for dial-in users.

Multilink PPP

Multilink PPP (MP) is an important enhancement that has been introduced in the PPP extensions to allow multiple parallel PPP physical links to be bundled together as if they were a single physical path. The implementation of multilink PPP can accomplish dynamic bandwidth allocation and also on-demand features to increase the available bandwidth for a single logical connection. The use of multilink PPP is also an enhancement that can have importance in the area of multimedia application support.

Multilink PPP is based on the fragmentation process of large frames and rebuilding them, sequentially. When the PPP links are configured for multilink PPP support they are said to be bundled. The multilink PPP sender is allowed to fragment large packets and the fragmented frames are delivered with an added multilink PPP header that basically consists of a sequence number that identifies each fragmented packet. The multilink PPP receiver reassembles the input packets in the correct order following the sequence numbers in the multilink PPP header.

The virtual connection made up by multilink PPP has more bandwidth than the original PPP link. The resulting MP bundled bandwidth is almost equal to the sum of the bandwidths of the individual links. The advantage is that large data packets can be transmitted within a shorter time.

The multilink PPP implementation in the Nways 221x family can accomplish both the Bandwidth Allocation Protocol (BAP) and the Bandwidth Allocation Control Protocol (BACP) to dynamically add and drop PPP dial circuits to a virtual link.

Multilink PPP also uses Bandwidth On Demand (BOD) to add dial-up links to an existing multilink PPP bundle.

The multilink PPP links can be defined in two different ways:

The Bandwidth Allocation Protocol (BAP) and the Bandwidth Allocation Control Protocol (BACP) are used to increase and decrease the multilink PPP interface bandwidth. These protocols rely on processes that when the actual bandwidth utilization thresholds are reached they can manage to add an enabled multilink PPP dial circuit to the MP bundle, if any is available and the negotiation process with the partner does not fail. The dedicated links have the priority of being added to the bundle, followed by the enabled ones.

The Bandwidth On Demand protocol (BOD) adds dial links to the MP bundle using configured dial circuit’s telephone numbers. They are added in sequence and lasts for the time that the bundle is in use.

Using multilink PPP needs some careful planning of the configured bundles. Limitations exist for mixing leased lines and dial-up circuits in the same bundle. Multilink PPP capabilities are being investigated to support multi-class functions in order to provide a reliable data link layer protocol for multimedia traffic over low speed links . The multilink PPP implementation in the Nways 221x router family supports also the Multilink multi-chassis. This functionality is provided when a remote connection can establish a layer 2 tunnel with a phone hunt group that spans over multiple access servers (see Access Integration Services Software User’s Guide V3.2, SC30-3988).

2.1.4 Asynchronous Transfer Mode (ATM)

Asynchronous transfer mode ( ATM) is a switching technology that offers high speed delivery of information including data, voice and video. It runs at 25, 100, 155, 622 Mbps or even up to 2.4 Gbps, and is both suitable for deployment in a LAN or WAN environment. Due to its ubiquitous nature, it can be categorized as both a LAN or a WAN technology.

Unlike LAN technologies such as Ethernet or token-ring that transport information in packets called frames, ATM transports information in cells. In legacy LANs, frames can vary in size, while in ATM, the cells are of fixed size and they are all 53 bytes. ATM is a connection-oriented protocol, which means it does not use broadcast techniques at the data link layer for delivery of information, and the data path is predetermined before any information is sent. It offers features that are not found in Ethernet or token-ring, one of which is called Quality of Service (QoS). Another benefit that ATM brings is the concept of Virtual LAN (VLAN). Membership in a group is no longer determined by physical location. Logically similar workstations can now be grouped together even though they are all separated.

Because ATM works differently from the traditional LAN technologies, new communication protocols and new applications have to be developed. Before this happens, something needs to be done to make the traditional LAN technologies and IP applications work across an ATM network. Today, there are two standards developed solely for this purpose:

2.1.4.1 Classical IP (CIP)

Classical IP (RFC 1577) is a way of running the IP protocol over an ATM infrastructure. As its name implies, it supports only the IP protocol. Since ATM does not provide broadcast service, something needs to be done to address the mechanism for ARP, which is important in IP for mapping IP addresses to hardware addresses. A device called the ARP server is introduced in this standard to address this problem and all IP workstations will have to register with the ARP server before communication can begin.

In RFC 1577, all IP workstations are grouped into a common domain called a logical IP subnet, or LIS. And within each LIS, there is an ARP server. The purpose of the ARP server is to maintain a table containing the IP addresses of all workstations within the LIS and their corresponding ATM addresses. All other workstations in a LIS are called ARP clients and they place calls, ATMARP, to the ARP server, for the resolution of the IP address to the ATM address. After receiving the information from the ARP server, ARP clients proceed to make calls to other clients to establish the data path so that information can flow. Therefore, ARP clients need to be configured with the ATM address of the ARP server before they can operate in a CIP environment. In a large CIP network, this poses an administrative problem if there is going to be a change in ARP server’s ATM address. Due to this problem, it is advisable to configure the ARP server’s End System Identifier (ESI) with a locally administered address (LSA) so that no reconfiguration is required on ARP clients.

There is an update to the RFC, called RFC 1577+, that provides the mechanism for multiple ARP servers within a single LIS. This is mainly to provide redundancy to the ARP server.

Classical IP over Permanent Virtual Circuit (CIP over PVC)

There is another implementation of CIP, which is called CIP over PVC. CIP over PVC is usually deployed over an ATM WAN connection, where the circuit is always connected. This is typically found in service providers that operate an ATM core switch (usually with switching capacity ranging from 50 Gbps to 100 Gbps), with limited or no support for SVC services. In CIP over PVC, there is no need to resolve the IP address of the destination to ATM address, as it has been mapped statically to an ATM connection through the definition of virtual path identifier (VPI) and virtual channel identifier (VCI) values. Because the mapping has to be done statically, CIP over PVC is used in networks where the interconnections are limited, otherwise, it would be an administrative burden for the network manager.

Though it may have its limitations, CIP over PVC can be a good solution to some specific requirements. For example, if it is used to connect a remote network to a central backbone, the network manager can set up the PVC connection in the ATM switch to be operative only at certain times of the day. The operation of the PVC (for example, setup and tear down) can be managed automatically by a network management station. In this way, a network manager can limit the flow of the remote network’s traffic to certain times of the day for security reasons or for a specific business requirement.

Advantages of CIP

There are several advantages of using CIP, especially in the areas of performance and simplicity:

2.1.4.2 LAN Emulation (LANE)

Unlike CIP, which provides for running only IP over ATM, LAN Emulation (LANE), is a standard that allows multiprotocol traffic to flow over ATM. As its name implies, LANE emulates the operation of Ethernet or token-ring so that existing applications that run on these two technologies can operate on ATM without any changes. It is useful in providing a migration path for the existing LAN to ATM because it protects the investment cost in the existing applications.

The components that make up LANE are much more complicated than those in CIP:

Although more complicated in terms of its implementation as opposed to CIP, LANE enjoys some advantages in several areas:

The following table shows the difference between ATM and LAN technologies.

LAN CIP LANE
Speed (Mbps) 4/16/100/1000 25/155/622 25/155/622
Broadcast support Yes No Yes, through the BUS
QoS No Yes Yes
Multiprotocol Yes No, only IP Yes
Shared/Dedicated bandwidth Share/Switch Switch Switch
Transport Data/Voice/Video natively No Yes Yes
Need new protocol No Yes Yes
Need new adaptor No (most PCs now have built-in LAN ports) Yes Yes
Administrative effort in installation of client Minimal Need to specify ARP server’s ATM address Can join an ELAN through any combination of the following :
- LECS address
- LES/BUS address
- ELAN names
Overheads (header vs total packet size) Low (≤ 2%) High (≥10%) High (≥ 10%)

ATM is a technology that provides a ubiquitous transport mechanism for both LAN and WAN. In the past, LAN and WAN used different protocols to operate, such as Ethernet for LAN and ISDN for WAN. This complicates design and makes maintaining the network costly because more protocols are involved, and managers need to be trained on different protocols. With ATM, it is possible to use it for both LAN and WAN connections and to make the network homogeneous.

2.1.5 Fast Internet Access

In recent years, the number of users on the Internet has grown exponentially and more and more users are subscribing to Internet service providers (ISPs) for access. Most home users still connect to ISPs through an analog modem, with initial speeds at a mediocre 9.6 kbps. With advancements in modem technology, the speed has increased to 14.4 kbps, to 28.8 kbps, then to 33.6 kbps and finally to 56 kbps. Some users have even signed up for ISDN services at 128 kbps or 256 kbps but these are few.

With the advent of e-commerce and multimedia rich applications proliferating on the Internet, this "last mile" technology has proved to be a serious bottleneck. Vendors are developing new technologies to "broaden the last mile pipe" and there are two major technologies today that do this: the cable modem and the xDSL technology.

These technologies, besides providing higher bandwidth for "surfers", have opened a new door for network managers who may be looking at new technologies for their company. With more employees working away from the office, application design has taken a new turn. In the past, application developers have always assumed that all users are connected via the LAN technologies, and bandwidth is never a problem. With more and more users working from home, application developers have now realized their application may not run on a user’s workstation at home, because of the 28.8 kbps link at which he or she is connected. While the company LAN has gone from 10 Mbps to 100 Mbps, and the entire corporation gears toward multimedia application deployment, there are still some carts dragging behind. Although security may pose a problem to the corporation, these technologies have nonetheless given network managers some additional options in remote connectivity.

2.1.5.1 Cable Modem Network

The cable TV (CATV) infrastructure is traditionally used for the transmission of one way analog video signals. The network infrastructure has evolved from mostly coaxial cabling to the new Hybrid Fiber-Coaxial (HFC) network, which is made up of a combination of fiber optic and coaxial "last mile" networks. With the introduction of fiber optic networks and the development of new standards, the HFC network soon became capable of two way transmission.

The cable modem network is typically made up of high speed fiber optic distribution rings and coaxial cabling that carry the TV signals to the subscriber’s home. Subscribers staying in the same district are connected to a common distribution point called a headend. The coaxial cable runs from the headend to the homes in a tree topology and the traffic direction is predominantly from the headend to the homes. The cable router is a specialized device that can transport data from a data network through the CATV’s coaxial infrastructure to the homes. It can also receive a signal from the cable modems installed in the homes and transport it to the data network.

The subscriber’s PC is connected to the cable modem through a 10 Mbps Ethernet Interface, so to the PC, it is exactly like connecting to a LAN. The bandwidth of the cable modem network is asymmetric, which means the bandwidth that is available from the headend to the subscribers (called the downstream channel) are not the same as that in the reverse direction (called the upstream channel). The downstream channel bandwidth ranges from 30 Mbps to 50 Mbps and all subscribers that are connected to this downstream channel share the common bandwidth. The upstream channel ranges from 500 kbps to 800 kbps. Depending on the configuration and bandwidth requirements, a group of subscribers can share two downstream and four upstream channels, giving a total of 60 Mbps downstream and 2 Mbps upstream. The design of the bandwidth distribution is such because the cable modem network is used mainly to provide fast Internet access. And Internet access is mainly sending a few strings of requests to a Web server for a bigger chunk of data to be displayed on a Web browser.

Cable modem technology provides a way for fast Internet connection (easily as 100 times faster than that of analog modems) for the homes and it can possibly be deployed for mobile workers. As a rather new technology, it has its problems and limitations:

These different standards make interoperability difficult and cable companies may not want to deploy cable modem on a large scale.

2.1.5.2 Digital Subscriber Line (DSL) Network

The digital subscriber line (DSL) technology is a way of transporting data over a normal phone line at a higher speed than the current analog modem. The term xDSL is usually used because there are several standards to it:

The xDSL technology is capable of providing a downstream bandwidth of 30 Mbps and an upstream bandwidth of around 600 kbps. But in commercial deployment, it is usually 1.5 Mbps downstream and maybe 256 kbps upstream. Subscribers of xDSL technology are connected to a device called a MUX in a point-to-point manner. The MUX aggregates a number of subscribers (usually 48, some may go as high as 100) and has an uplink to a networking device, typically a switch.

An interesting point to note is that, unlike a conventional analog modem, a subscriber can still use the phone while the xDSL modem is in use. This is because the signaling used by the xDSL modem is of a different frequency from that used by the phone. The subscriber’s PC is connected to the modem through an Ethernet or ATM interface. For connection through the ATM interface, CIP is commonly used.

The xDSL technology is positioned as a competitor to the cable modem network because both of these are competing for the same market - home Internet users. Although mainly used for connecting home users, there are already some companies experimenting with using xDSL for connections to the head office.

The deployment of xDSL technology was not a smooth one in the beginning due to its severe limitations on distance. Early subscribers had to be living near the telephone exchanges. With improvements in the technology and the deployment of other equipment, the distance problem has slowly been resolved.

2.1.5.3 Cable Modem versus xDSL

Both the cable modem and xDSL technologies provide a "fat pipe" to subscriber homes. While the intent is to provide fast Internet access to the subscribers, many service providers have begun testing new technologies such as Video On Demand and VPN services.

There are some differences between the cable modem and the xDSL technology and they can be summarized as follows:

Cable Modem xDSL
Topology Tree Point-to-point
Infrastructure Cable TV Phone
Connectivity at PC Ethernet Ethernet/ATM
Bandwidth Users share a common downstream (e.g. 30 Mbps) Point-to-Point connection to the MUX, usually at 1-3 Mbps
Connection Continuous (due to cheap charging scheme) May not be Continuous (due to duration based charging)
Availability Only to houses with CATV wiring To houses with phone lines
Wide spread use Limited Very limited
Potential for business use Not really. Not all business addresses have CATV wiring A viable alternative
Charge scheme Usually flat rate Flat/Duration based

Network managers planning to consider these technologies have to think about the following:

2.1.6 Wireless IP

Mobility has always been the key to success for many companies. Without doubt, mobile communication will be a key component of a company’s network infrastructure in the next few years. Much research and development has been done on wireless communication, and in fact, wireless communication has been around for quite some time. With the popularity of the Internet, many developments have focused on delivering IP across a mobile network.

For many years, one of the problems with wireless communication has been the adoption of standards and speed. But things are changing with the approval of the IEEE 802.11 standard for wireless networks. It specifies a standard for transmitting data over a wireless network at up to 2 Mbps or even at a higher rate in the future. IEEE 802.11 uses the 2.4 GHz portion of the radio frequency. Some research groups have even begun experimenting with a higher transmission rate at a different frequency.

With the adoption of the IEEE 802.11 standard and vendors producing proven products, you may have to give a wireless network serious thought. Here are some reasons why:

Wireless IP is a relatively new field to many network managers. It is important for network managers to begin exploring it as it is set to become more popular as there is an increase in mobile workers and the introduction of field proven products.

2.1.6.1 Cellular Digital Packet Data (CDPD)

Cellular digital packet data (CDPD) is a way of transmitting an IP packet over a cellular phone network. With the increase in popularity of the personal digital assistant (PDA), many vendors are developing products as an add-on to the PDA to enable users to connect to a mobile network. Since the connection is still slow, at 19.2 kbps, it is mainly used for e-mail exchange and text-based information dissemination. CDPD products are usually a modem that fits to the PDA and provides basic TCP/IP services such as SLIP or PPP protocol.

The advantage of CDPD is of course mobility. No longer is a user tied to the physical connection of a LAN. Information is readily available, and users need not even look for a phone line anymore. With companies putting more workers on the road, it is an important area that network managers should start looking into.

As a new technology, besides the maturity of standards and products, there are several concerns that network managers should look into also. CDPD is capable of sending data at 19.2 kbps. Taking into account the adding of a header for reliable transmission, the actual data transfer rate is more like 9.6 kbps. With a transmission rate like this, it is only the important text data that is transmitted. Graphics or multimedia applications are almost out of the question. Also, one of the most important aspects of mobile networks is of course security. Some area that need special attention include:

Also, deploying CPDP technology in a network involves subscribing the service from a service provider. This translates to extra cost involved and may not be cheap for a company with several thousand employees. Last but not least, mobile communication is subject to interference and failures such as poor transmission power due to a low battery or over long distance. Error recovery becomes very important in situations like these, and should be both at the network layer as well as the application layer.

2.2 The Connecting Devices

A network can be as simple as two users sharing information through a diskette or as complex as the Internet that we have today. The Internet is made up of thousands of networks interconnected through devices called hubs, bridges, routers and switches. These devices are the building blocks of a network and each of them performs a specific task to deliver the information that is flowing in the network. Some points to be considered as to which device is the most appropriate one to implement are:

The connecting devices function at different layers of the OSI model, and it is important to know this so that a choice can be made in using them.


Prev Home Next
Datacenter Up VOIP

CSS ist valide! Valid XHTML 1.0 Transitional