Packet switching in networks

Packet switching is used to optimize the use of the channel capacity available in digital telecommunication networks such as computer networks, to minimize the transmission latency (i.e. the time it takes for data to pass across the network), and to increase robustness of communication.

The most well-known use of packet switching is the Internet and local area networks. The Internet uses the Internet protocol suite over a variety of Link Layer protocols. For example, Ethernet and frame relay are very common. Newer mobile phone technologies (e.g., GPRS, I-mode) also use packet switching.

X.25 is a notable use of packet switching in that, despite being based on packet switching methods, it provided virtual circuits to the user. These virtual circuits carry variable-length packets. In 1978, X.25 was used to provide the first international and commercial packet switching network, the International Packet Switched Service (IPSS). Asynchronous Transfer Mode (ATM) also is a virtual circuit technology, which uses fixed-length cell relay connection oriented packet switching.

Datagram packet switching is also called connectionless networking because no connections are established. Technologies such as Multiprotocol Label Switching (MPLS) and the Resource Reservation Protocol (RSVP) create virtual circuits on top of datagram networks. Virtual circuits are especially useful in building robust failover mechanisms and allocating bandwidth for delay-sensitive applications.

MPLS and its predecessors, as well as ATM, have been called "fast packet" technologies. MPLS, indeed, has been called "ATM without cells". Modern routers, however, do not require these technologies to be able to forward variable-length packets at multigigabit speeds across the network.

image

Packet switching

Packet switching is a network communications method that groups all transmitted data, irrespective of content, type, or structure into suitably-sized blocks, called packets. The network over which packets are transmitted is a shared network that routes each packet independently from all others and allocates transmission resources as needed. Principal goals of packet switching are to optimize utilization of available link capacity and to increase robustness of communication.

Network resources are managed by statistical multiplexing or dynamic bandwidth allocation in which a physical communication channel is effectively divided into an arbitrary number of logical variable-bit-rate channels or data streams. Each logical stream consists of a sequence of packets, which normally are forwarded by a network node asynchronously in a first-in, first-out fashion. Alternatively, the packets may be forwarded according to some scheduling discipline for fair queuing or for differentiated or guaranteed quality of service. In case of a shared physical medium, the packets may be delivered according to some packet-mode multiple access scheme. When traversing network nodes, packets are buffered and queued, resulting in variable delay and throughput, depending on the traffic load in the network.

Packet switching contrasts with another principal networking paradigm, circuit switching, a method which sets up a specific circuit with a limited number dedicated connection of constant bit rate and constant delay between nodes for exclusive use during the communication session.

Packet mode (or packet-oriented, packet-based) communication may be utilized with or without intermediate forwarding nodes (packet switches).

ConnNet

ConnNet was a packet switched data network operated by the Southern New England Telephone Company serving the U.S. state of Connecticut.

ConnNet was the nation's first local public packet switching network when it was launched on March 11, 1985. Users could access services such as Dow Jones News Retrieval, CompuServe, Dialcom, GEnie, Delphi, Eaasy Sabre, NewsNet, PeopleLink, the National Library of Medicine, and BIX. ConnNet could also be used to access other national and international packet networks, such as Tymnet and ACCUNET. Large companies also connected their mainframe computers to ConnNet allowing employees access to the mainframes from home. The network is no longer in operation.

Hardware

The X.25 network was based on hardware from Databit, Inc. consisting of three EDX-P Network Nodes that performed switching and were located in Hartford, New Haven and Stamford. Databit also supplied 23 ANP 2520 Advanced Network Processors each of which provided the system with a point of presence, a network control center and modems. Customers would order leased line connections into the network for host computers running at 4,800 to 56,000 bits per second (bit/s). Terminals would connect over a leased line from 1,200 to 9,600 bit/s synchronous, 300 to 2,400 bit/s asynchronous or using dial-up connections from 300 to 1,200 bit/s. The connection to Tymnet was established over an X.75 based 9,600 bit/s analog link from the ConnNet Hartford node to Tymnet's Bloomfield node.

Tymnet

Tymnet was an international data communications network headquartered in San Jose, California that utilized virtual call packet switched technology and used X.25, SNA/SDLC, ASCII and BSC interfaces to connect host computers (servers) at thousands of large companies, educational institutions, and government agencies. Users typically connected via dial-up connections or dedicated async connections. The business consisted of a large public network that supported dial-up users and a private network business that allowed government agencies and large companies (mostly banks and airlines) to build their own dedicated networks. The private networks were often connected via gateways to the public network to reach locations not on the private network. Tymnet was also connected to dozens of other public networks in the United States and internationally via X.25/X.75 gateways.

As the Internet grew and became almost universally accessible in the late 1990s, the need for services such as Tymnet migrated to the Internet style connections, but still had some value in the third world and for specific legacy roles. However the value of these links continued to decrease, and Tymnet was officially shut down in 2004.

Network

Tymnet offered local dial-up modem access in most cities in the United States and to a limited degree in Canada, which preferred its own DATAPAC service.

Users would dial into Tymnet and then interact with a simple command-line interface to establish a connection with a remote system. Once connected, data was passed to and from the user as if connected directly to a modem on the distant system. For various technical reasons, the connection was not entirely "invisible", and sometimes required the user to enter arcane commands to make 8-bit clean connections work properly for file transfer.

Tymnet was extensively used by large companies to provide dial-up services for their employees who were "on the road", as well as a gateway for users to connect to large online services such as CompuServe or The Source.

Organization and functionality

In its original implementation, the network supervisor contained most of the routing intelligence in the network. Unlike the TCP/IP protocol underlying the internet, Tymnet used a circuit switching layout which allowed the supervisors to be aware of every possible end-point. In its original incarnation, the users connected to nodes built using Varian minicomputers, then entered commands that were passed to the supervisor which ran on a XDS 940 host.

Circuits were character oriented and the network was oriented towards interactive character-by-character full-duplex communications circuits. The nodes handled character translation between various character sets, which were numerous at that point in time. This did have the side effect of making data transfers quite difficult, as bytes from the file would be invisibly "translated" without specific intervention on the part of the user.

Tymnet later developed their own custom hardware, the Tymnet Engine, which contained both nodes and a supervisor running on one of those nodes. As the network grew, the supervisor was in danger of being overloaded by the sheer number of nodes in the network, since the requirements for controlling the network took a great part of the supervisor's capacity.

Tymnet II was developed in response to this challenge. Tymnet II was developed to ameliorate the problems outlined above by off-loading some of the work-load from the supervisor and providing greater flexibility in the network by putting more intelligence into the node code. A Tymnet II node would set up its own "permuter tables", eliminating the need for the supervisor to keep copies of them, and had greater flexibility in handling its inter-node links. Data transfers were also possible via "auxiliary circuits".

Telenet

Telenet was a packet switched network which went into service in 1974. It was the first publicly available commercial packet-switched network service.

The original founding company, Telenet Inc., was established by Larry Roberts (former head of the ARPANet), and Barry Wessler. GTE acquired Telenet in 1979. It was later acquired by Sprint and called "Sprintnet". Sprint migrated customers from Telenet to the modern-day SprintLink IP network, one of many networks composing today's Internet. Telenet had its first offices in downtown Washington DC, then moved to McLean, Virginia. It was acquired by GTE while in McLean, and then moved offices in Reston, Virginia.

Under the various names, the company operated a public network, and also sold its packet switching equipment to other carriers and to large enterprise networks.

Coverage

Originally, the public network had switching nodes in seven US cities:

* Washington, D.C. (network operations center as well as switching)
* Boston, MA
* New York, NY
* Chicago, IL
* Dallas, TX
* San Francisco, CA
* Los Angeles, CA

The switching nodes were fed by Telenet Access Controller (TAC) terminal concentrators both colocated and remote from the switches. By 1980, there were over 1000 switches in the public network. At that time, the next largest network using Telenet switches was that of Southern Bell, which had approximately 250 switches.

Internal Network Technology

The initial network used statically-defined hop-by-hop routing, using Prime commercial minicomputers as switches, but then migrated to a purpose-built multiprocessing switch based on 6502 microprocessors. Among the innovations of this second-generation switch was a patented arbitrated bus interface that created a switching fabric, a shared bus in modern terms, among the microprocessors.

Most interswitch lines ran at 56 kbit/s, with a few, such as New York-Washington, at T1 (i.e., 1.544 Mbit/s). The main internal protocol was a proprietary variant on X.75; Telenet also ran standard X.75 gateways to other packet switching networks.

Originally, the switching tables could not be altered separately from the main executable code, and topology updates had to be made by deliberately crashing the switch code and forcing a reboot from the network management center. Improvements in the software allowed new tables to be loaded, but the network never used dynamic routing protocols. Multiple static routes, on a switch-by-switch basis, could be defined for fault tolerance. Network management functions continued to run on Prime minicomputers.

Its X.25 host interface was the first in the industry and Telenet helped standardize X.25 in the CCITT.

Reverse telnet

Reverse telnet is a specialized application of telnet, where the server side of the connection reads and writes data to a TTY line (RS-232 serial port), rather than providing a command shell to the host device. Typically, reverse telnet is implemented on an embedded device (e.g. terminal/console server), which has an Ethernet network interface and serial port(s). Through the use of reverse telnet on such a device, IP-networked users can use telnet to access serially-connected devices.

In the past, reverse telnet was typically used to connect to modems or other external asynchronous devices. Today, reverse telnet is used mostly for connecting to the console port of a router, switch or other device.

Example

On the client, the command line for initiating a "reverse telnet" connection might look like this:

telnet 172.16.1.254 2002

(The syntax in the above example would be valid for the command-line telnet client packaged with many operating systems, including most Unices, or available as an option or add-on.)

In this example, 172.16.1.254 is the IP address of the server, and 2002 is the TCP port associated with a TTY line on the server.

A typical server configuration on a Cisco router would look like this:

version 12.3
service timestamps debug uptim
service timestamps log uptime
no service password-encryption
!
hostname Terminal_Server
!
ip host Router1 2101 8.8.8.8
ip host Router2 2102 8.8.8.8
ip host Router3 2113 8.8.8.8
!
!
interface Loopback0
description Used for Terminal Service
ip address 8.8.8.8 255.255.255.255
!
line con 0
exec-timeout 0 0
password MyPassword
login
line 97 128
transport input telnet
line vty 0 4
exec-timeout 0 0
password MyPassword
login
transport input none
!
end

Telnet Security

When Telnet was initially developed in 1969, most users of networked computers were in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became after the bandwidth explosion of the 1990s. The rise in the number of people with access to the Internet, and by extension, the number of people attempting to crack other people's servers made encrypted alternatives much more of a necessity.

Experts in computer security, such as SANS Institute, and the members of the comp.os.linux.security newsgroup recommend that the use of Telnet for remote logins should be discontinued under all normal circumstances, for the following reasons:


* Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark.

* Most implementations of Telnet have no authentication to ensure that communication is carried out between the two desired hosts and not intercepted in the middle.

* Commonly used Telnet daemons have several vulnerabilities discovered over the years.


These security-related shortcomings have seen the usage of the Telnet protocol drop rapidly, especially on the public Internet, in favor of the ssh protocol, first released in 1995. SSH provides much of the functionality of telnet, with the addition of strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be.

As has happened with other early Internet protocols, extensions to the Telnet protocol provide TLS security and SASL authentication that address the above issues. However, most Telnet implementations do not support these extensions; and there has been relatively little interest in implementing these as SSH is adequate for most purposes. The main advantage of TLS-Telnet would be the ability to use certificate-authority signed server certificates to authenticate a server host to a client that does not yet have the server key stored. In SSH, there is a weakness in that the user must trust the first session to a host when it has not yet acquired the server key.

SSH Tunnel Diagram

Hand drawn Diagram about SSH tunneling

Connection methods

FTP runs exclusively over TCP. FTP servers by default listen on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. FTP uses out-of-band control, which means it uses a separate connection for control and data. Thus, for the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.

In active mode, the FTP client opens a dynamic port (49152–65535), sends the FTP server the dynamic port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 20 on the FTP server.

In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2". Each field is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 49154 for the data connection will send the command "PORT 192,168,0,1,192,2". The port fields should be interpreted as p1×256 + p2 = port, or, in this example, 192×256 + 2 = 49154.

In passive mode, the FTP server opens a dynamic port (49152–65535), sends the FTP client the server's IP address to connect to and the port on which it is listening (a 16 bit value broken into a high and low byte, like explained before) over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a dynamic port between 49152 and 65535.

To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode (127,0,0,1,192,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.

In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by RFC 2428 in September 1998.

While data is being transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the control session can be disconnected by the firewall, causing an error to be generated.

The FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some commandline clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption.

Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command.

In ASCII mode , resuming transfers can be troublesome if client and server use different end of line characters.

The objectives of FTP, as outlined by its RFC, are:
To promote sharing of files (computer programs and/or data).
To encourage indirect or implicit use of remote computers.
To shield a user from variations in file storage systems among different hosts.
To transfer data reliably, and efficiently.

File Transfer Protocol

In computing, the File Transfer Protocol (FTP) is a network protocol used to transfer data from one computer to another through a network, such as over the Internet.

FTP is a file transfer protocol for exchanging files over any TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access). There are many existing FTP client and server programs. FTP servers can be set up anywhere between game servers, voice servers, internet hosts, and other physical servers.