Download Computer Network (NEW)hot!

Govt. Polytechnic for Women, Morni Hills, Panchkula
Department of Computer Engineering
E- Session Notes
Subject: Computer Network;
Semester: 5th
For any enquiry, please contact Office or Call at 01733-250096 or Visit
www.mornigpw.org or contact us at [email protected]
1
Subject:-Computer Networks
S.
No
1
2
Session :- 3 hrs
Topic Covered
Session
No.
Networking Basics : Definition of network, Session 1
Models of network computing, Network models,
LAN, MAN and,WAN, network architecture,
OSI Reference Model, layer services, primitives Session 2
and service access points.
3
DLL design issues, elementary
protocols, sliding window protocols
4
Sliding window protocols
5
Network layer, Routing algorithms, Congestion Session 5
Control algorithms.
6
Unit-3 Functioning of session layer Session
Layer OSI primitives, Remote procedure calls
Session 6
7
Data Compressing (4 hrs)
Huffman arithmetic codes, Data encryption,
Public encryptography and its uses
Session 7
Presentation Layer (4 hrs)
Presentation layer primitives, function
presentation layer
Application Layer, Application layer design
issue
Session 9
8
9
10
11
data
link Session 3
Session 4
Session 8
of
File transfer and management, E-mail, virtual
terminal
2
Session 10
Session 11
Session 1
Networking Basics
Introduction:Computer Network:
A computer network, often simply referred to as a network, is a collection
of computers and
other
hardware components
interconnected
by
communication channels that allow sharing of resources and information.
Where at least one process in one device is able to send/receive data to/from
at least one process residing in a remote device, then the two devices are said
to be in a network. Simply, more than one computer interconnected through a
communication medium for information interchange is called a computer
network.
Networks may be classified according to a wide variety of characteristics, such
as the medium used to transport the data, communications protocol used,
scale, topology, and organizational scope.
Communications protocols define the rules and data formats for exchanging
information in a computer network, and provide the basis for network
programming. Well-known communications protocols include Ethernet, a
hardware and link layer standard that is ubiquitous in local area networks,
and the Internet protocol suite, which defines a set of protocols for
internetworking, i.e. for data communication between multiple networks, as
well as host-to-host data transfer, and application-specific data transmission
formats.
Definition of network
When you have two or more computers connected to each other, you have a
network. The purpose of a network is to enable the sharing of files and
information between multiple systems. The Internet could be described as a
global network of networks. Computer networks can be connected through
cables, such as Ethernet cables or phone lines, or wirelessly, using wireless
networking cards that send and receive data through the air.
Models of Network Computing
After you have the necessary prerequisites for network communication, a
structure must be put in place that organizes the way communication and
sharing occur. Many models are recognized. We will discuss very basic two
models:
1. Centralized Computing
2. Distributed Computing
3
Various types of network are derived from these two basic models of
computing. (Some people may include 'Collaborative Computing', but this
type of computing is the subtype of 'Distributed Computing').
Centralized Computing
The earliest computers were large, expensive, and difficult to manage.
Originally, these large mainframe computers were not networked in the sense
you are familiar with today. Jobs were entered into the system by reading
commands from card decks. The computer would execute one job at a time
and generate a printout when the job was complete. Terminals, which came
later, enabled users to interact with the centralized computer, but terminals
were merely input / output devices that had no independent processing
power. All processing still took place on the mainframe, hence the name
centralized computing. Networks, therefore, served little purpose other than
to deliver commands to and results from the powerful centralized processing
device. Large IBM and Digital (DEC) networks often still operate on this
model, but Microsoft has largely ignored it.
In summary, the centralized computing model involves the following:
1. All processing takes place in the central, mainframe computer.
2. Terminals are connected to the central computer and function only as
input / output devices.
3. Networks may be employed to interconnect two or more mainframe
computers. Terminals connect only to the mainframe, never to each
other.
This early computing model worked well in large organizations, but was not
flexible and did not scale down to meet the needs of smaller organization. As
such, new ways to sharing information were needed to allow computing power
to be shared efficiently on smaller networks.
Distributed Computing
As personal computers were introduced to organizations, a new model of
distributed computing emerged. Instead of concentrating computing to a
central device, PCs made it possible to give each worker an independent,
individual computer. Each of these PCs can process and store data locally,
without assistance from another machine. This meant that groups who
previously had found the cost of a mainframe environment prohibitive were
able to gain the benefits of networking at far-reduced cost. Under the
distributed computing model, networking has evolved to enable the many
distributed computers to exchange data and share resources and services
4
among themselves. Note that these machines need not be considered equals.
A Windows NT file server, for instance, is considered to be a part of a
distributed network. This server stores and retrieves files for other machines,
but doesn't do the thinking for these machines as a mainframe would have
done in the centralized computing model.
In summary, distributed computing involves the following:
1. Multiple computers are capable of operating independently.
2. Tasks are completed locally on various computers.
3. Networks enable the computers to exchange data and services but do
not provide processing assistance.
Distributed computing was a major step forward in the way that businesses
could leverage their hardware resources. However, it largely dealt with
sharing of data and printers. Processing was left to be done at each machine
separately, without any specialization or assistance.
Collaborative Computing:
Also called cooperative computing, collaborative computing enables
computers in a distributed computing environment to share processing power
in addition to data, resources, and services. In a collaborative computing
environment, one computer might "borrow" processing power by running a
program on other computers on the network. Or, processes might be
designed so that they can run on two or more computers. Obviously,
collaborative computing cannot take place without a network to enable the
various computers to communicate.
Network Models
LAN, MAN and WAN
A LAN (local area network) is a group of computers and network devices
connected together, usually within the same building. By definition, the
connections must be high speed and relatively inexpensive (e.g., token ring or
Ethernet). Most Indiana University Bloomington departments are on LANs.
A LAN connection is a high-speed connection to a LAN. On the IUB campus,
most connections are either Ethernet (10Mbps) or Fast Ethernet (100Mbps),
and a few locations have Gigabit Ethernet (1000Mbps) connections.
A MAN (metropolitan area network) is a larger network that usually spans
several buildings in the same city or town. The IUB network is an example of
a MAN.
5
A WAN (wide area network), in comparison to a MAN, is not restricted to a
geographical location, although it might be confined within the bounds of a
state or country. A WAN connects several LANs, and may be limited to an
enterprise (a corporation or an organization) or accessible to the public. The
technology is high speed and relatively expensive. The Internet is an example
of a worldwide public WAN.
Network Topology
There are two levels in a network topology and there are five kinds of network
topologies. The networks can be connected at two levels, the physical and the
other is logical. A topology basically defines how the network has to be
designed and provides a structure to the network.
The five different kinds of topologies are
•Bus
•Ring
•Star
•Tree
• Mesh
Bus Topology
The bus topology is a series of nodes which are all connected to a backbone.
Bus networks typically work well for smaller networks and use Ethernet
cables for networking. It is easy to maintain and troubleshoot in a bus
network. All the nodes in a bus network are dependant on the backbone and
even if one node fails the remaining nodes work.
Ring Topology
A ring network is circular in shape and every node will have one node on
either side of it. The ring topology is rare to come across because of its
limitations. If there is damaged cable or breakdown in any one of the nodes
then the entire network stops functioning.
Star Topology
A star topology is based on a central node which acts as a hub. A star
topology is common in homes networks where all the computers connect to
the single central computer using it as a hub. The medium used to connect is
the UTP or the untwisted pair cable. In case one node stops functioning or if
there is cable damage the rest of the network would still work.
Tree Topology
The tree topology is a group of star networks put together. The only
difference is that the tree topology follows a hierarchy in structure and the
entire tree is dependant on this hierarchy.
6
Mesh Topology
Mesh topology is a group of nodes which are all connected to each other and
many types of connections are possible in a mesh topology. Every single node
is connected to the other nodes in a mesh topology and the chances of
connection break downs are very minimal in a mesh topology. Mesh topology
is mostly used on a WAN.
Network topologies are the most important part of the communication and the
communication begins in the network. There are many kinds of network, the
cabled network, the wireless technology, mobile technology, satellite
communications and a combination of all these. Wireless network are
increasingly becoming popular among many companies so that they need not
spend too much on cabling and it is convenient too. However there are
security issues in wireless technology and if the network has to be highly
secure then cable is still the best bet.
A company may choose to sue any type of network but they still need a
topology to design the communications system and plan the data flow and
which order data will take while traveling. This is very important and for this
you need to decide one of the topology formats. Even wireless networks need
to conform to a star, mesh, or a tree topology.
In order to set up a network a person should be a network engineer and
should know the functionalities of the network topology from a physical level.
Then there is the logical or the software level where the network needs to be
programmed. However the primary step is at the physical level. Once the
network is set up physically then the software’s can be installed and the
protocols can be configured. Troubleshooting networks at the logical level is
very simple, but the same cannot be said at the physical level. To identify the
problem the network engineer should know the entire functioning of the
network topologies.
Bus Topology
From the name of the network itself many inferences of the network can be
derived. A bus topology in more technical terms means that it is a method of
transmission on networks that uses a common vehicle for transmissions and
thus it is categorized as shared communication. Imagine a bus picking up
various people from one stop and dropping of people as it travels and then
picking a few more. That is what happens in a bus network exactly.
7
However in a Bus topology only one device is allowed to transmit at a given
point of time. The DAP or the Distribute Access Protocol has the information
about which station has to transmit the data. The data that is being
transmitted have frames that will have the source name and the network
address.
Bus Topology Functionality
The bus topology connects each computer on the network into something
called the segment trunk. A bus is usually referred to a cable that connects
end to end and this is used to transmit the signals from one end to the other
end. At every end a terminator is placed so that it understands in which
direction the data is traveling and also the terminator is used to absorb the
signals. If the terminator does not absorb the signal then the same signal is
reflected back to the bus confusing the whole data flow. The bus is considered
to be a passive network because the computers are largely dependant on the
signal that is being transmitted.
Bus Topology Advantages
The advantage of the Bus network is that if one computer fails in the network
the others are still not affected and they continue to work . Bus network is
very simple and easy to set up. If there is an urgent need to set up a network
and perhaps be used on a short term basis then the Bus network is the best
possibility. Bus networks use the least amount of cable to set up making it
cost effective.
Bus Topology Limitations
In the bus network you will need a network connection in order to determine
if the data is being transferred between two nodes. If the data transfer rate is
high then the Bus network does not perform very well because the data
travels in a stream and cannot be overloaded. The bus network is a bit
challenging when you have to troubleshoot the problems. Bus networks are
not suitable as large networks as there are limitations to the number of nodes
you can set up for one single cable. As the number of computers increase in
the network the data transfer rate goes down accordingly and noticeably.
Bus Topology Conclusion
The bus networks in spite of its limitations is considered to be the easiest and
the fastest network that can be set up compared to the other kinds of
network. In bus networks there is a collision handling system which ensures
that data travels without errors and data is delivered correctly.
There is a bus master on the network which ensures that data is flowing in
the right direction and order. All the computers on the bus network however
listen for the signals and they do not hold the responsibility to move the
signal forward. The signal carries forward on its own. So if one computer is
8
not receiving any signals the signal still carries forward without stopping at
the computer that has failed. These days bus networks are less common due
to the advancement of networks and there are much lesser complicated
networks that are easy to operate and efficient. However even these newer
technologies derive their basics from older technologies like the Bus Topology.
Network Architecture
Network architecture is the design of a communications network. It is a
framework for the specification of a network's physical components and their
functional organization and configuration, its operational principles and
procedures, as well as data formats used in its operation.
In telecommunication, the specification of a network architecture may also
include a detailed description of products and services delivered via a
communications network, as well as detailed rate and billing structures under
which services are compensated.
The network architecture of the Internet is predominantly expressed by its
use of the Internet Protocol Suite, rather than a specific model for
interconnecting networks or nodes in the network, or the usage of specific
types of hardware links.
Communication Protocols
A set of rules is needed for any means of communication:
9
Human intercommunication (in pairs or larger groups) requires
rules of conversation (do not speak if someone else is speaking) to
function effectively.

Computers are no different. Consider the following simplistic
analogy:
o
Two computers connected via a single connection -Imagine two people talking via two tin cans connected via piece
of string:

If the two people talk at the same time then we get what is
known (in networking terms) as data collision.
Therefore, we need regulations and rules to how we
communicate over a computer network. For example to remote login
(telnet), FTP or email.

The set of rules and regulations is called a Protocol.

Protocols and Architecture
 Layered structure of hardware and software to support exchange
of data between systems/distributed applications
 Set of rules for transmission of data between systems
 One or more common protocols for every layer
Protocols Characteristics
1. Direct/indirect communication
A Direct communication
 Point-to-point link
 Two entities share a link, allowing direct communication
 Entities may also connect through a number of intermediate hosts,
bringing in the issue of access control, making the protocol more
complex
B
indirect communication network
 Entities depend on other entities for data exchange
 Entities may be connected over local network (Ethernet) or may belong
to different networks (internet)
2. Monolithic/structured protocol
A Monolithic protocol
 All protocol logic (for every layer) is combined into one unit
 Problem in changing any aspect of the protocol (such as virtual
circuit request)
B Structured protocol
 Set of protocols with hierarchical/layered structure Clearly shows
the distinction between different layers of logic
 Hardware/software used to implement communications with
structured protocol
10
3 Symmetric/asymmetric protocol
A Symmetric protocol
 Involves communication between peer entitie
B Asymmetric protocol
 Involves client/server type of relationship
4 . Standard/nonstandard protocol
A Standard protocol
 Commonly accepted protocols that have been agreed on by a
standards body
B Nonstandard protocol
 Built for specific communications situation Functions
Functions of Protocols:
Connection Control





data transfer can be either connectionless or connection-oriented
in connectionless transfers each PDU is independent of all others sent
in connection-oriented transfers a logical connection is established prior
to the data transfer, then each PDU sent has a sequence number
sequencing supports ordered delivery, flow control, and error control
connection control function of a protocol manages the establishment
and disconnection of a link

Ordered Delivery
o PDUs may travel different routes, and may arrive out of order
with respect to the transmitting order
o a protocol must be able to reorder the PDUs in the correct order

Flow Control
o a receiver may not be able to process the PDUs as fast as the
transmitter can send them
o a receiver requires some way of limiting the rate of the
transmitter
o flow control functions ensure that data sent does not overwhelm
the receiver

Error Control
o PDUs can be lost or damaged
o methods for detecting and correcting errors is required
o retransmission upon failure of acknowledgement of receipt is a
common method for handling lost PDUs
o cyclic redundancy checks are often used to detect damaged PDUs
11

Addressing
o a protocol must have a means for identifying a particular user
using a particular application on a particular host residing on
some network
o addressing is a means for protocols to identify these needs

Multiplexing
o multiplexing is used to improve the efficiency and usage of the
transmission medium
o functions exist to support frequency or time division multiplexing
as well as multiplexing the connections

Transmission Services
o other types of services to the upper layers exist
o three common services are: priority, grade of service, and
security
12
Session 2:
OSI Network Model
OSI model
7. Application layer
6. Presentation layer
5. Session layer
4. Transport layer
3. Network layer
2. Data link layer
1. Physical layer
Open Systems Interconnection (OSI) model is a reference model developed
by ISO (International Organization for Standardization) in 1984, as a
conceptual framework of standards for communication in the network across
different equipment and applications by different vendors. It is now
considered the primary architectural model for inter-computing and
internetworking communications. Most of the network communication
protocols used today have a structure based on the OSI model. The OSI
model defines the communications process into 7 layers, which divides the
tasks involved with moving information between networked computers into
seven smaller, more manageable task groups. A task or group of tasks is then
assigned to each of the seven OSI layers. Each layer is reasonably selfcontained so that the tasks assigned to each layer can be implemented
independently. This enables the solutions offered by one layer to be updated
without adversely affecting the other layers.
13
The OSI 7 layers model has clear characteristics. Layers 7 through 4 deal with
end to end communications between data source and destinations. Layers 3
to 1 deal with communications between network devices.
On the other hand, the seven layers of the OSI model can be divided into two
groups: upper layers (layers 7, 6 & 5) and lower layers (layers 4, 3, 2, 1).
The upper layers of the OSI model deal with application issues and generally
are implemented only in software. The highest layer, the application layer, is
closest to the end user. The lower layers of the OSI model handle data
transport issues. The physical layer and the data link layer are implemented
in hardware and software. The lowest layer, the physical layer, is closest to
the physical network medium (the wires, for example) and is responsible for
placing data on the medium.
Physical Layer
The Physical
Layer defines
the electrical and physical specifications
for
devices. In particular, it defines the relationship between a device and a
transmission medium, such as a copper or optical cable. This includes the
layout of pins, voltages, cable specifications, hubs, repeaters, network
adapters, host bus adapters (HBA used in storage area networks) and more.
Its main task is the transmission of a stream of bits over a communication
channel.
Data Linking Layer
The Data Link Layer provides the functional and procedural means to transfer
data between network entities and to detect and possibly correct errors that
may occur in the Physical Layer. Originally, this layer was intended for pointto-point and point-to-multipoint media, characteristic of wide area media in
the telephone system. Local area network architecture, which included
broadcast-capable multiaccess media, was developed independently of the
ISO work in IEEE Project 802. IEEE work assumed sublayering and
management functions not required for WAN use. In modern practice, only
error detection, not flow control using sliding window, is present in data link
protocols such as Point-to-Point Protocol (PPP), and, on local area networks,
the IEEE 802.2 LLC layer is not used for most protocols on the Ethernet, and
on other local area networks, its flow control and acknowledgment
mechanisms
are
rarely
used.
Sliding-window
flow
control
and
acknowledgment is used at the Transport Layer by protocols such as TCP, but
is still used in niches where X.25 offers performance advantages. Simply, its
main job is to create and recognize the frame boundary. This can be done by
attaching special bit patterns to the beginning and the end of the frame. The
input data is broken up into frames.
Network Layer
The Network Layer provides the functional and procedural means of
transferring variable length data sequences from a source host on one
14
network to a destination host on a different network, while maintaining the
quality of service requested by the Transport Layer (in contrast to the data
link layer which connects hosts within the same network). The Network Layer
performs network routing functions, and might also perform fragmentation
and reassembly, and report delivery errors. Routers operate at this layer—
sending data throughout the extended network and making the Internet
possible. This is a logical addressing scheme – values are chosen by the
network engineer. The addressing scheme is not hierarchical. It controls the
operation
of
the subnet and
determine
the routing strategies
between IMP and insures that all the packs are correctly received at the
destination in the proper order.
Transport Layer
The Transport Layer provides transparent transfer of data between end users,
providing reliable data transfer services to the upper layers. The Transport
Layer controls the reliability of a given link through flow control,
segmentation/desegmentation, and error control. Some protocols are state
and connection oriented. This means that the Transport Layer can keep track
of the segments and retransmit those that fail. The Transport layer also
provides the acknowledgement of the successful data transmission and sends
the next data if no errors occurred. Some Transport Layer protocols, for
example TCP, but not UDP, support virtual circuits provide connection
oriented
communication
over
an
underlying
packet
oriented datagram network .Where it assures the delivery of packets in the
order in which they were sent and assure that they are free of errors
.The datagram transportation deliver the packets randomly and broadcast it
to multiple nodes. Notes: The transport layer multiplexes several streams on
to 1 physical channel. The transport headers tells which message belongs to
which connnection.
The Session Layer
This Layer provides a user interface to the network where the user negotiates
to establish a connection. The user must provide the remote address to be
contacted. The operation of setting up a session between two processes is
called "Binding". In some protocols it is merged with the transport layer. Its
main work is to transfer data from the other application to this application so
this application is mainly used for transferred layer.
Presentation Layer
The Presentation Layer establishes context between Application Layer entities,
in which the higher-layer entities may use different syntax and semantics if
the presentation service provides a mapping between them. If a mapping is
available, presentation service data units are encapsulated into session
protocol data units, and passed down the stack.This layer provides
independence from data representation (e.g., encryption) by translating
between application and network formats. The presentation layer transforms
15
data into the form that the application accepts. This layer formats and
encrypts data to be sent across a network. It is sometimes called the syntax
layer. The original presentation structure used the basic encoding rules of
Abstract Syntax Notation One (ASN.1), with capabilities such as converting an
EBCDIC-coded text file to an ASCII-coded file, or serialization of objects and
other data structures from and to XML.
Application Layer
The Application Layer is the OSI layer closest to the end user, which means
that both the OSI application layer and the user interact directly with the
software application. This layer interacts with software applications that
implement a communicating component. Such application programs fall
outside the scope of the OSI model. Application layer functions typically
include identifying communication partners, determining resource availability,
and synchronizing communication. When identifying communication partners,
the application layer determines the identity and availability of communication
partners for an application with data to transmit.
The specific description for each layer is as follows:
Layer 7:Application Layer
Defines interface to user processes for communication and data transfer in
network
Provides standardized services such as virtual terminal, file and job transfer
and operations
Layer 6:Presentation Layer
Masks the differences of data formats between dissimilar systems
Specifies architecture-independent data transfer format
Encodes and decodes data; Encrypts and decrypts data; Compresses and
decompresses data
Layer 5:Session Layer
Manages user sessions and dialogues
Controls establishment and termination of logic links between users
Reports upper layer errors
Layer 4:Transport Layer
16
Manages end-to-end message delivery in network
Provides reliable and sequential packet delivery through error recovery and
flow control mechanisms
Provides connectionless oriented packet delivery
Layer 3:Network Layer
Determines how data are transferred between network devices
Routes packets according to unique network device addresses
Provides flow and congestion control to prevent network resource depletion
Layer 2:Data Link Layer
Defines procedures for operating the communication links
Frames packets
Detects and corrects packets transmit errors
Layer 1:Physical Layer
Defines physical means of sending data over network devices
Interfaces between network medium and devices
Defines optical, electrical and mechanical characteristics
Service Access Point:
A Service Access Point (SAP) is an identifying label for network endpoints
used in Open Systems Interconnection (OSI) networking.
When using the OSI Network Layer (CONS or CLNS), the base for constructing
an address for a network element is an NSAP address, similar in concept to
an IP address. OSI Application Layer protocols as well as Asynchronous
Transfer Mode (ATM) can use Transport (TSAP), Session (SSAP) or
Presentation (PSAP) Service Access Points to specify a destination address for
a connection. These SAPs consist of NSAP addresses combined with optional
transport, session and presentation selectors, which can differentiate at any of
the three layers between multiple services at that layer provided by a network
element.
The SAP is a conceptual location at which one OSI layer can request the
services of another OSI layer. As an example, PD-SAP or PLME-SAP in IEEE
17
802.15.4 can be mentioned, where the Media Access Control (MAC) layer
requests certain services from the Physical Layer. Service access points are
also used in IEEE 802.2 Logical Link Control in Ethernet and similar Data Link
Layerprotocols.
The TSAP is an expansion of the NSAP.
18
Session 3:
Data Link Layer Design Issues
The data link layer has a number of specific functions it can carry out. These
functions include
1. Providing a well-defined service interface to the network layer.
2. Dealing with transmission errors.
3. Regulating the flow of data so that slow receivers are not swamped by
fast senders.
To accomplish these goals, the data link layer takes the packets it gets from
the network layer and encapsulates them into frames for transmission. Each
frame contains a frame header, a payload field for holding the packet, and a
frame trailer, as illustrated in Fig. 3-1. Frame management forms the heart
of what the data link layer does. In the following sections we will examine all
the above-mentioned issues in detail.
Figure 3-1. Relationship between packets and frames.
Although this chapter is explicitly about the data link layer and the data link
protocols, many of the principles we will study here, such as error control and
flow control, are found in transport and other protocols as well. In fact, in
many networks, these functions are found only in the upper layers and not in
the data link layer. However, no matter where they are found, the principles
are pretty much the same, so it does not really matter where we study them.
In the data link layer they often show up in their simplest and purest forms,
making this a good place to examine them in detail.
3.1.1. Services Provided to the Network Layer
The function of the data link layer is to provide services to the network layer.
The principal service is transferring data from the network layer on the source
machine to the network layer on the destination machine. On the source
machine is an entity, call it a process, in the network layer that hands some
bits to the data link layer for transmission to the destination. The job of the
19
data link layer is to transmit the bits to the destination machine so they can
be handed over to the network layer there, as shown in Fig. 3-2(a). The
actual transmission follows the path of Fig. 3-2(b), but it is easier to think in
terms of two data link layer processes communicating using a data link
protocol. For this reason, we will implicitly use the model of Fig. 32(a)throughout this chapter.
Figure 3-2. (a) Virtual communication. (b) Actual communication.
The data link layer can be designed to offer various services. The actual
services offered can vary from system to system. Three reasonable
possibilities that are commonly provided are
1. Unacknowledged connectionless service.
2. Acknowledged connectionless service.
3. Acknowledged connection-oriented service.
Let us consider each of these in turn.
Unacknowledged connectionless service consists of having the source machine
send independent frames to the destination machine without having the
destination machine acknowledge them. No logical connection is established
beforehand or released afterward. If a frame is lost due to noise on the line,
no attempt is made to detect the loss or recover from it in the data link layer.
This class of service is appropriate when the error rate is very low so that
recovery is left to higher layers. It is also appropriate for real-time traffic,
such as voice, in which late data are worse than bad data. Most LANs use
unacknowledged connectionless service in the data link layer.
20
The next step up in terms of reliability is acknowledged connectionless
service. When this service is offered, there are still no logical connections
used, but each frame sent is individually acknowledged. In this way, the
sender knows whether a frame has arrived correctly. If it has not arrived
within a specified time interval, it can be sent again. This service is useful
over unreliable channels, such as wireless systems.
It is perhaps worth emphasizing that providing acknowledgements in the data
link layer is just an optimization, never a requirement. The network layer can
always send a packet and wait for it to be acknowledged. If the
acknowledgement is not forthcoming before the timer expires, the sender can
just send the entire message again. The trouble with this strategy is that
frames usually have a strict maximum length imposed by the hardware and
network layer packets do not. If the average packet is broken up into, say, 10
frames, and 20 percent of all frames are lost, it may take a very long time for
the packet to get through. If individual frames are acknowledged and
retransmitted, entire packets get through much faster. On reliable channels,
such as fiber, the overhead of a heavyweight data link protocol may be
unnecessary, but on wireless channels, with their inherent unreliability, it is
well worth the cost.
Getting back to our services, the most sophisticated service the data link layer
can provide to the network layer is connection-oriented service. With this
service, the source and destination machines establish a connection before
any data are transferred. Each frame sent over the connection is numbered,
and the data link layer guarantees that each frame sent is indeed received.
Furthermore, it guarantees that each frame is received exactly once and that
all frames are received in the right order. With connectionless service, in
contrast, it is conceivable that a lost acknowledgement causes a packet to be
sent several times and thus received several times. Connection-oriented
service, in contrast, provides the network layer processes with the equivalent
of a reliable bit stream.
When connection-oriented service is used, transfers go through three distinct
phases. In the first phase, the connection is established by having both sides
initialize variables and counters needed to keep track of which frames have
been received and which ones have not. In the second phase, one or more
frames are actually transmitted. In the third and final phase, the connection is
released, freeing up the variables, buffers, and other resources used to
maintain the connection.
Consider a typical example: a WAN subnet consisting of routers connected by
point-to-point leased telephone lines. When a frame arrives at a router, the
hardware checks it for errors (using techniques we will study late in this
chapter), then passes the frame to the data link layer software (which might
be embedded in a chip on the network interface board). The data link layer
21
software checks to see if this is the frame expected, and if so, gives the
packet contained in the payload field to the routing software. The routing
software then chooses the appropriate outgoing line and passes the packet
back down to the data link layer software, which then transmits it. The flow
over two routers is shown in Fig. 3-3.
Figure 3-3. Placement of the data link protocol.
The routing code frequently wants the job done right, that is, with reliable,
sequenced connections on each of the point-to-point lines. It does not want to
be bothered too often with packets that got lost on the way. It is up to the
data link protocol, shown in the dotted rectangle, to make unreliable
communication lines look perfect or, at least, fairly good. As an aside,
although we have shown multiple copies of the data link layer software in
each router, in fact, one copy handles all the lines, with different tables and
data structures for each one.
3.1.2. Framing
To provide service to the network layer, the data link layer must use the
service provided to it by the physical layer. What the physical layer does is
accept a raw bit stream and attempt to deliver it to the destination. This bit
stream is not guaranteed to be error free. The number of bits received may
be less than, equal to, or more than the number of bits transmitted, and they
may have different values. It is up to the data link layer to detect and, if
necessary, correct errors.
The usual approach is for the data link layer to break the bit stream up into
discrete frames and compute the checksum for each frame. (Checksum
algorithms will be discussed later in this chapter.) When a frame arrives at the
destination, the checksum is recomputed. If the newly-computed checksum is
22
different from the one contained in the frame, the data link layer knows that
an error has occurred and takes steps to deal with it (e.g., discarding the bad
frame and possibly also sending back an error report).
Breaking the bit stream up into frames is more difficult than it at first
appears. One way to achieve this framing is to insert time gaps between
frames, much like the spaces between words in ordinary text. However,
networks rarely make any guarantees about timing, so it is possible these
gaps might be squeezed out or other gaps might be inserted during
transmission.
Since it is too risky to count on timing to mark the start and end of each
frame, other methods have been devised. In this section we will look at four
methods:
1. Character count.
2. Flag bytes with byte stuffing.
3. Starting and ending flags, with bit stuffing.
4. Physical layer coding violations.
The first framing method uses a field in the header to specify the number of
characters in the frame. When the data link layer at the destination sees the
character count, it knows how many characters follow and hence where the
end of the frame is. This technique is shown in Fig. 3-4(a) for four frames of
sizes 5, 5, 8, and 8 characters, respectively.
Figure 3-4. A character stream. (a) Without errors. (b) With one
error.
The trouble with this algorithm is that the count can be garbled by a
transmission error. For example, if the character count of 5 in the second
23
frame of Fig. 3-4(b)becomes a 7, the destination will get out of
synchronization and will be unable to locate the start of the next frame. Even
if the checksum is incorrect so the destination knows that the frame is bad, it
still has no way of telling where the next frame starts. Sending a frame back
to the source asking for a retransmission does not help either, since the
destination does not know how many characters to skip over to get to the
start of the retransmission. For this reason, the character count method is
rarely used anymore.
The second framing method gets around the problem of resynchronization
after an error by having each frame start and end with special bytes. In the
past, the starting and ending bytes were different, but in recent years most
protocols have used the same byte, called a flag byte, as both the starting
and ending delimiter, as shown in Fig. 3-5(a) as FLAG. In this way, if the
receiver ever loses synchronization, it can just search for the flag byte to find
the end of the current frame. Two consecutive flag bytes indicate the end of
one frame and start of the next one.
Figure 3-5. (a) A frame delimited by flag bytes. (b) Four examples of
byte sequences before and after byte stuffing.
A serious problem occurs with this method when binary data, such as object
programs or floating-point numbers, are being transmitted. It may easily
happen that the flag byte’s bit pattern occurs in the data. This situation will
usually interfere with the framing. One way to solve this problem is to have
the sender’s data link layer insert a special escape byte (ESC) just before
each ‘‘accidental’’ flag byte in the data. The data link layer on the receiving
end removes the escape byte before the data are given to the network layer.
This technique is called byte stuffing orcharacter stuffing. Thus, a framing
24
flag byte can be distinguished from one in the data by the absence or
presence of an escape byte before it.
Of course, the next question is: What happens if an escape byte occurs in the
middle of the data? The answer is that it, too, is stuffed with an escape byte.
Thus, any single escape byte is part of an escape sequence, whereas a
doubled one indicates that a single escape occurred naturally in the data.
Some examples are shown in Fig. 3-5(b). In all cases, the byte sequence
delivered after destuffing is exactly the same as the original byte sequence.
The byte-stuffing scheme depicted in Fig. 3-5 is a slight simplification of the
one used in the PPP protocol that most home computers use to communicate
with their Internet service provider. We will discuss PPP later in this chapter.
A major disadvantage of using this framing method is that it is closely tied to
the use of 8-bit characters. Not all character codes use 8-bit characters. For
example. UNICODE uses 16-bit characters, As networks developed, the
disadvantages of embedding the character code length in the framing
mechanism became more and more obvious, so a new technique had to be
developed to allow arbitrary sized characters.
The new technique allows data frames to contain an arbitrary number of bits
and allows character codes with an arbitrary number of bits per character. It
works like this. Each frame begins and ends with a special bit pattern,
01111110 (in fact, a flag byte). Whenever the sender’s data link layer
encounters five consecutive 1s in the data, it automatically stuffs a 0 bit into
the outgoing bit stream. This bit stuffing is analogous to byte stuffing, in
which an escape byte is stuffed into the outgoing character stream before a
flag byte in the data.
When the receiver sees five consecutive incoming 1 bits, followed by a 0 bit, it
automatically destuffs (i.e., deletes) the 0 bit. Just as byte stuffing is
completely transparent to the network layer in both computers, so is bit
stuffing. If the user data contain the flag pattern, 01111110, this flag is
transmitted as 011111010 but stored in the receiver’s memory as
01111110. Figure 3-6 gives an example of bit stuffing.
Figure 3-6. Bit stuffing. (a) The original data. (b) The data as they
appear on the line. (c) The data as they are stored in the receiver’s
memory after destuffing.
25
With bit stuffing, the boundary between two frames can be unambiguously
recognized by the flag pattern. Thus, if the receiver loses track of where it is,
all it has to do is scan the input for flag sequences, since they can only occur
at frame boundaries and never within the data.
The last method of framing is only applicable to networks in which the
encoding on the physical medium contains some redundancy. For example,
some LANs encode 1 bit of data by using 2 physical bits. Normally, a 1 bit is a
high-low pair and a 0 bit is a low-high pair. The scheme means that every
data bit has a transition in the middle, making it easy for the receiver to
locate the bit boundaries. The combinations high-high and low-low are not
used for data but are used for delimiting frames in some protocols.
As a final note on framing, many data link protocols use a combination of a
character count with one of the other methods for extra safety. When a frame
arrives, the count field is used to locate the end of the frame. Only if the
appropriate delimiter is present at that position and the checksum is correct is
the frame accepted as valid. Otherwise, the input stream is scanned for the
next delimiter.
3.1.3. Error Control
Having solved the problem of marking the start and end of each frame, we
come to the next problem: how to make sure all frames are eventually
delivered to the network layer at the destination and in the proper order.
Suppose that the sender just kept outputting frames without regard to
whether they were arriving properly. This might be fine for unacknowledged
connectionless service, but would most certainly not be fine for reliable,
connection-oriented service.
The usual way to ensure reliable delivery is to provide the sender with some
feedback about what is happening at the other end of the line. Typically, the
protocol calls for the receiver to send back special control frames bearing
positive or negative acknowledgements about the incoming frames. If the
sender receives a positive acknowledgement about a frame, it knows the
frame has arrived safely. On the other hand, a negative acknowledgement
means that something has gone wrong, and the frame must be transmitted
again.
An additional complication comes from the possibility that hardware troubles
may cause a frame to vanish completely (e.g., in a noise burst). In this case,
the receiver will not react at all, since it has no reason to react. It should be
clear that a protocol in which the sender transmits a frame and then waits for
26
an acknowledgement, positive or negative, will hang forever if a frame is ever
lost due to, for example, malfunctioning hardware.
This possibility is dealt with by introducing timers into the data link layer.
When the sender transmits a frame, it generally also starts a timer. The timer
is set to expire after an interval long enough for the frame to reach the
destination, be processed there, and have the acknowledgement propagate
back to the sender. Normally, the frame will be correctly received and the
acknowledgement will get back before the timer runs out, in which case the
timer will be canceled.
However, if either the frame or the acknowledgement is lost, the timer will go
off, alerting the sender to a potential problem. The obvious solution is to just
transmit the frame again. However, when frames may be transmitted multiple
times there is a danger that the receiver will accept the same frame two or
more times and pass it to the network layer more than once. To prevent this
from happening, it is generally necessary to assign sequence numbers to
outgoing frames, so that the receiver can distinguish retransmissions from
originals.
The whole issue of managing the timers and sequence numbers so as to
ensure that each frame is ultimately passed to the network layer at the
destination exactly once, no more and no less, is an important part of the
data link layer’s duties. Later in this chapter, we will look at a series of
increasingly sophisticated examples to see how this management is done.
3.1.4. Flow Control
Another important design issue that occurs in the data link layer (and higher
layers as well) is what to do with a sender that systematically wants to
transmit frames faster than the receiver can accept them. This situation can
easily occur when the sender is running on a fast (or lightly loaded) computer
and the receiver is running on a slow (or heavily loaded) machine. The sender
keeps pumping the frames out at a high rate until the receiver is completely
swamped. Even if the transmission is error free, at a certain point the receiver
will simply be unable to handle the frames as they arrive and will start to lose
some. Clearly, something has to be done to prevent this situation.
Two approaches are commonly used. In the first one, feedback-based flow
control, the receiver sends back information to the sender giving it
permission to send more data or at least telling the sender how the receiver is
doing. In the second one, rate-based flow control, the protocol has a builtin mechanism that limits the rate at which senders may transmit data,
without using feedback from the receiver. In this chapter we will study
feedback-based flow control schemes because rate-based schemes are never
used in the data link layer. We will look at rate-based schemes in Chap. 5.
27
Various feedback-based flow control schemes are known, but most of them
use the same basic principle. The protocol contains well-defined rules about
when a sender may transmit the next frame. These rules often prohibit
frames from being sent until the receiver has granted permission, either
implicitly or explicitly. For example, when a connection is set up, the receiver
might say: ‘‘You may send me n frames now, but after they have been sent,
do not send any more until I have told you to continue.’’ We will examine the
details shortly.
3.3. Elementary Data Link Protocols
To introduce the subject of protocols, we will begin by looking at three
protocols of increasing complexity. For interested readers, a simulator for
these and subsequent protocols is available via the Web (see the preface).
Before we look at the protocols, it is useful to make explicit some of the
assumptions underlying the model of communication. To start with, we
assume that in the physical layer, data link layer, and network layer are
independent processes that communicate by passing messages back and
forth. In many cases, the physical and data link layer processes will be
running on a processor inside a special network I/O chip and the network
layer code will be running on the main CPU. However, other implementations
are also possible (e.g., three processes inside a single I/O chip; or the
physical and data link layers as procedures called by the network layer
process). In any event, treating the three layers as separate processes makes
the discussion conceptually cleaner and also serves to emphasize the
independence of the layers.
Another key assumption is that machine A wants to send a long stream of
data to machine B, using a reliable, connection-oriented service. Later, we will
consider the case where B also wants to send data to A simultaneously. A is
assumed to have an infinite supply of data ready to send and never has to
wait for data to be produced. Instead, when A’s data link layer asks for data,
the network layer is always able to comply immediately. (This restriction, too,
will be dropped later.)
We also assume that machines do not crash. That is, these protocols deal with
communication errors, but not the problems caused by computers crashing
and rebooting.
As far as the data link layer is concerned, the packet passed across the
interface to it from the network layer is pure data, whose every bit is to be
delivered to the destination’s network layer. The fact that the destination’s
network layer may interpret part of the packet as a header is of no concern to
the data link layer.
28
When the data link layer accepts a packet, it encapsulates the packet in a
frame by adding a data link header and trailer to it (see Fig.2-1). Thus, a
frame consists of an embedded packet, some control information (in the
header), and a checksum (in the trailer). The frame is then transmitted to the
data link layer on the other machine. We will assume that there exist suitable
library
procedures to_physical_layer to
send
a
frame
and from_physical_layer to receive a frame. The transmitting hardware
computes and appends the checksum (thus creating the trailer), so that the
datalink layer software need not worry about it. The polynomial algorithm
discussed earlier in this chapter might be used, for example.
Initially, the receiver has nothing to do. It just sits around waiting for
something to happen. In the example protocols of this chapter we will indicate
that the data link layer is waiting for something to happen by the procedure
call wait_for_event(&event). This procedure only returns when something has
happened (e.g., a frame has arrived). Upon return, the variable event tells
what happened. The set of possible events differs for the various protocols to
be described and will be defined separately for each protocol. Note that in a
more realistic situation, the data link layer will not sit in a tight loop waiting
for an event, as we have suggested, but will receive an interrupt, which will
cause it to stop whatever it was doing and go handle the incoming frame.
Nevertheless, for simplicity we will ignore all the details of parallel activity
within the data link layer and assume that it is dedicated full time to handling
just our one channel.
When a frame arrives at the receiver, the hardware computes the checksum.
If the checksum is incorrect (i.e., there was a transmission error), the data
link layer is so informed (event = cksum_err). If the inbound frame arrived
undamaged, the data link layer is also informed (event = frame_arrival) so
that it can acquire the frame for inspection using from_physical_layer. As
soon as the receiving data link layer has acquired an undamaged frame, it
checks the control information in the header, and if everything is all right,
passes the packet portion to the network layer. Under no circumstances is a
frame header ever given to a network layer.
There is a good reason why the network layer must never be given any part
of the frame header: to keep the network and data link protocols completely
separate. As long as the network layer knows nothing at all about the data
link protocol or the frame format, these things can be changed without
requiring changes to the network layer’s software. Providing a rigid interface
between network layer and data link layer greatly simplifies the software
design because communication protocols in different layers can evolve
independently.
29
A frame is composed of four fields: kind, seq, ack, and info, the first three of
which contain control information and the last of which may contain actual
data to be transferred. These control fields are collectively called the frame
header.
The kind field tells whether there are any data in the frame, because some of
the protocols distinguish frames containing only control information from
those containing data as well. The seq and ack fields are used for sequence
numbers and acknowledgements, respectively; their use will be described in
more detail later. The infofield of a data frame contains a single packet;
the info field of a control frame is not used. A more realistic implementation
would use a variable-length info field, omitting it altogether for control
frames.
Again, it is important to realize the relationship between a packet and a
frame. The network layer builds a packet by taking a message from the
transport layer and adding the network layer header to it. This packet is
passed to the data link layer for inclusion in the info field of an outgoing
frame. When the frame arrives at the destination, the data link layer extracts
the packet from the frame and passes the packet to the network layer. In this
manner, the network layer can act as though machines can exchange packets
directly.
In most of the protocols, we assume that the channel is unreliable and loses
entire frames upon occasion. To be able to recover from such calamities, the
sending data link layer must start an internal timer or clock whenever it sends
a frame. If no reply has been received within a certain predetermined time
interval, the clock times out and the data link layer receives an interrupt
signal.
3.3.1. An Unrestricted Simplex Protocol
As an initial example we will consider a protocol that is as simple as it can be.
Data are transmitted in one direction only. Both the transmitting and
receiving network layers are always ready. Processing time can be ignored.
Infinite buffer space is available. And best of all, the communication channel
between the data link layers never damages or loses frames. This thoroughly
unrealistic protocol, which we will nickname ‘‘utopia,’’
The protocol consists of two distinct procedures, a sender and a receiver. The
sender runs in the data link layer of the source machine, and the receiver
runs in the data link layer of the destination machine. No sequence numbers
or acknowledgements are used here, so MAX_SEQ is not needed. The only
event type possible is frame_arrival (i.e., the arrival of an undamaged frame).
30
The sender is in an infinite while loop just pumping data out onto the line as
fast as it can. The body of the loop consists of three actions: go fetch a packet
from the (always obliging) network layer, construct an outbound frame using
the variable s, and send the frame on its way. Only the info field of the frame
is used by this protocol, because the other fields have to do with error and
flow control and there are no errors or flow control restrictions here.
The receiver is equally simple. Initially, it waits for something to happen, the
only possibility being the arrival of an undamaged frame. Eventually, the
frame arrives and the procedure wait_for_event returns, with event set
to frame_arrival (which
is
ignored
anyway).
The
call
to from_physical_layer removes the newly arrived frame from the hardware
buffer and puts it in the variable r, where the receiver code can get at it.
Finally, the data portion is passed on to the network layer, and the data link
layer settles back to wait for the next frame, effectively suspending itself until
the frame arrives.
3.3.2. A Simplex Stop-and-Wait Protocol
Now we will drop the most unrealistic restriction used in protocol 1: the ability
of the receiving network layer to process incoming data infinitely quickly (or
equivalently, the presence in the receiving data link layer of an infinite
amount of buffer space in which to store all incoming frames while they are
waiting their respective turns). The communication channel is still assumed to
be error free however, and the data traffic is still simplex.
The main problem we have to deal with here is how to prevent the sender
from flooding the receiver with data faster than the latter is able to process
them.
In
essence,
if
the
receiver
requires
a
time
Δt to
execute from_physical_layer plus to_network_layer, the sender must transmit
at an average rate less than one frame per time Δt. Moreover, if we assume
that no automatic buffering and queueing are done within the receiver’s
hardware, the sender must never transmit a new frame until the old one has
been fetched by from_physical_layer, lest the new one overwrite the old one.
In certain restricted circumstances (e.g., synchronous transmission and a
receiving data link layer fully dedicated to processing the one input line), it
might be possible for the sender to simply insert a delay into protocol 1 to
slow it down sufficiently to keep from swamping the receiver. However, more
usually, each data link layer will have several lines to attend to, and the time
interval between a frame arriving and its being processed may vary
considerably. If the network designers can calculate the worst-case behavior
of the receiver, they can program the sender to transmit so slowly that even if
every frame suffers the maximum delay, there will be no overruns. The
trouble with this approach is that it is too conservative. It leads to a
bandwidth utilization that is far below the optimum, unless the best and worst
31
cases are almost the same (i.e., the variation in the data link layer’s reaction
time is small).
A more general solution to this dilemma is to have the receiver provide
feedback to the sender. After having passed a packet to its network layer, the
receiver sends a little dummy frame back to the sender which, in effect, gives
the sender permission to transmit the next frame. After having sent a frame,
the sender is required by the protocol to bide its time until the little dummy
(i.e., acknowledgement) frame arrives. Using feedback from the receiver to
let the sender know when it may send more data is an example of the flow
control mentioned earlier.
Protocols in which the sender sends one frame and then waits for an
acknowledgement before proceeding are called stop-and-wait
Although data traffic in this example is simplex, going only from the sender to
the receiver, frames do travel in both directions. Consequently, the
communication channel between the two data link layers needs to be capable
of bidirectional information transfer. However, this protocol entails a strict
alternation of flow: first the sender sends a frame, then the receiver sends a
frame, then the sender sends another frame, then the receiver sends another
one, and so on. A half- duplex physical channel would suffice here.
As in protocol 1, the sender starts out by fetching a packet from the network
layer, using it to construct a frame, and sending it on its way. But now, unlike
in protocol 1, the sender must wait until an acknowledgement frame arrives
before looping back and fetching the next packet from the network layer. The
sending data link layer need not even inspect the incoming frame: there is
only one possibility. The incoming frame is always an acknowledgement.
The only difference between receiver1 and receiver2 is that after delivering a
packet to the network layer, receiver2 sends an acknowledgement frame back
to the sender before entering the wait loop again. Because only the arrival of
the frame back at the sender is important, not its contents, the receiver need
not put any particular information in it.
3.3.3. A Simplex Protocol for a Noisy Channel
Now let us consider the normal situation of a communication channel that
makes errors. Frames may be either damaged or lost completely. However,
we assume that if a frame is damaged in transit, the receiver hardware will
detect this when it computes the checksum. If the frame is damaged in such a
way that the checksum is nevertheless correct, an unlikely occurrence, this
protocol (and all other protocols) can fail (i.e., deliver an incorrect packet to
the network layer).
32
At first glance it might seem that a variation of protocol 2 would work: adding
a timer. The sender could send a frame, but the receiver would only send an
acknowledgement frame if the data were correctly received. If a damaged
frame arrived at the receiver, it would be discarded. After a while the sender
would time out and send the frame again. This process would be repeated
until the frame finally arrived intact.
The above scheme has a fatal flaw in it. Think about the problem and try to
discover what might go wrong before reading further.
To see what might go wrong, remember that it is the task of the data link
layer processes to provide error-free, transparent communication between
network layer processes. The network layer on machine A gives a series of
packets to its data link layer, which must ensure that an identical series of
packets are delivered to the network layer on machine B by its data link layer.
In particular, the network layer on B has no way of knowing that a packet has
been lost or duplicated, so the data link layer must guarantee that no
combination of transmission errors, however unlikely, can cause a duplicate
packet to be delivered to a network layer.
Consider the following scenario:
1. The network layer on A gives packet 1 to its data link layer. The packet
is correctly received at B and passed to the network layer on B. B sends
an acknowledgement frame back to A.
2. The acknowledgement frame gets lost completely. It just never arrives
at all. Life would be a great deal simpler if the channel mangled and
lost only data frames and not control frames, but sad to say, the
channel is not very discriminating.
3. The data link layer on A eventually times out. Not having received an
acknowledgement, it (incorrectly) assumes that its data frame was lost
or damaged and sends the frame containing packet 1 again.
4. The duplicate frame also arrives at the data link layer on B perfectly
and is unwittingly passed to the network layer there. If A is sending a
file to B, part of the file will be duplicated (i.e., the copy of the file
made by B will be incorrect and the error will not have been detected).
In other words, the protocol will fail.
Clearly, what is needed is some way for the receiver to be able to distinguish
a frame that it is seeing for the first time from a retransmission. The obvious
way to achieve this is to have the sender put a sequence number in the
header of each frame it sends. Then the receiver can check the sequence
33
number of each arriving frame to see if it is a new frame or a duplicate to be
discarded.
Since a small frame header is desirable, the question arises: What is the
minimum number of bits needed for the sequence number? The only
ambiguity in this protocol is between a frame, m, and its direct
successor, m + 1. If frame m is lost or damaged, the receiver will not
acknowledge it, so the sender will keep trying to send it. Once it has been
correctly received, the receiver will send an acknowledgement to the sender.
It is here that the potential trouble crops up. Depending upon whether the
acknowledgement frame gets back to the sender correctly or not, the sender
may try to send m or m + 1.
The event that triggers the sender to start sending frame m + 2 is the arrival
of an acknowledgement for frame m + 1. But this implies that m has been
correctly received, and furthermore that its acknowledgement has also been
correctly received by the sender (otherwise, the sender would not have begun
with m + 1, let alone m + 2). As a consequence, the only ambiguity is
between a frame and its immediate predecessor or successor, not between
the predecessor and successor themselves.
A 1-bit sequence number (0 or 1) is therefore sufficient. At each instant of
time, the receiver expects a particular sequence number next. Any arriving
frame containing the wrong sequence number is rejected as a duplicate.
When a frame containing the correct sequence number arrives, it is accepted
and passed to the network layer. Then the expected sequence number is
incremented modulo 2 (i.e., 0 becomes 1 and 1 becomes 0).
An example of this kind of protocol is shown in Fig. 3-12. Protocols in which
the sender waits for a positive acknowledgement before advancing to the next
data item are often called PAR (Positive Acknowledgement with
Retransmission) or ARQ (Automatic Repeat reQuest). Like protocol 2,
this one also transmits data only in one direction.
Protocol 3 differs from its predecessors in that both sender and receiver have
a variable whose value is remembered while the data link layer is in the wait
state. The sender remembers the sequence number of the next frame to send
in next_frame_to_send; the receiver remembers the sequence number of the
next frame expected inframe_expected. Each protocol has a short initialization
phase before entering the infinite loop.
After transmitting a frame, the sender starts the timer running. If it was
already running, it will be reset to allow another full timer interval. The time
interval should be chosen to allow enough time for the frame to get to the
receiver, for the receiver to process it in the worst case, and for the
34
acknowledgement frame to propagate back to the sender. Only when that
time interval has elapsed is it safe to assume that either the transmitted
frame or its acknowledgement has been lost, and to send a duplicate. If the
timeout interval is set too short, the sender will transmit unnecessary frames.
While these extra frames will not affect the correctness of the protocol, they
will hurt performance.
After transmitting a frame and starting the timer, the sender waits for
something exciting to happen. Only three possibilities exist: an
acknowledgement frame arrives undamaged, a damaged acknowledgement
frame staggers in, or the timer expires. If a valid acknowledgement comes in,
the sender fetches the next packet from its network layer and puts it in the
buffer, overwriting the previous packet. It also advances the sequence
number. If a damaged frame arrives or no frame at all arrives, neither the
buffer nor the sequence number is changed so that a duplicate can be sent.
When a valid frame arrives at the receiver, its sequence number is checked to
see if it is a duplicate. If not, it is accepted, passed to the network layer, and
an acknowledgement is generated. Duplicates and damaged frames are not
passed to the network layer
At layer 2, user's messages are already broken up into segments. Control
information (headers and trailers) is added to each segment to make up a
frame. We are concerned only with the transmission of frames between two
adjacent IMPs.
Functions and requirements of the Data Link Protocols
The basic function of the layer is to transmit frames over a physical
communication link. Transmission may be half duplex or full duplex. To
ensure that frames are delivered free of errors to the destination station (IMP)
a number of requirements are placed on a data link protocol. The protocol
(control mechanism) should be capable of performing:
1. The identification of a frame (i.e. recognise the first and last bits of a
frame).
2. The transmission of frames of any length up to a given maximum. Any
bit pattern is permitted in a frame.
3. The detection of transmission errors.
4. The retransmission of frames which were damaged by errors.
5. The assurance that no frames were lost.
6. In a multidrop configuration
1. Some mechanism must be used for preventing conflicts caused
by simultaneous transmission by many stations.
7. The detection of failure or abnormal situations for control and
monitoring purposes.
35
It should be noted that as far as layer 2 is concerned a host message is pure
data, every single bit of which is to be delivered to the other host. The frame
header pertains to layer 2 and is never given to the host.
We will first look at three elementary data link protocols of increasing
complexity.
Elementary Data Link Protocols
An unrestricted simplex protocol
In order to appreciate the step by step development of efficient and complex
protocols such as SDLC, HDLC etc., we will begin with a simple but unrealistic
protocol. In this protocol:





Data are transmitted in one direction only
The transmitting (Tx) and receiving (Rx) hosts are always ready
Processing time can be ignored
Infinite buffer space is available
No errors occur; i.e. no damaged frames and no lost frames (perfect
channel)
The protocol consists of two procedures, a sender and receiver as depicted
below:
/* protocol 1 */
Sender()
{
forever
{
from_host(buffer);
S.info = buffer;
sendf(S);
}
}
Receiver()
{
forever
{
wait(event);
getf(R);
to_host(R.info);
}
}
36
A simplex stop-and-wait protocol
In this protocol we assume that



Data are transmitted in one direction only
No errors occur (perfect channel)
The receiver can only process the received information at a finite rate
These assumptions imply that the transmitter cannot send frames at a rate
faster than the receiver can process them.
The problem here is how to prevent the sender from flooding the receiver.
A general solution to this problem is to have the receiver provide some sort of
feedback to the sender. The process could be as follows: The receiver send an
acknowledge frame back to the sender telling the sender that the last
received frame has been processed and passed to the host; permission to
send the next frame is granted. The sender, after having sent a frame, must
wait for the acknowledge frame from the receiver before sending another
frame. This protocol is known as stop-and-wait.
A simplex protocol for a noisy channel
In this protocol the unreal "error free" assumption in protocol 2 is dropped.
Frames may be either damaged or lost completely. We assume that
transmission errors in the frame are detected by the hardware checksum.
One suggestion is that the sender would send a frame, the receiver would
send an ACK frame only if the frame is received correctly. If the frame is in
error the receiver simply ignores it; the transmitter would time out and would
retransmit it.
One fatal flaw with the above scheme is that if the ACK frame is lost or
damaged, duplicate frames are accepted at the receiver without the receiver
knowing it.
Imagine a situation where the receiver has just sent an ACK frame back to
the sender saying that it correctly received and already passed a frame to its
host. However, the ACK frame gets lost completely, the sender times out and
retransmits the frame. There is no way for the receiver to tell whether this
frame is a retransmitted frame or a new frame, so the receiver accepts this
duplicate happily and transfers it to the host. The protocol thus fails in this
aspect.
To overcome this problem it is required that the receiver be able to
distinguish a frame that it is seeing for the first time from a retransmission.
One way to achieve this is to have the sender put a sequence number in the
header of each frame it sends. The receiver then can check the sequence
37
number of each arriving frame to see if it is a new frame or a duplicate to be
discarded.
The receiver needs to distinguish only 2 possibilities: a new frame or a
duplicate; a 1-bit sequence number is sufficient. At any instant the receiver
expects a particular sequence number. Any wrong sequence numbered frame
arriving at the receiver is rejected as a duplicate. A correctly numbered frame
arriving at the receiver is accepted, passed to the host, and the expected
sequence number is incremented by 1 (modulo 2).
This protocol can handle lost frames by timing out. The timeout interval has
to be long enough to prevent premature timeouts which could cause a
"deadlock" situation.
38
Session 4:
Sliding Window Protocols
Piggybacking technique
In most practical situations there is a need for transmitting data in both
directions (i.e. between 2 computers). A full duplex circuit is required for the
operation.
If protocol 2 or 3 is used in these situations the data frames and ACK
(control) frames in the reverse direction have to be interleaved. This method
is acceptable but not efficient. An efficient method is to absorb the ACK frame
into the header of the data frame going in the same direction. This technique
is known as piggybacking.
When a data frame arrives at an IMP (receiver or station), instead of
immediately sending a separate ACK frame, the IMP restrains itself and waits
until the host passes it the next message. The acknowledgement is then
attached to the outgoing data frame using the ACK field in the frame header.
In effect, the acknowledgement gets a free ride in the next outgoing data
frame.
This technique makes better use of the channel bandwidth. The ACK field
costs only a few bits, whereas a separate frame would need a header, the
acknowledgement, and a checksum.
An issue arising here is the time period that the IMP waits for a message onto
which to piggyback the ACK. Obviously the IMP cannot wait forever and there
is no way to tell exactly when the next message is available. For these
reasons the waiting period is usually a fixed period. If a new host packet
arrives quickly the acknowledgement is piggybacked onto it; otherwise, the
IMP just sends a separate ACK frame.
Sliding window
When one host sends traffic to another it is desirable that the traffic should
arrive in the same sequence as that in which it is dispatched. It is also
desirable that a data link should deliver frames in the order sent.
A flexible concept of sequencing is referred to as the sliding window concept
and the next three protocols are all sliding window protocols.
39
In all sliding window protocols, each outgoing frame contains a sequence
number SN ranging from 0 to 2^(n -1)(where n is the number of bits
reserved for the sequence number field).
At any instant of time the sender maintains a list of consecutive sequence
numbers corresponding to frames it is permitted to send. These frames are
said to fall within the sending window. Similarly, the receiver maintains
a receiving window corresponding to frames it is permitted to accept.
The size of the window relates to the available buffers of a receiving or
sending node at which frames may be arranged into sequence.
At the receiving node, any frame falling outside the window is discarded.
Frames falling within the receiving window are accepted and arranged into
sequence. Once sequenced, the frames at the left of the window are delivered
to the host and an acknowledgement of the delivered frames is transmitted to
their sender. The window is then rotated to the position where the left edge
corresponds to the next expected frame, RN.
Whenever a new frame arrives from the host, it is given the next highest
sequence number, and the upper edge of the sending window is advanced by
one. The sequence numbers within the sender's window represent frames
sent but as yet not acknowledged. When an acknowledgement comes in, it
gives the position of the receiving left window edge which indicates what
frame the receiver expects to receive next. The sender then rotates its
window to this position, thus making buffers available for continuous
transmission.
A one bit sliding window protocol: protocol 4
The sliding window protocol with a maximum window size 1 uses stop-andwait since the sender transmits a frame and waits for its acknowledgement
before sending the next one.
Pipelining
In many situations the long round-trip time can have important implications
for the efficiency of the bandwidth utilization.
As an example, consider a satellite channel with a 500ms round-trip
propagation delay. At time t~~=0 the sender starts sending the first
frame. Not until at least t~>=~500 ms has the acknowledgement
arrived back at the sender. This means that the sender was blocked
most of the time causing a reduction in efficiency.
As another example, if the link is operated in a two-way alternating mode
(half-duplex), the line might have to be "turned around" for each frame in
order to receive an acknowledgement. This acknowledgement delay could
severely impact the effective data transfer rate.
40
The effects of these problems can be overcome by allowing the sender to
transmit multiple contiguous frames (say up to w frames) before it receives
an acknowledgement. This technique is known as pipelining.
In the satellite example, with a channel capacity of 50kbps and 1000-bit
frames, by the time the sender has finished sending 26 frames, t~=~520 ms,
the acknowledgement for frame 0 will have just arrived, allowing the sender
to continue sending frames. At all times, 25 or 26 unacknowledged frames will
be outstanding, and the sender's window size needs to be at least 26.
Pipelining frames over an unreliable communication channel raises some
serious issues. What happens if a frame in the middle of a long stream is
damaged or lost? What should the receiver do with all the correct frames
following the bad one?
The are two basic Automatic Request for Repeat (ARQ) methods for dealing
with errors in the presence of pipelining.
One method, the normal mode of ARQ is called Go-back-N. If the receiver
detects any error in frame N, it signals the sender and then discards any
subsequent frame.
The sender, which may currently be sending frame N+X when the error signal
is detected, initiates retransmission of frame N and all subsequent frames.
The other method is called selective reject. In this method the receiver stores
all the correct frames following the bad one. When the sender finally notices
what was wrong, it just retransmits the one bad frame, not all its successors.
Protocol 5: Pipelining, Multiple outstanding frames (MaxSeq)
In this protocol, the sender may transmit up to MaxSeq frames without
waiting for an acknowledgement. In addition, unlike the previous protocols,
the host is not assumed to have a new message all the time. Instead, the
host causes host ready events when there is a message to send.
This protocol employs the Go-back-N technique. In the example below, the
window size of the receiver is equal to 1, and a maximum of MaxSeq frames
may be outstanding at any instant.
Protocol 6
This protocol employs the selective reject technique. The protocol does not
discard good frames because an earlier frame was damaged or lost provided
that these good frames fall within the receiving window.
41
Associated with each outstanding frame is a timer. When the timer goes off,
(or when the transmitter is notified of any error), only that one frame is
retransmitted, not all the outstanding frames, as in protocol 5.
In this protocol, the receiver's window size is fixed, the maximum of which
is (MaxSeq+1)/2 . The maximum number is thus chosen to ensure that there
will not be an overlapping between the new window and the previous window.
The overlapping of windows means that the receiver would not be able to
differentiate between a new frame and a retransmitted frame.
The receiver has a buffer reserved for each sequence number within its
window. Whenever a frame arrives, its sequence number is checked to see if
it falls within the receiver's window. If so, and if it has not already been
received, it is accepted and stored regardless of whether or not it is the next
frame expected by the host. Frames passed to the host must always be in
order.
Protocol 6 is more efficient than protocol 5 in that:


Protocol 6 employs an auxiliary timer to prevent delay in piggybacking.
If no reverse traffic has presented itself before the timer goes off, a
separate acknowledgement is sent.
Whenever the receiver has reason to suspect that an error has occured
it sends a negative acknowledgement (NAK) frame back to the sender.
Such a frame is a request for retransmission of the frame specified in
the NAK.
High-level Data Link Control Procedures: HDLC, SDLC
Introduction
In this subsection we describe the International Standards Organisation data
link protocol HDLC (High-level Data Link Control). CCITT Recommendation
X.25 level 2 is one of the permissible options of HDLC. All these bit-oriented
protocols grew out from the original IBM SDLC (Synchronous Data Link
Control). All these protocols are based on the same protocols. They differ only
in minor ways (see the appropriate protocol definition).
HDLC is a discipline for the management of information transfer over a data
communication channel.
HDLC has a basic structure that governs the function and the use of control
procedures. The basic structure includes:



The definitions of primary and secondary station responsibilities.
The design of information grouping for control and checking.
The design of the format for transfer of information and control data.
42
Primary and secondary stations
A data link involves two or more participating stations. For control purposes
one station on the link is designated a primary station, the others
are secondary stations. The primary station is responsible for the organization
of data flow and for the link level error recovery procedures.
A frame sent from a primary station is referred to as a command frame. A
frame from a secondary to a primary is referred to as a response frame.
Normally when a command is sent, a response or a string of responses is
expected
in
reply.
On a point-to-point link either station could be the primary. On multidrop links
and where polling is employed, the station which polls the other is the
primary. A station may have several links connected to it. In some
configurations it may be assigned as a primary for some links and a
secondary for others. The station assignments are normally made when a
system is designed.
Frame structure
In HDLC the input data string to be transmitted over the link is broken up
into data frames which are then transmitted sequentially. The input data
string could be command, response or information.
All frames start and end with the flag byte 01111110. There is a 3-byte
header at the start of the frame and a 3-byte trailer at the end. Between the
header and the trailer any number of bits can be carried (bit-oriented).
The header
byte 1 - Flag (01111110):
A frame is identified by this beginning flag F and contains only non-F bit
patterns. HDLC uses bit-stuffing to achieve data transparency.
Whenever the transmitting hardware encounters five consecutive ones
in the data, it automatically stuffs a zero bit into the outgoing bit
stream. When the receiver sees five consecutive incoming one bits
followed by a zero bit, it automatically deletes the zero bit. If the user
data contained the flag pattern 01111110, it would be transmitted
as 011111010 but stored in the receiver's memory as 01111110. Thus
the pattern F can never occur by chance.
byte 2 - Address:
In command frames, the address identifies the station(s) for which the
command is intended. In response frames, the address identifies the
station from which the response originated. However, the address could
also be a broadcast address so that a single frame is received by all
stations on the link, or it could be the address of a group of stations.
43
byte 3 - Control:
The control field contains information for controlling the link, which we
will examine later.
The trailer
bytes 1 and 2 - Frame Check Sequence:
The FCS field contains a 16-bit Cyclic Redundancy Check (CRC) error
detecting code.
byte 3 - Flag:
This flag indicates the end of the frame. When this flag is detected the
receiver examines the preceding two bytes and executes its error
detection algorithm.
A flag may be followed by a frame, by another flag, or by an idle condition.
Data link channel states
Active channel state:
A channel is in an ACTIVE state when the primary or a secondary is
actively transmitting a frame, a single abort sequence or interframe
time fill. In this state the right to continue transmission is reserved.
Abort:
A station can abort a frame by transmitting at least seven contiguous
ones. The receiving station will ignore the frame.
Interframe time fill:
In this state continuous flag bytes are sent between frames.
Idle channel state:
A channel is defined to be in an IDLE state when the transmission of 15
or more contiguous one bits is detected. In this state a primary must
repoll a secondary before transmitting an I-frame to it.
Types of frames
There are three kinds of frames:
I-frame:
Information frame. This type of frame carries user's data.
S-frame:
Supervisory frame: This is used for supervisory control functions such
as acknowledgements, requesting transmission and requesting a
temporary suspension of transmission.
U-frame:
Unnumbered frame or Unsequenced frame. This is used to provide
additional link control functions.
Before discussing in detail the functional aspects of these frames we will look
at the modes of operation.
44
Modes of operation
For a secondary station two operational modes are defined: Normal response
mode and Asynchronous response mode.
Normal response mode
In this mode a secondary station can transmit only in response to a command
frame from the primary station. The response transmission may consist of one
or more frames, the last of which must be explicitly indicated (using the
Poll/Final bit). The secondary then cannot transmit again until it receives
another command to do so.
Asynchronous response mode
In this mode the secondary station may initiate transmission of a frame or
group of frames without receiving explicit permission from the primary. The
frames may contain data or control information. The secondary station is
responsible for time-out and retransmission if necessary.
ARM is necessary for the control of loops of stations or multi-drop lines with
hub polling. In these configurations a secondary may receive a "go-ahead"
message from another secondary and transmit in response to it.
Unfortunately, the above two modes are unbalanced modes in which one end
of the link is the master and the other end is the slave. To make the protocol
more suitable when the two stations are equals (e.g. the nodes of mesh
structured computer networks), HDLC has an additional mode: Asynchronous
Balanced Mode (ABM).
Asynchronous balanced mode (or simply Balanced mode)
In this mode the stations have identical protocols. They both can initiate
transmission at any time. They can send both commands and responses.
Commands and responses
In this section we will describe the various information, supervisory and
unnumbered frames. These types of frame are distinguished by their 8-bit
control fields. Within each type, the frames are differentiated by the ways the
bits in the C-field are configured. We will look closely at the C-field
configurations, their associated functions and frames. When one of the frames
is received by a secondary station, it is a command; when it is received by a
primary station, it is a response.
I-frames
The I-frames are identified by the first bit sent of the control field. This bit is a
0.
45
The next three bits provide counts for numbering the frame being sent. It is
called the send sequence number (N(S)).
The next bit is the Poll/Final bit. It is the send/receive control. A P bit is sent
to a secondary station to authorise transmission. An F bit is sent by a
secondary station in response to the P bit. Normally, only one P bit is
outstanding on the data link.
The next three bits provide counts for numbering the frame expected to be
received next. It is a piggybacked acknowledgement, and is called the receive
sequence number (N(R)).
S-frames
The S-frames are identified by the first two bits sent of the control field.
These are 10.The next two bits are used for coding the commands and
responses.The Poll/final bit is as in the I-frame.The next three bits form N(R),
which indicates that all I-frames numbered up to N(R)-1 have been correctly
received and the receiver is expecting the I-frame numbered N(R).
The S-frame does not contain an information field. Consequently it does not
have N(S) and it is normally a six byte frame.
The four types of S-frame are described below:
Receive Ready (RR)
An RR frame confirms receipt of frames numbered up to N(R)-1 and
indicates that it is ready to receive frame number N(R). An RR frame
with the poll bit set to 1 may be used by a primary station to poll a
secondary station.
Reject (REJ)
An REJ frame is used by the primary or secondary station to request
retransmission of information frame number N(R) and those that follow
it. It implies that I-frames numbered N(R)-1 and below have been
correctly received.
Only one reject condition may be established at any given time for a
givendirectionof transmission over the link. The REJ condition is
clearedbyreceiptofanI-framewithan N(S) equal to the N(R) of the REJ
command/responseframe.
Receive Not Ready (RNR)
An RNR frame indicates a temporary busy condition. The station which
sends the RNR frame acknowledges I frames up to N(R)-1, expects Iframe number N(R), and indicates that it cannot accept any more I-
46
frames. This busy condition is cleared upon the receipt of any other Sframe and of certain types of U-frame.
Selective Reject (SREJ)
An SREJ frame is used by the primary or secondary to request
retransmission of the single I-frame numbered N(R). All frames up to
N(R)-1 have been received correctly but N(R) has not. Once SREJ has
been transmitted, the only I-frames accepted are the frame N(R) and
those that follow it.
U-frames
The U-frames are identified by the first two bits sent of the control field.
These bits are 11. The P/F bit is used as before. The other five "modifier" bits
are available to encode up to 32 types of U-frame. However, not all 32
combinations are used yet. A U-frame has no sequence numbers. U-frames
are used to provide additional link control functions such as


commands which can initialize a station, change transmission modes,
and disconnect a station;
provide a mechanism for rejecting invalid commands or dealing with
some special error conditions.
The SNRM command allows a station that has just come back on line to
announce its presence. The secondary station confirms acceptance of SNRM
by transmitting a single UA response frame with the F bit set to one. The
secondary station forces all the sequence numbers to zero. The SNRM
contains no information field. The SARM and SABM commands function
similarly.
The DISC command terminates an operational mode previously set by a
command and places the receiving secondary station effectively off line. The
expected response is a UA frame. DISC contains no information field.
The Unnumbered Acknowledge (UA) frame is used by the secondary station to
acknowledge the receipt and acceptance of U-frame commands from the
primary. The UA frame contains no information field.
The CMDR response is used by a secondary station when it receives a nonvalid frame. A received frame may be non-valid for several reasons:
1. the command is not implemented at the receiving station;
2. the I-field is too long to fit into the receiving station's buffers; or
3. The N(R) received is incongruous with the N(S) that was sent to it.
The Command Reject frame has an information field that contains details of
why the command was rejected.
47
Information Exchange
In this section we will describe how information exchange between stations
takes place using HDLC protocols. We will also describe methods employed for
error recovery in some typical abnormal error conditions (not all possible
situations).
Set-up
If a secondary station is off-line, the primary station must first send a
command (e.g. SNRM) to the secondary station to set it up in some
operational mode (e.g. NRM). The secondary station confirms the acceptance
of the command by setting its N(R) and N(S) to zero and returns an
unnumbered acknowledge (UA) frame to the primary. Both stations are then
ready for information exchange.
Polling
Having agreed upon the operational mode, both stations can now exchange
information. However, if the mode is normal response mode then


the primary can send data or command frames to the secondary station
at any time, but
the secondary station can only transmit if it is permitted to do so, i.e. if
it receives a frame with the poll bit set to one.
Normal Response
When a station receives enough data to build up a frame together with the
address of the receiving station it will first compute the Frame Check
Sequence (FCS). It will then start transmission by generating a flag, serialize
the address bits, the control bits and data bits, followed by the FCS and the
final flag.
The receiving station constantly monitors the line and searches for a flag.
When a flag is detected the receiver knows that a frame is on its way, and
checks the address byte received to see whether the frame is destined for it
or not. If it is, the receiver then continues to receive all the bits of the frame
until another flag is seen. The receiver then computes the FCS and compares
it with that received. If the frame is correctly and properly received, the
receiving station will send an acknowledgement (ACK) message to the sender
at the earliest opportunity. The ACK message could be a separate message or
it could be piggybacked on an I-frame travelling to the original sender.
Error control
Error control is achieved at this level by the following procedures:
1. FCS: Data, address and control bits in the frame are CRC coded so that
transmission errors can be detected effectively.
48
2. N(S) and N(R) are also used for error control. If the received frame
whose send sequence number N(S) does not match the expected frame
number N(R) the receiver knows that an error has occurred, i.e. some
frame is missing or the received frame is a duplicate.
3. The transmitter can time out and retransmit an unacknowledged frame
or the receiver can request the retransmission of a frame or group of
frames.
4. The Poll and Final bits could also be used for error control purposes.
Flow control
Flow control is achieved in various ways:
1. HDLC is a pipelining protocol. The transmitter is allowed to transmit a
number of frames up to Nmax before an ACK is received. This is
different from the stop-and-wait procedure in which every frame must
be acknowledged before the next frame is allowed to be transmitted.
The pipelining protocol thus
o speeds up the flow of information; i.e. it is more efficient; and
o prevents the receiver from being flooded.
2. Go-back-N and selective reject requests by the receiver also improve
the flow.
49
Session 5:
Network Layer:
The network layer is concerned with getting packets from the source all the
way to the destination. Getting to the destination may require making many
hops at intermediate routers along the way. This function clearly contrasts
with that of the data link layer, which has the more modest goal of just
moving frames from one end of a wire to the other. Thus, the network layer
is the lowest layer that deals with end-to-end transmission.
To achieve its goals, the network layer must know about the topology of the
communication subnet (i.e., the set of all routers) and choose appropriate
paths through it. It must also take care to choose routes to avoid overloading
some of the communication lines and routers while leaving others idle. Finally,
when the source and destination are in different networks, new problems
occur. It is up to the network layer to deal with them. In this chapter we will
study all these issues and illustrate them, primarily using the Internet and its
network layer protocol, IP, although wireless networks will also be addressed.
Routing Algorithms
The main function of the network layer is routing packets from the source
machine to the destination machine. In most subnets, packets will require
multiple hops to make the journey. The only notable exception is for
broadcast networks, but even here routing is an issue if the source and
destination are not on the same network. The algorithms that choose the
routes and the data structures that they use are a major area of network
layer design.
The routing algorithm is that part of the network layer software responsible
for deciding which output line an incoming packet should be transmitted on. If
the subnet uses datagrams internally, this decision must be made anew for
every arriving data packet since the best route may have changed since last
time. If the subnet uses virtual circuits internally, routing decisions are made
only when a new virtual circuit is being set up. Thereafter, data packets just
follow the previously-established route. The latter case is sometimes
called session routing because a route remains in force for an entire user
session (e.g., a login session at a terminal or a file transfer).
The network layer is concerned with getting packets from the source all the
way to the destination. The packets may require to make many hops at the
intermediate routers while reaching the destination. This is the lowest layer
that deals with end to end transmission. In order to achieve its goals, the
network later must know about the topology of the communication network. It
must also take care to choose routes to avoid overloading of some of the
50
communication lines while leaving others idle. The main functions performed
by the network layer are as follows:



Routing
Congestion Control
Internetworking
Routing
Routing is the process of forwarding of a packet in a network so that it
reaches its intended destination. The main goals of routing are:
1. Correctness: The routing should be done properly and correctly so
that the packets may reach their proper destination.
2. Simplicity: The routing should be done in a simple manner so that the
overhead is as low as possible. With increasing complexity of the
routing algorithms the overhead also increases.
3. Robustness: Once a major network becomes operative, it may be
expected to run continuously for years without any failures. The
algorithms designed for routing should be robust enough to handle
hardware and software failures and should be able to cope with
changes in the topology and traffic without requiring all jobs in all hosts
to be aborted and the network rebooted every time some router goes
down.
4. Stability: The routing algorithms should be stable under all possible
circumstances.
5. Fairness: Every node connected to the network should get a fair
chance of transmitting their packets. This is generally done on a first
come first serve basis.
6. Optimality: The routing algorithms should be optimal in terms of
throughput and minimizing mean packet delays. Here there is a tradeoff and one has to choose depending on his suitability.
Classification of Routing Algorithms
The routing algorithms may be classified as follows:
1. Adaptive Routing Algorithm: These algorithms change their routing
decisions to reflect changes in the topology and in traffic as well. These
get their routing information from adjacent routers or from all routers.
The optimization parameters are the distance, number of hops and
estimated transit time. This can be further classified as follows:
1. Centralized: In this type some central node in the network gets
entire information about the network topology, about the traffic
51
and about other nodes. This then transmits this information to
the respective routers. The advantage of this is that only one
node is required to keep the information. The disadvantage is
that if the central node goes down the entire network is down,
i.e. single point of failure.
2. Isolated: In this method the node decides the routing without
seeking information from other nodes. The sending node does
not know about the status of a particular link. The disadvantage
is that the packet may be send through a congested route
resulting in a delay. Some examples of this type of algorithm for
routing are:
 Hot Potato: When a packet comes to a node, it tries to
get rid of it as fast as it can, by putting it on the shortest
output queue without regard to where that link leads. A
variation of this algorithm is to combine static routing with
the hot potato algorithm. When a packet arrives, the
routing algorithm takes into account both the static
weights of the links and the queue lengths.
 Backward Learning: In this method the routing tables at
each node gets modified by information from the incoming
packets. One way to implement backward learning is to
include the identity of the source node in each packet,
together with a hop counter that is incremented on each
hop. When a node receives a packet in a particular line, it
notes down the number of hops it has taken to reach it
from the source node. If the previous value of hop count
stored in the node is better than the current one then
nothing is done but if the current value is better then the
value is updated for future use. The problem with this is
that when the best route goes down then it cannot recall
the second best route to a particular node. Hence all the
nodes have to forget the stored informations periodically
and start all over again.
3. Distributed: In this the node receives information from its
neighboring nodes and then takes the decision about which way
to send the packet. The disadvantage is that if in between the
the interval it receives information and sends the packet
something changes then the packet may be delayed.
2. Non-Adaptive Routing Algorithm: These algorithms do not base
their routing decisions on measurements and estimates of the current
traffic and topology. Instead the route to be taken in going from one
node to the other is computed in advance, off-line, and downloaded to
the routers when the network is booted. This is also known as static
routing. This can be further classified as:
1. Flooding: Flooding adapts the technique in which every
incoming packet is sent on every outgoing line except the one on
52
which it arrived. One problem with this method is that packets
may go in a loop. As a result of this a node may receive several
copies of a particular packet which is undesirable. Some
techniques adapted to overcome these problems are as follows:
 Sequence Numbers: Every packet is given a sequence
number. When a node receives the packet it sees its
source address and sequence number. If the node finds
that it has sent the same packet earlier then it will not
transmit the packet and will just discard it.
 Hop Count: Every packet has a hop count associated with
it. This is decremented(or incremented) by one by each
node which sees it. When the hop count becomes zero(or
a maximum possible value) the packet is dropped.
 Spanning Tree: The packet is sent only on those links
that lead to the destination by constructing a spanning
tree routed at the source. This avoids loops in
transmission but is possible only when all the intermediate
nodes have knowledge of the network topology.
Flooding is not practical for general kinds of applications. But in
cases where high degree of robustness is desired such as in
military applications, flooding is of great help.
2. Random Walk: In this method a packet is sent by the node to
one of its neighbors randomly. This algorithm is highly robust.
When the network is highly interconnected, this algorithm has
the property of making excellent use of alternative routes. It is
usually implemented by sending the packet onto the least
queued link.
Delta Routing
Delta routing is a hybrid of the centralized and isolated routing algorithms.
Here each node computes the cost of each line (i.e some functions of the
delay, queue length, utilization, bandwidth etc) and periodically sends a
packet to the central node giving it these values which then computes
the k best paths from node i to node j. Let Cij1 be the cost of the best ij path, Cij2 the cost of the next best path and so on.If Cijn - Cij1 < delta,
(Cijn - cost of n'th best i-j path, delta is some constant) then path n is
regarded equivalent to the best i-j path since their cost differ by so little.
When delta -> 0 this algorithm becomes centralized routing and when delta
-> infinity all the paths become equivalent.
53
Multipath Routing
In the above algorithms it has been assumed that there is a single best path
between any pair of nodes and that all traffic between them should use it. In
many networks however there are several paths between pairs of nodes that
are almost equally good. Sometimes in order to improve the performance
multiple paths between single pair of nodes are used. This technique is called
multipath routing or bifurcated routing. In this each node maintains a table
with one row for each possible destination node. A row gives the best, second
best, third best, etc outgoing line for that destination, together with a relative
weight. Before forwarding a packet, the node generates a random number
and then chooses among the alternatives, using the weights as probabilities.
The tables are worked out manually and loaded into the nodes before the
network is brought up and not changed thereafter.
Hierarchical Routing
In this method of routing the nodes are divided into regions based on
hierarchy. A particular node can communicate with nodes at the same
hierarch
Congestion Control Algorithms
When too many packets are present in (a part of) the subnet, performance
degrades. This situation is called congestion. When the number of packets
dumped into the subnet by the hosts is within its carrying capacity, they are
all delivered (except for a few that are afflicted with transmission errors) and
the number delivered is proportional to the number sent. However, as traffic
increases too far, the routers are no longer able to cope and they begin losing
packets. This tends to make matters worse. At very high trafffic, performance
collapses completely and almost no packets are delivered.
Internetworking
Until now, we have implicitly assumed that there is a single homogeneous
network, with each machine using the same protocol in each layer.
Unfortunately, this assumption is wildly optimistic. Many different networks
exist, including LANs, MANs, and WANs. Numerous protocols are in
widespread use in every layer. In the following sections we will take a careful
look at the issues that arise when two or more networks are connected to
form an internet.
Considerable controversy exists about the question of whether today’s
abundance of network types is a temporary condition that will go away as
soon as everyone realizes how wonderful [fill in your favorite network] is or
54
whether it is an inevitable, but permanent, feature of the world that is here to
stay. Having different networks invariably means having different protocols.
55
Session 6
Functioning of session layer
In the seven-layer OSI
layer is layer 5.
model of computer
networking,
the session
The session layer provides the mechanism for opening, closing and managing
a session between end-user application processes, i.e., a semi-permanent
dialogue. Communication sessions consist of requests and responses that
occur between applications. Session-layer services are commonly used in
application environments that make use of remote procedure calls (RPCs).
An example of a session-layer protocol is the OSI protocol suite session-layer
protocol, also known asX.225 or ISO 8327. In case of a connection loss this
protocol may try to recover the connection. If a connection is not used for a
long period, the session-layer protocol may close it and re-open it. It provides
for either full duplex or half-duplex operation and provides synchronization
points in the stream of exchanged messages.[1]
Other examples of session layer implementations include Zone Information
Protocol (ZIP) – the AppleTalk protocol that coordinates the name binding
process, and Session Control Protocol (SCP) – the DECnet Phase IV sessionlayer protocol.
Within the service layering semantics of the OSI network architecture, the
session layer responds to service requests from the presentation layer and
issues service requests to the transport layer.
Services

Authentication

Authorization
Session restoration (checkpointing and recovery)

The session layer of the OSI model is responsible for session check
pointing and recovery. It allows information of different streams, perhaps
originating from different sources, to be properly combined or synchronized.
An example application is web conferencing, in which the streams of audio
and video must be synchronous to avoid so-called lip synch problems. Floor
control ensures that the person displayed on screen is the current speaker.
Another application is in live TV programs, where streams of audio and video
need to be seamlessly merged and transitioned from one to the other to avoid
silent airtime or excessive overlap.
The OSI Network Layer Service Primitives
The network layer service is defined by a Set of Primitives - These primitives
seem very like programming language procedures. Because the network layer
must provides 2 types of service, namely connection-oriented and
connectionless, there are two sets of primitives.
56
Primitives for the Connection-Oriented service
With this service the primitives can be divided into 4 groups, depending on
their function:


Making the connection - CONNECT
Sending information (i.e. using the connection) - DATA, DATAACKNOWLEDGE, EXPEDITED-DATA.

Closing the connection - DISCONNECT

Resetting the connection - RESET.
You make a connection and close a connection by using the CONNECT and
DISCONNECT calls. Data is sent using DATA, DATA-ACKNOWLEDGE, and
EXPEDITED-DATA (for those special expedited data transmissions). If
something goes wrong, then the connection can be reset, using the RESET
call.
Primitives for the Connectionless service
These primitives are divided into two groups:

Send a packet of data - UNITDATA

En quire into the performance of the network - FACILITY, REPORT.
Packets are to sent using UNITDATA. FACILITY can lets you inquire to the
network about things like average delivery statistics and the like. REPORT is
used by the network to tell the host if there is a problem with the network, for
example, if a machine has gone down.
Remote procedure call
In computer science, a remote procedure call (RPC) is an inter-process
communication that allows a computer program to cause a subroutine or
procedure to execute in another address space (commonly on another
computer on a shared network) without the programmer explicitly coding the
details for this remote interaction. That is, the programmer writes essentially
the same code whether the subroutine is local to the executing program, or
remote. When the software in question uses object-oriented principles, RPC is
called remote invocation or remote method invocation.
Many different (often incompatible) technologies can be used to implement
the concept.
57
History and origins
The idea of treating network operations as remote procedure calls goes back
at least to the 1980s in early ARPANET documents.Bruce Jay Nelson is
generally credited with coining the term.One of the first business uses of RPC
was by Xerox under the name "Courier" in 1981. The first popular
implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as
the basis for Network File System.
Message passing
An RPC is initiated by the client, which sends a request message to a known
remote server to execute a specified procedure with supplied parameters. The
remote server sends a response to the client, and the application continues its
process. While the server is processing the call, the client is blocked (it waits
until the server has finished processing before resuming execution), unless
the client sends an asynchronous request to the server, such as an XHTTP
call. There are many variations and subtleties in various implementations,
resulting in a variety of different (incompatible) RPC protocols.
An important difference between remote procedure calls and local calls is that
remote calls can fail because of unpredictable network problems. Also, callers
generally must deal with such failures without knowing whether the remote
procedure was actually invoked. Idempotent procedures (those that have no
additional effects if called more than once) are easily handled, but enough
difficulties remain that code to call remote procedures is often confined to
carefully written low-level subsystems.
Sequence of events during a RPC
1. The client calls the client stub. The call is a local procedure call, with
parameters pushed on to the stack in the normal way.
2. The client stub packs the parameters into a message and makes a
system call to send the message. Packing the parameters is
called marshalling.
3. The client's local operating system sends the message from the client
machine to the server machine.
4. The local operating system on the server machine passes the incoming
packets to the server stub.
5. The server stub unpacks the parameters from the message . Unpacking
the parameters is called unmarshalling.
6. Finally, the server stub calls the server procedure. The reply traces the
same steps in the reverse direction.
Standard contact mechanisms
To let different clients access servers, a number of standardized RPC systems
have been created. Most of these use an interface description language (IDL)
58
to let various platforms call the RPC. The IDL files can then be used to
generate code to interface between the client and server. The most common
tool used for this is RPCGEN.
59
Session 7
Arithmetic coding is a form of entropy encoding used in lossless data
compression. Normally, a string of characters such as the words "hello there"
is represented using a fixed number of bits per character, as in
the ASCII code. When a string is converted to arithmetic encoding, frequently
used characters will be stored with fewer bits and not-so-frequently occurring
characters will be stored with more bits, resulting in fewer bits used in total.
Arithmetic coding differs from other forms of entropy encoding such
as Huffman coding in that rather than separating the input into component
symbols and replacing each with a code, arithmetic coding encodes the entire
message into a single number, a fraction n where (0.0 ≤ n < 1.0).
An arithmetic coding example assuming a fixed probability distribution
of three Symbols "A","B" and "C". Probability of "A" is 50%, probability
of "B" is 33% and probability of "C" is 17%. Furthermore we assume
that the recursion depth is known in each step. In step one we code "B"
which is inside the interval [0.5,0.83): The binary number "0.10x" is
the shortest code that represents an Interval that is entirely inside
60
[0.5,0.83). "x" means an arbitrary bit sequence. There are two extreme
cases: the smallest x stands for an infinite number of zeros which
represents the left side of the represented Interval. Then the left side of
the Interval is dec(0.10)=0.5. The greatest x stands for an infinite
number of ones which gives a number that converges towards
dec(0.11)=0.75 Therefore "0.10x" represents the Interval [0.5,0.75)
which is inside [0.5,0.83) Now we can leave out the "0." part since all
Intervals begin with "0." and we can ignore the "x" part because no
matter what Bit-sequence it represents, we will stay inside [0.5,0.75)
Huffman coding
There is great similarity between arithmetic coding and Huffman coding – in
fact, it has been shown that Huffman is just a specialized case of arithmetic
coding – but because arithmetic coding translates the entire message into one
number represented in base b, rather than translating each symbol of the
message into a series of digits in base b, it will sometimes approach
optimal entropy encoding much more closely than Huffman can.
In fact, a Huffman code corresponds closely to an arithmetic code where each
of the frequencies is rounded to a nearby power of ½ — for this reason
Huffman deals relatively poorly with distributions where symbols have
frequencies far from a power of ½, such as 0.75 or 0.375. This includes most
distributions where there are either a small numbers of symbols (such as just
the bits 0 and 1) or where one or two symbols dominate the rest.
For an alphabet {a, b, c} with equal probabilities of 1/3, Huffman coding may
produce the following code:

a → 0: 50%

b → 10: 25%
c → 11: 25%

This code has an expected (2 + 2 + 1)/3 ≈ 1.667 bits per symbol for Huffman
coding, an inefficiency of 5 percent compared to log23 ≈ 1.585 bits per
symbol for arithmetic coding.
For an alphabet {0, 1} with probabilities 0.625 and 0.375, Huffman encoding
treats them as though they had 0.5 probability each, assigning 1 bit to each
value, which does not achieve any compression over naive block encoding.
Arithmetic coding approaches the optimal compression ratio of
When the symbol 0 has a high probability of 0.95, the difference is much
greater:
One simple way to address this weakness is to concatenate symbols to
form a new alphabet in which each symbol represents a sequence of
61
symbols in the original alphabet. In the above example, grouping
sequences of three symbols before encoding would produce new
"super-symbols" with the following frequencies:

000: 85.7%

001, 010, 100: 4.5% each
011, 101, 110: 0.24% each
111: 0.0125%


With this grouping, Huffman coding averages 1.3 bits for every three
symbols, or 0.433 bits per symbol, compared with one bit per symbol
in the original encoding.
Data Encryption
In cryptography, encryption is the process of encoding messages (or
information) in such a way that eavesdroppers or hackers cannot read it, but
that authorized parties can In an encryption scheme, the message or
information (referred to as plaintext) is encrypted using an encryption
algorithm, turning it into an unreadable ciphertext (ibid.). This is usually done
with the use of an encryption key, which specifies how the message is to be
encoded. Any adversary that can see the ciphertext, should not be able to
determine anything about the original message. An authorized party,
however, is able to decode the ciphertext using a decryption algorithm, that
usually requires a secret decryption key, that adversaries do not have access
to. For technical reasons, an encryption scheme usually needs a keygeneration algorithm, to randomly produce keys.
There
are
two
basic
types
of
encryption
schemes : private-key
encryption and public-key encryption. In private-key schemes, the encryption
and decryption keys are the same. Thus communicating parties must agree
on a secret key before they wish to communicate. By contrast, in public-key
schemes, the encryption key is public: that is, anyone (friend or foe) has
access to the encryption key, and can encrypt messages. However only the
receiving party has access to the decryption key and thus is the only one
capable of reading the encrypted messages. Public-key encryption is a
relatively recent invention: historically, all encryption schemes have been
private-key schemes.
Encryption has long been used by militaries and governments to facilitate
secret communication. It is now commonly used in protecting information
within many kinds of civilian systems. For example, the Computer Security
Institute reported that in 2007, 71% of companies surveyed utilized
encryption for some of their data in transit, and 53% utilized encryption for
some of their data in storage. Encryption can be used to protect data "at
rest", such as files on computers and storage devices (e.g. USB flash drives).
In recent years there have been numerous reports of confidential data such
62
as customers' personal records being exposed through loss or theft of laptops
or backup drives. Encrypting such files at rest helps protect them should
physical security measures fail. Digital rights management systems which
prevent unauthorized use or reproduction of copyrighted material and protect
software against reverse engineering (see also copy protection) are another
somewhat different example of using encryption on data at rest.
Encryption is also used to protect data in transit, for example data being
transferred
via networks (e.g.the Internet, e-commerce),mobile
telephones, wireless
microphones, wireless
intercom systems, Bluetooth devices and bank automatic teller machines.
There have been numerous reports of data in transit being intercepted in
recent years.[3] Encrypting data in transit also helps to secure it as it is often
difficult to physically secure all access to networks.
Encryption, by itself, can protect the confidentiality of messages, but other
techniques are still needed to protect the integrity and authenticity of a
message; for example, verification of a message authentication code (MAC) or
a digital signature. Standards and cryptographic software and hardware to
perform encryption are widely available, but successfully using encryption to
ensure security may be a challenging problem. A single slip-up in system
design or execution can allow successful attacks. Sometimes an adversary can
obtain unencrypted information without directly undoing the encryption. See,
e.g., traffic analysis, TEMPEST, or Trojan horse.
One of the earliest public key encryption applications was called Pretty Good
Privacy (PGP). It was written in 1991 by Phil Zimmermann and was purchased
by Symantec in 2010.
Digital signature and encryption must be applied at message creation time
(i.e. on the same device it has been composed) to avoid tampering. Otherwise
any node between the sender and the encryption agent could potentially
tamper it. It should be noted that encrypting at the time of creation only adds
security if the encryption device itself has not been tampered with.
Introduction
Often there has been a need to protect information from 'prying eyes'. In the
electronic age, information that could otherwise benefit or educate a group or
individual can also be used against such groups or individuals. Industrial
espionage among highly competitive businesses often requires that extensive
security measures be put into place. And, those who wish to exercise their
personal freedom, outside of the oppressive nature of governments, may also
wish to encrypt certain information to avoid suffering the penalties of going
against the wishes of those who attempt to control.
Still, the methods of data encryption and decryption are relatively
straightforward, and easily mastered. I have been doing data encryption since
63
my college days, when I used an encryption algorithm to store game
programs and system information files on the university mini-computer, safe
from 'prying eyes'. These were files that raised eyebrows amongst those who
did not approve of such things, but were harmless [we were always careful
NOT to run our games while people were trying to get work done on the
machine]. I was occasionally asked what this "rather large file" contained, and
I once demonstrated the program that accessed it, but you needed a
password to get to 'certain files' nonetheless. And, some files needed a
separate encryption program to decipher them.
Methods of Encrypting Data
Traditionally, several methods can be used to encrypt data streams, all of
which can easily be implemented through software, but not so easily
decrypted when either the original or its encrypted data stream are
unavailable. (When both source and encrypted data are available, codebreaking becomes much simpler, though it is not necessarily easy). The best
encryption methods have little effect on system performance, and may
contain other benefits (such as data compression) built in. The well-known
'PKZIP®' utility offers both compression AND data encryption in this manner.
Also DBMS packages have often included some kind of encryption scheme so
that a standard 'file copy' cannot be used to read sensitive information that
might otherwise require some kind of password to access. They also need
'high performance' methods to encode and decode the data.
Encryption methods can be SYMMETRIC in which encryption and decryption
keys are the same, or ASYMMETRIC (aka 'Public Key') in which encryption and
decryption keys differ. 'Public Key' methods must be asymmetric, to the
extent that the decryption key CANNOT be easily derived from the encryption
key. Symmetric keys, however, usually encrypt more efficiently, so they lend
themselves to encrypting large amounts of data. Asymmetric encryption is
often limited to ONLY encrypting a symmetric key and other information that
is needed in order to decrypt a data stream, and the remainder of the
encrypted data uses the symmetric key method for performance reasons. This
does not in any way diminish the security nor the ability to use a public key to
encrypt the data, since the symmetric key method is likely to be even MORE
secure than the asymmetric method.
For symmetric key ciphers, there are basically two types: BLOCK CIPHERS, in
which a fixed length block is encrypted, and STREAM CIPHERS, in which the
data is encrypted one 'data unit' (typically 1 byte) at a time, in the same
order it was received in. Fortunately, the simplest of all of the symmetric key
'stream cipher' methods is the TRANSLATION TABLE (or 'S table'), which
should easily meet the performance requirements of even the most
performance-intensive application that requires data to be encrypted. In a
translation table, each 'chunk' of data (usually 1 byte) is used as an offset
64
within one or more arrays, and the resulting 'translated' value is then written
into the output stream. The encryption and decryption programs would each
use a table that translates to and from the encrypted data. 80x86 CPU's have
an instruction 'XLAT' that lends itself to this purpose.
While translation tables are very simple and fast, the down side is that once
the translation table is known, the code is broken. Further, such a method is
relatively straightforward for code breakers to decipher - such code methods
have been used for years, even before the advent of the computer. Still, for
general "unreadability" of encoded data, without adverse effects on
performance,
the
'translation
table'
method
lends
itself
well.
A modification to the 'translation table' uses 2 or more tables, based on the
position of the bytes within the data stream, or on the data stream itself.
Decoding becomes more complex, since you have to reverse the same
process reliably. But, by the use of more than one translation table, especially
when implemented in a 'pseudo-random' order, this adaptation makes code
breaking relatively difficult. An example of this method might use translation
table 'A' on all of the 'even' bytes, and translation table 'B' on all of the 'odd'
bytes. Unless a potential code breaker knows that there are exactly 2 tables,
even with both source and encrypted data available the deciphering process is
relatively difficult.
Similar to using a translation table, 'data repositioning' lends itself to use by a
computer, but takes considerably more time to accomplish. This type of cipher
would be a trivial example of a BLOCK CIPHER. A buffer of data is read from
the input, then the order of the bytes (or other 'chunk' size) is rearranged,
and written 'out of order'. The decryption program then reads this back in,
and puts them back 'in order'. Often such a method is best used in
combination with one or more of the other encryption methods mentioned
here, making it even more difficult for code breakers to determine how to
decipher your encrypted data. As an example, consider an anagram. The
letters are all there, but the order has been changed. Some anagrams are
easier than others to decipher, but a well written anagram is a brain teaser
nonetheless, especially if it's intentionally misleading.
My favorite methods, however, involve something that only computers can
do: word/byte rotation and XOR bit masking. This is very common since it has
relatively high ENTROPY in the resulting cipher. High entropy data is difficult
to extract information from, and the higher the entropy, the better the cipher.
So, if you rotate the words or bytes within a data stream, using a method that
involves multiple and variable direction and duration of rotation, in an easily
reproducible pattern, you can quickly encode a stream of data with a method
that can be nearly impossible to break. Further, if you use an 'XOR mask' in
combination with this ('flipping' the bits in certain positions from 1 to 0, or 0
65
to 1) you end up making the code breaking process even more difficult. The
best combination would also use 'pseudo random' effects, the easiest of which
might involve a simple sequence like Fibonacci numbers, which can appear
'pseudo-random' after many iterations of 'modular' arithmetic (i.e. math that
'wraps around' after reaching a limit, like integer math on a computer). The
Fibonacci sequence '1,1,2,3,5,...' is easily generated by adding the previous 2
numbers in the sequence to get the next. Doing modular arithmetic on the
result and operating on multiple byte sequences (using a prime number of
bytes for block rotation, as one example) would make the code breaker's job
even more difficult, adding the 'pseudo-random' effect that is easily
reproduced by your decryption program.
In some cases, you may want to detect whether data has been tampered
with, and encrypt some kind of 'checksum' or CRC into the data stream itself.
This is useful not only for authorization codes and licenses (where encrypted
data is expected to be used) but also for programs themselves. A virus that
infects such a 'protected' program is likely to neglect any encryption algorithm
and authorization/checksum signature that has been written to the executable
binary file(s). The program (and any dynamic library) could then check itself
each time it loads, and thus detect the presence of file corruption. Such a
method would have to be kept VERY secret, to prevent virus programmers
from exploiting it at some point.
Public Key Encryption Algorithms
One very important feature of a good encryption scheme is the ability to
specify a 'key' or 'password' of some kind, and have the encryption method
alter itself such that each 'key' or 'password' produces a unique encrypted
output, one that also requires a unique 'key' or 'password' to decrypt. This
can either be a symmetric or asymmetric key. The popular 'PGP' public key
encryption, and the 'RSA' encryption that it's based on, uses an
'asymmetrical' key, allowing you to share the 'public' encryption key with
everyone, while keeping the 'private' decryption key safe. The encryption key
is significantly different from the decryption key, such that attempting to
derive the private key from the public key involves too many hours of
computing time to be practical. It would NOT be impossible, just highly
unlikely, which is 'pretty good'.
There are few operations in mathematics that are truly 'irreversible'. In nearly
all cases, the commutative property or an 'inverse' operation applies. if an
operation is performed on 'a', resulting in 'b', you can perform an equivalent
operation on 'b' to get 'a'. In some cases you may get the absolute value
(such as a square root), or the operation may be undefined (such as dividing
by zero). However, it may be possible to base an encryption key on an
algorithm such that you cannot perform a direct calculation to get the
decryption key. An operation that would cause a division by zero would
66
PREVENT a public key from being directly translated into a private key. As
such, only 'trial and error' (otherwise known as a 'brute force' attack) would
remain as a valid 'key cracking' method, and it would therefore require a
significant amount of processing time to create the private key from the public
key.
In the case of the RSA encryption algorithm, it uses very large prime numbers
to generate the public key and the private key. Although it would be possible
to factor out the public key to get the private key (a trivial matter once the 2
prime factors are known), the numbers are so large as to make it very
impractical to do so. The encryption algorithm itself is ALSO very slow, which
makes it impractical to use RSA to encrypt large data sets. So PGP (and other
RSA-based encryption schemes) encrypt a symmetrical key using the public
key, then encrypt the remainder of the data with a faster algorithm using the
symmetrical key. The symmetrical itself key is randomly generated, so that
the only (theoretical) way to get it would be by using the private key to
decrypt the RSA-encrypted symmetrical key.
Example: Suppose you want to encrypt data (let's say this web page) with a
key of 12345. Using your public key, you RSA-encrypt the 12345, and put
that at the front of the data stream (possibly followed by a marker or
preceded by a data length to distinguish it from the rest of the data). THEN,
you follow the 'encrypted key' data with the encrypted web page text,
encrypted using your favorite method and the key '12345'. Upon receipt, the
decrypt program looks for (and finds) the encrypted key, uses the 'private
key' to decrypt it, and gets back the '12345'. It then locates the beginning of
the encrypted data stream, and applies the key '12345' to decrypt the data.
The result: a very well protected data stream that is reliably and efficiently
encrypted, transmitted, and decrypted.
Source files for a simple RSA-based encryption algorithm can be found HERE:
ftp://ftp.funet.fi/pub/crypt/cryptography/asymmetric/rsa
It is somewhat difficult to write a front-end to get this code to work (I have
done so myself), but for the sake of illustration, the method actually DOES
work and by studying the code you can understand the processes involved in
RSA encryption. RSA, incidentally, is reportedly patented through the year
2000, and may be extended beyond that, so commercial use of RSA requires
royalty payments to the patent holder (www.rsa.com). But studying the
methods and experimenting with it is free, and with source code being
published in print (PGP) and outside the U.S., it's a good way to learn how it
works, and maybe to help you write a better algorithm yourself.
Cryptography, a science for keeping data secure, has existed for thousands of
years.
Cryptographic
methods
can
provide
both encryption/decryption and digital signatures. 1 Encryption provides
67
for confidentiality: keeping information protected from unauthorized
disclosure or viewing by mathematically scrambling the original text. Digital
signatures — which are analogous to written signatures 2 — provide three
other functions:
 authentication — proof that users are who they claim to be or that
resources (e.g. computer device, software or data) are what they
purport to be;
 non-repudiation —
proof that a transaction occurred, or that a
message was sent or received, thus one of the parties to the
exchange cannot deny that the exchange occurred; and
 integrity — so that data cannot be modified without detection.
Cryptography performs these functions by using digital keys (a unique
combination of ones and zeros) that can be employed by an individual user to
encrypt, decrypt and verify digital data. With cryptography, any type of digital
information — text, data, voice or images — can be encrypted so that only
individuals with the correct key can make it comprehensible.
There are two major cryptographic methods. In secret key cryptography,
the same key (or a copy thereof) is used to encrypt and decrypt the data.
In public key cryptography, there are two different but related keys, and
what is encrypted with one can only be decrypted by the other.
Without access to the correct key, data encrypted to ensure confidentiality
can only be decrypted into understandable plaintext 3 by using "brute-force"
techniques, i.e., trying all possible variations of the key and checking to see if
the resulting plaintext is meaningful. All other things being equal,
cryptographic strength is defined by the length of the cryptographic key (or
"bit-length"), which establishes the number of possible permutations. With
each bit added to the length of the key, the strength is doubled. In July 1997,
it took 78,000 volunteered computers on the Internet 96 days to crack a
message encrypted with DES (the Data Encryption Standard), a secret key
algorithm that uses a single 56-bit key. It is estimated that it would take the
same computer resources 67 years to crack a secret key algorithm using a
64-bit key and well over 13 billion times the age of the universe to crack a
128-bit key. Of course, with expert knowledge, specialized hardware, and
substantial funds, one can accelerate the process to some degree. In 1993, a
Canadian mathematician proposed the design for a machine he believed could
be built for $1 million which would complete a brute-force attack on a 56bitDES key in an average of three-and-a-half hours. 4 But even with such
resources, breaking an 80-bit key will be beyond the realm of possibility for at
least a decade.
68
Secret Key Cryptography
Secret key cryptography can be used to encrypt data and either store it
electronically (on a computer disk or hard drive) or transmit it to a close
associate; however, on its own, it has significant limitations that make it
unsuitable for widespread use over public networks among users who do not
know each other. Secret key cryptography requires both parties to prearrange the sharing of the single key that is used for both encryption and
decryption. If the reason for using encryption is due to the lack of security of
the communication channel (e.g. a computer network), it stands to reason
that one should not send the secret key along that same channel where
anyone could copy it and decrypt all one's encrypted data. It is broadly
recognized that the main problems faced by secret key cryptography in open
networks pertain to distribution of keys and scalability (i.e. scalability refers
not just to the notion of an increasing number of users but also to the notion
that open networks include entities of different sizes, from individuals to
multinational corporations, as well as transactions escalating in both volume
and value).
Public Key Cryptography
Public key cryptography, however, offers a solution to both these challenges
since it involves the use of a pair of different yet related keys. Each user has a
private key and a public key. The private key is kept secure, known only to
the user; the other key can be made public and either sent over the network
to each correspondent or, even better, placed in a secure public directory,
almost like the electronic equivalent of a telephone book. To use this kind of
system, the sender would encrypt a message with the recipient's public key.
Only the recipient's private key could decrypt the message. Public key
cryptography thus permits the secure transmission of data across open
networks such as the Internet without the necessity of previously exchanging
a secret key. This allows parties who do not know each other to exchange and
authenticate information and conduct business in a secure manner.
In addition to the capability to encrypt for confidentiality, some forms of
public key cryptography also enable key holders to make their documents
capable of subsequent authentication by using their private key to create a
digital signature.5 This technique also ensures the integrity of documents and
enables recipients to determine quickly if a message has been altered in any
way during transmission.
While public key cryptography has definite advantages over secret key
cryptography for use over open, public networks, secret key cryptography has
its own strengths that are essential to a variety of applications. 6 Both secret
and public key cryptography will be used together to protect sensitive
information stored in computers and distributed over communications
networks.
69
Certification Authorities
If public key cryptography is to work on a large scale for electronic commerce,
one of the main problems to be solved is the trustworthy distribution of public
keys. Some software programs, such as PGP ("Pretty Good Privacy"), which is
widely available on the Internet, require users to distribute their public key to
other users — an approach which may work well in small, closed groups. 7 A
secure, accessible directory, however, is at the heart of broad scale
distribution of public keys — especially when combined with procedures to
ensure that a specific public key genuinely belongs to a particular user.
One of the ways this can be accomplished is through a certification
authority (CA), a trusted agent who manages the distribution of public keys
or certificates containing such keys. 8 Sometimes the termtrusted third
party (TTP) is used as a synonym for certification authority, but the two
terms are not always used in quite the same way. 9
A "certificate" is an electronic form (similar to an electronic version of a
driver's license, a passport or a video rental card) containing the key holder's
public key and some identifying information which confirms that both the key
holder and the certificate issuer (the CA) are who they say they are.
One of the main advantages of having a supporting trusted agent is that it
relieves individuals of distributing keys and managing large numbers of
relationships 10 in a complex, multiple- security environment (the security
relationship one establishes with a bank or a hospital will be different than
that with an acquaintance or an on-line bookstore). It is not, however, simply
an issue of convenience or efficiency. The CA "binds" the specific identity of a
key holder to a particular certificate containing the relevant public key by
signing
the
certificate
with
the CA's
key,
thereby
ensuring
11
authentication and preventing non-repudiation, with the ultimate objective
of maintaining confidence in the system.
Given the differences between digital signature functions (authentication,
non-repudiation and integrity) and the encryption function (confidentiality),
many cryptographic systems now require two pairs of keys: one pair for
digital signatures and the other to provide encryption for confidentiality. If
there is no supporting infrastructure of certification authorities, the user must
generate the private and public key pairs for both digital signatures and
confidentiality. If there is a supporting infrastructure, there are options as to
where the key pairs are generated.
In the case of key pairs for digital signatures, the key pair should be
generated by the user application and the public key should be signed by
the CA and distributed for use. In order to limit the possibility of fraud, the
private signing key should never leave the user application.
70
In the case of key pairs for confidentiality, the key pair is often generated by
the CA in order to ensure back-up capability so that the private encryption
key can be retrieved, thereby permitting recovery of encrypted data in the
event that the private key is lost or compromised.
Making a back-up of the confidentiality key (also known as key archiving) 12 is
one of several methods available to provide for lawful access to plaintext.
Other methods for such access — often generically referred to as key
recovery — include key encapsulation (where, for example, a session
key or long-term encryption key is itself encrypted by a key recovery
agent's public key) and key derivation techniques (for example, the approach
proposed at the Royal Holloway College 13 in London, which allows for the
confidentiality key to be regenerated from either end of the communication by
the trusted third parties who originally provided the mathematical elements
used in generating the key).
Applications of Cryptography
Historically, cryptography was used to assure only secrecy. Wax seals,
signatures, and other physical mechanisms were typically used to assure
integrity of the media and authenticity of the sender. With the advent of
electronic funds transfer, the applications of cryptography for integrity began
to surpass its use for secrecy. Electronic cash came into being from
cryptography, and the electronic credit card and debit card sprung into
widespread use. The advent of public key cryptography introduced the
possibility of digital signatures, and other related concepts such as electronic
credentials. In the information age, cryptography has become one of the
major methods for protection in all applications.
Cryptographic protocols have only recently come under intensive study, and
as of this time, they are not sufficiently well developed to provide a great deal
of assurance. There are several protocols that offer provable properties,
primarily those designed for use with the OTP. The problem with proving
properties of protocols under other schemes is that the mathematics is
extremely complex for the RSA, and there is no sound mathematical basis for
the DES. Much research is under way at this time in the field of protocol
analysis and verification, and it is likely that once this field stabilizes,
cryptographic protocols will follow suit.
Several special purpose cryptographic protocols have been developed and
demonstrated sound. Most notably, the RSA key distribution protocol, a public
key poker playing protocol, an OTP based dining cryptographers protocol, and
the protocol used for verifying the nuclear test ban treaty
71
A typical cryptographic protocol failure is encountered in the use of the RSA .
It seems that if an attacker can choose the plaintext to be signed under an
RSA signature system, observe the result of the signature, and then iterate
the process, it is possible to get the signer to reveal the private key in a very
small number of signatures (about 1 signature per bit of the key). Thus an
unmodified RSA signature system requires a sound protocol to be safely used.
Secrecy in Transmission
Most current secrecy systems for transmission use a private key system for
transforming transmitted information because it is the fastest method that
operates with reasonable assurance and low overhead.
If the number of communicating parties is small, key distribution is done
periodically with a courier service and key maintenance is based on physical
security of the keys over the period of use and destruction after new keys are
distributed.
If the number of parties is large, electronic key distribution is usually used.
Historically, key distribution was done with a special key-distribution-key (also
known as a master-key) maintained by all parties in secrecy over a longer
period of time than the keys used for a particular transaction. The "sessionkey" is generated at random either by one of the parties or by a trusted third
party and distributed using the master-key.
The problem with master-key systems is that if the master-key is successfully
attacked, the entire system collapses. Similarly, if any of the parties under a
given master-key decides to attack the system, they can forge or intercept all
messages throughout the entire system. Many complex private-key systems
for reducing some of these problems have been proposed and used for
various applications.
With the advent of public-key systems, secrecy can be maintained without a
common master-key or a large number of keys. Instead, if Bob wants to
communicate with Alice, Bob sends Alice a session-key encrypted with Alice's
public key. Alice decrypts the session-key and uses that over the period of the
transaction.
These are examples of cryptographic protocols, methods for communicating
while attaining a particular cryptographic objective. These protocols are used
primarily to deal with key management and system misuse problems. Many
other protocols are applied to eliminate other attacks on these systems.
72
Secrecy in Storage
Secrecy in storage is usually maintained by a one-key system where the user
provides the key to the computer at the beginning of a session, and the
system then takes care of encryption and decryption throughout the course of
normal use. As an example, many hardware devices are available for personal
computers to automatically encrypt all information stored on disk. When the
computer is turned on, the user must supply a key to the encryption
hardware. The information cannot be read meaningfully without this key, so
even if the disk is stolen, the information on it will not be useable.
Secrecy in storage has its problems. If the user forgets a key, all of the
information encrypted with it becomes permanently unuseable. The
information is only encrypted while in storage, not when in use by the user.
This leaves a major hole for the attacker. If the encryption and decryption are
done in software, or if the key is stored somewhere in the system, the system
may be circumvented by an attacker. Backups of encrypted information are
often stored in plaintext because the encryption mechanism is only applied to
certain devices.
Integrity in Transmission
Many of the users of communication systems are not as much concerned
about secrecy as about integrity. In an electronic funds transfer, the amount
sent from one account to another is often public knowledge. What the bank
cares about is that only proper transfers can take place. If an active tapper
could introduce a false transfer, funds would be moved illicitly. An error in a
single bit could literally cause millions of dollars to be erroneously credited or
debited. Cryptographic techniques are widely used to assure that intentional
or accidental modification of transmitted information does not cause
erroneous actions to take place.
A typical technique for assuring integrity is to perform a checksum of the
information being transmitted and transmit the checksum in encrypted form.
Once the information and encrypted checksum are received, the information
is again check summed and compared to the transmitted checksum after
decryption. If the checksums agree, there is a high probability that the
message is unaltered. Unfortunately, this scheme is too simple to be of
practical value as it is easily forged. The problem is that the checksum of the
original message is immediately apparent and a plaintext message with an
identical checksum can be easily forged. Designing strong cryptographic
checksums is therefore important to the assurance of integrity in systems of
this sort.
The key distribution problem in a one-key system is as before, but an
interesting alternative is presented by the use of public keys. If we generate a
73
single public-key for the entire system and throw away the private key that
would go with it, we can make the checksum impossible to decrypt. In order
to verify the original message, we simply generate a new checksum, encrypt
with the public key, and verify that the encrypted checksum matches. This is
known as a one-way function because it is hard to invert.
Actual systems of this sort use high quality cryptographic checksums and
complext key distribution and maintenance protocols, but there is a trend
towards the use of public keys for key maintenance.
Integrity in Storage
Integrity against random noise has been the subject of much study in the
fields of fault tolerant computing and coding theory, but only recently has the
need for integrity of stored information against intentional attack become a
matter for cryptography.
The major mean of assuring integrity of stored information has historically
been access control. Access control includes systems of locks and keys,
guards, and other mechanisms of a physical or logical nature. The recent
advent of computer viruses has changed this to a significant degree, and the
use of cryptographic checksums for assuring the integrity of stored
information is now becoming widespread.
As in the case of integrity in transmission, a cryptographic checksum is
produced and compared to expectations, but storage media tends to have
different properties than transmission media. Transmitted information is
typically more widely available over a shorter period of time, used for a
relatively low volume of information, and accessed at a slower rate than
stored information. These parameters cause different tradeoffs in how
cryptosystems are used.
Authentication of Identity
Authenticating the identity of individuals or systems to each other has been a
problem for a very long time. Simple passwords have been used for
thousands of years to prove identity. More complex protocols such as
sequences of keywords exchanged between sets of parties are often shown in
the movies or on television. Cryptography is closely linked to the theory and
practice of using passwords, and modern systems often use strong
cryptographic transforms in conjunction with physical properties of individuals
and shared secrets to provide highly reliable authentication of identity.
Determining good passwords falls into the field known as key selection. In
essence, a password can be thought of as a key to a cryptosystem that allows
encryption and decryption of everything that the password allows access to.
74
In fact, password systems have been implemented in exactly this way in
some commercial products.
The selection of keys has historically been a cause of cryptosystem failure.
Although we know from Shannon that H(K) is maximized for a key chosen
with an equal probability of each possible value (i.e. at random), in practice
when people choose keys, they choose them to make them easy to
remember, and therefore not at random. This is most dramatically
demonstrated in the poor selection that people make of passwords.
On many systems, passwords are stored in encrypted form with read access
available to all so that programs wishing to check passwords needn't be run
by privileged users. A side benefit is that the plaintext passwords don't appear
anywhere in the system, so an accidental leak of information doesn't
compromise system wide protection.
A typical algorithm for transforming any string into an encrypted password is
designed so that it takes 10 or more msec/transformation to encode a string.
By simple calculation, if only capital letters were allowed in a password, it
would take .26 seconds to check all the one letter passwords, 6.76 seconds to
check all the 2 letter passwords, 4570 seconds for the 4 letter passwords, and
by the time we got to 8 letter passwords, it would take about 2*10**9
seconds (24169 days, over 66 years).
For passwords allowing lower case letters, numbers, and special symbols, this
goes up considerably. Studies over the years have consistently indicated that
key selection by those without a knowledge of protection is very poor. In a
recent study , 21% of the users on a computer system had 1 character
passwords, with up to 85% having passwords of 1/2 the maximum allowable
length, and 92% having passwords of 4 characters or less. These results are
quite typical, and dramatically demonstrate that 92% of all passwords could
be guessed on a typical system in just over an hour.
Several suggestions for getting unpredictable uniform random numbers
include the use of low order bits of Geiger counter counts, the use of the time
between entries at a keyboard, low order bits of the amount of light in a room
as measured by a light sensitive diode, noisy diode output, the last digit of
the first phone number on a given page of a telephone book, and digits from
transcendental numbers such as Pi.
Credentialing Systems
A credential is typically a document that introduces one party to another by
referencing a commonly known trusted party. For example, when credit is
applied for, references are usually requested. The credit of the references is
checked and they are contacted to determine the creditworthiness of the
75
applicant. Credit cards are often used to credential an individual to attain
further credit cards. A driver's license is a form of credential, as is a passport.
Electronic credentials are designed to allow the credence of a claim to be
verified electronically. Although no purely electronic credentialing systems are
in widespread use at this time, many such systems are being integrated into
the smart-card systems in widespread use in Europe. A smart-card is simply a
credit-card shaped computer that performs cryptographic functions and stores
secret information. When used in conjunction with other devices and systems,
it allows a wide variety of cryptographic applications to be performed with
relative ease of use to the consumer.
Electronic Signatures
Electronic signatures, like their physical counterparts, are a means of
providing a legally binding transaction between two or more parties. To be as
useful as a physical signature, electronic signatures must be at least as hard
to forge, at least as easy to use, and accepted in a court of law as binding
upon all parties to the transaction.
The need for these electronic signatures is especially accute in business
dealings wherein the parties to a contract are not in the same physical
vicinity. For example, in an international sale of an airplane, signatures are
typically required from two bankers, two companies, two insurance agencies,
two attorneys, two governments, and often several other parties. The
contracts are hundreds of pages long, and signatures must be attained within
a relatively short period of time on the same physical document. Faxcimily
signatures are not legally binding in all jurisdictions, and the sheer length of a
document precludes all parties reading the current copy as they meet at the
table to affix signatures. Under current law, all parties must meet in one
location in order to complete the transaction. In a transatlantic sale, $100,000
in costs can easily be incurred in such a meeting.
An effort in Europe is currently underway to replace physical signatures with
electronic signatures based on the RSA cryptosystem. If this effort succeeds,
it will allow many millions of dollars to be saved, and launch the era of digital
signatures into full scale motion. It will also create a large savings for those
who use the system, and therefore act to force others to participate in order
to remain competitive.
Electronic Cash
There are patents under force throughout the world today to allow electronic
information to replace cash money for financial transactions between
individuals. Such a system involves using cryptography to keep the assets of
nations in electronic form. Clearly the ability to forge such a system would
76
allow national economies to be destroyed in an instant. The pressure for
integrity in such a system is staggering.
Threshold Systems
Thresholding systems are systems designed to allow use only if a minimal
number of parties agree to said use. For example, in a nuclear arms situation,
you might want a system wherein three out of five members of the joint
chiefs of staff agree. In a banking situation, a safe might only be opened if 4
out of the authorized 23 people allowed to open the safe were present. Such
systems preclude a single individual acting alone, while allowing many of the
parties to a transaction to be absent without the transaction being halted.
Most threshold systems are based on encryption with keys which are
distributed in parts. The most common technique for partitioning a key into
parts is to form the key as the solution to N equations in N unknowns. If N
independent equations are known, the key can be determined by solving the
simultaneous equations. If less than N equations are known, the key can be
any value since there is still an independent variable in the equations. Any
number can be chosen for N and equations can be held by separate
individuals. The same general concept can be used to form arbitrary
combinations of key requirements by forming ORs and ANDs of encryptions
using different sets of keys for different combinations of key holders . The
major difficulties with such a system lie in the key distribution problem and
the large number of keys necessary to achieve arbitrary key holder
combinations.
Systems Using Changing Keys
Shannon has shown us that given enough reuse of a key, it can eventually be
determined. It is thus common practice to regularly change keys to limit the
exposure due to successful attack on any given key. A common misconception
is that changing a key much more often than the average time required to
break the cryptosystem, provides an increased margin of safety.
If we assume the key is chosen at random, and that the attacker can check a
given percentage of the keys before a key change is made, it is only a matter
of time before one of the keys checked by the attacker happens to correspond
to one of the random keys. If the attacker chooses keys to attack at random
without replacement over the period of key usage, and begins again at the
beginning of each period, it is 50% likely that a currently valid key will be
found by the time required to try 50% of the total number of keys, regardless
of key changes. Thus if a PC could try all the DES keys in 10 years, it would
be 50% likely that a successful attack could be launched in 5 years of effort.
The real benefit of key changes is that the time over which a broken key is
77
useful is limited to the time till the next key change. This is called limiting the
exposure from a stolen key.
Hardware to Support Cryptography
Historically, cryptography has been carried out through the use of
cryptographic devices. The use of these devices derives from the difficulty in
performing cryptographic transforms manually, the severe nature of errors
that result from the lack of redundancy in many cryptographic systems, and
the need to make the breaking of codes computationally difficult.
In WWII, the ENIGMA machine was used by the Germans to encode
messages, and one of the first computers ever built was the BOMB, which was
designed to break ENIGMA cryptograms. Modern supercomputers are used
primarily by the NSA to achieve the computational advantage necessary to
break many modern cryptosystems. The CRAY could be easily used to break
most password enciphering systems, RSA systems with keys of length under
about 80 (circa 1986) are seriously threatened by the CRAY, and even the
DES can be attacked by using special purpose computer hardware. Many
devices have emerged in the marketplace for the use of cryptography to
encrypt transmissions, act as cryptographic keys for authentication of
identification, protect so called debit cards and smart cards, and implementing
electronic cash money systems.
78
Session 8
Public key cryptography
Public-key algorithms are asymmetric algorithms and, therefore, are based on
the use of two different keys, instead of just one. In public-key cryptography,
the two keys are called the private key and the public key



Private key: This key must be know only by its owner.
Public key: This key is known to everyone (it is public)
Relation between both keys: What one key encrypts, the other one
decrypts, and vice versa. That means that if you encrypt something
with my public key (which you would know, because it's public :-), I
would need my private key to decrypt the message.
A secure conversation using public-key cryptography
In a basic secure conversation using public-key cryptography, the sender
encrypts the message using the receiver's public key. Remember that this key
is known to everyone. The encrypted message is sent to the receiving end,
who will decrypt the message with his private key. Only the receiver can
decrypt the message because no one else has the private key. Also, notice ho
Pros and cons of public-key systems
Public-key systems have a clear advantage over symmetric algorithms: there
is no need to agree on a common key for both the sender and the receiver. As
seen in the previous example, if someone wants to receive an encrypted
message, the sender only needs to know the receiver's public key (which the
receiver will provide; publishing the public key in no way compromises the
79
secure transmission). As long as the receiver keeps the private key secret, no
one but the receiver will be able to decrypt the messages encrypted with the
corresponding public key. This is due to the fact that, in public-key systems, it
is relatively easy to compute the public key from the private key, but very
hard to compute the private key from the public key (which is the one
everyone knows). In fact, some algorithms need several months (and even
years) of constant computation to obtain the private key from the public key.
Another important advantage is that, unlike symmetric algorithms, public-key
systems can guarantee integrity and authentication, not only privacy. The
basic communication seen above only guarantees privacy. We will shortly see
how integrity and authentication fit into public-key systems.
The main disadvantage of using public-key systems is that they are not as
fast as symmetric algorithms.
Public-key cryptography refers to a cryptographic system requiring two
separate keys, one of which is secret and one of which is public. Although
different, the two parts of the key pair are mathematically linked. One key
locks or encrypts the plaintext, and the other unlocks or decrypts
the ciphertext. Neither key can perform both functions by itself. The public
key may be published without compromising security, while the private key
must not be revealed to anyone not authorized to read the messages.
Public-key cryptography uses asymmetric key algorithms (such as RSA), and
can also be referred to by the more generic term "asymmetric key
cryptography." The algorithms used for public key cryptography are based on
mathematical relationships (the most notable ones being the integer
factorization and discrete logarithm problems) that presumably have no
efficient solution. Although it is computationally easy for the intended
recipient to generate the public and private keys, to decrypt the message
using the private key, and easy for the sender to encrypt the message using
the public key, it is extremely difficult (or effectively impossible) for anyone to
derive the private key, based only on their knowledge of the public key. This
80
is why, unlike symmetric key algorithms, a public key algorithm
does not require
a secure initial exchange of
one
(or
more) secret
keys between the sender and receiver. The use of these algorithms also
allows the authenticity of a message to be checked by creating a digital
signature of the message using the private key, which can then be verified by
using the public key. In practice, only ahash of the message is typically
encrypted for signature verification purposes.
Public-key cryptography is a fundamental, important, and widely used
technology. It is an approach used by many cryptographic algorithms
and cryptosystems. It underpins such Internet standards as Transport Layer
Security (TLS), PGP, and GPG. There are three primary kinds of public key
systems: public key distribution systems, digital signature systems, and public
key cryptosystems, which can perform both public key distribution and digital
signature services. Diffie–Hellman key exchange is the most widely used
public key distribution system, while the Digital Signature Algorithm is the
most widely used digital signature system.
81
Session 9
Presentation Layer
The presentation layer is concerned with preserving the meaning of
information sent across a network. The presentation layer may represent
(encode) the data in various ways (e.g. data compression, or encryption), but
the receiving peer will convert the encoding back into its original meaning.
The presentation layer concerns itself with the following issues:
1. Data Format. Converting the complex data structures used by an
application strings, integers, structures, etc. | into a byte stream transmitted
across the network. Representing information in such a way that
communicating peers agree to the format of the data being exchanged. E.g.,
How many bits does an integer contain? ASCII or EBCDIC character set?
2. Compressing data to reduce the amount of transmitted data (e.g., to save
money).
3. Security and Privacy issues:
Encryption : Scrambling the data so that only authorized participants can
unscramble the messages of a conversation. Recall, that it's easy to \wiretap"
transmission media such as Ethernets.
Authentication : Verifying that the remote party really is the party they
claim to be rather than an impostor.
Abstract Syntax Notation
Abstract Syntax Notation (ASN.1) is an ISO standard that addresses the issue
of
representing, encoding, transmitting, and decoding data structures. It
consists of two parts:
1. An abstract syntax that describes data structures in an unambiguous way.
The
syntax allows programmers to talk about \integers", \character strings", and
\structures" rather than bits and bytes.
2. A transfer syntax that describes the bit stream encoding of ASN.1 data
objects.
Send: data and additional _elds to describe the type of data.Upon receipt of
data, the reverse operation takes place, with the receiver converting from
ASN.1 format to the internal representation of the local machine.
Alternative approaches to the data representation problem:
1. Have the sender convert data into the format expected by the receiver, so
that the receiver doesn't have to perform any decoding. The disadvantage to
this approach is that every sender needs to know how to encode data for
every possible target machine.
2. ASN.1 takes the approach of converting everything into a common form,
much like the \network standard representation" of TCP/IP. However, this
approach has the disadvantage that communication between two identical
machines results in (needless) conversions.
82
ASN.1's abstract syntax is similar in form to that of any high level
programming language.
For instance, consider the following C structure:
struct Student {
char name[50]; /* ``Foo Bar'' */
int grad; /* Grad student? (yes/no) */
float gpa; /* 1.1 */
int id; /* 1234567890 */
char bday[8]; /* mm/dd/yy */
}
Its ASN.1 counterpart is:
Student ::= SEQUENCE {
name OCTET STRING, -- 50 characters
grad BOOLEAN, -- comments preceded
gpa REAL, -- by ``--''
id INTEGER,
bday OCTET STRING -- birthday
}
Sun's XDR
Sun Microsystem's External Data Representation (XDR) is an alternative to
ASN.1. XDR
is much simpler than ASN.1, but less powerful. For instance:
1. XDR uses implicit typing. Communicating peers must know the type of any
exchanged data. In contrast, ASN.1 uses explicit typing; it includes type
information as part of the transfer syntax.
2. In XDR, all data is transferred in units of 4 bytes. Numbers are transferred
in network order, most significant byte first.
3. Strings consist of a 4 byte length, followed by the data (and perhaps
padding in the last byte). Contrast this with ASN.1.
4. Defined types include: integer, enumeration, Boolean,floating point, fixed
length array, structures, plus others.
One advantage that XDR has over ASN.1 is that current implementations of
ASN.1 execute significantly slower than XDR.
Data Compression
Why do data compression? What is it? Trying to reduce the amount of data
sent. Suppose that we wanted to transfer a 20 Mb file to another machine.
Would we really need to send 20 Mb of data? If the _le consisted entirely of
the letter \A", we could send the letter \A", followed by a count of the number
of times it appears in the file, and have the receiver regenerate the file. There
are three general approaches to data compression. Each approach assumes
that the data stream can be transformed into a more compact representation,
which the receiver reconstructs back into the original data.
83
Approach 1: Finite Set of Symbols
Consider a library with many branch offices in which the previous days
transactions are sent to every other branch after closing. Transactions consist
of checked out and returned books. We could exchange information in the
following ways:
1. We could send the name of the book, its author, the copy number, etc.
together with the type of transaction.
2. Alternatively, the library could maintain a site wide table assigning a unique
IDnumber to every book in every branch. Transactions could then refer to the
book's ID number, rather than its title. Because book IDs are small (e.g. a
few bytes), less data will be transmitted.
Note: The above technique is used throughout programming. We frequently
exchange pointers and array subscripts to avoid the cost of transferring large
amounts of data between subroutines.
The previous approach assumes that all objects occur with equal frequency,
and that the set of objects (e.g., books) is finite. If we examine text,
however, we immediately notice that some words appear more often than
others. We could reduce the number of bits needed to represent a document
by using a coding scheme that employs small code words to represent
common words and longer code words to represent words the appear
infrequently.
Approach 2: Huffman Encoding
Huffman encoding is a technique used to encode symbols according to the
frequency of their use. The algorithm is as follows:
1. Create a set of nodes, one node per symbol, with a node's value given by
the
probability of its occurrence in the data.
2. Find the two nodes having the smallest value, remove them from the set,
and create a new node having the two removed nodes as children, and assign
the new node a value that is the sum of its children's values. Add the new
node back to the set of nodes.
3. Repeat step 2 until only one node remains. We now have a tree, whose
probability value is one.
4. The encoding for each symbol is the path from the root to the symbol.
Using a code of 0 for a left child, 1 for a right child, the length of each
symbol's encoding is
proportional to the relative probability of its occurrence.
One drawback with Huffman encoding, however, is that symbols have
dithering lengths, making it relatively expensive (computationally) to decode.
Also, A single-bit error can wipe out the entire message.
Approach 3: Context Dependent Encoding
84
The last technique, context dependent encoding, recognizes that the
probability of a particular symbol occurring next depends on the previous
symbol. For instance, the probability that a \T" directly follows a \Q" is about
4 times less than the probability of a \U" following a \Q".
The main disadvantage of conditional probability methods is the increase in
table space.
Each symbol has its own table that gives the codes for those symbols
immediately following it. For K symbols, the tables will contain K2 entries. All
K symbols have K entries for the symbols that follow them.
One variation to this technique is as follows:
1. Use 5-bit code to represent symbols.
2. Have four different \modes", where the current mode determines the
meaning of symbols. Four symbols are reserved to denote a switch to another
mode. For
instance, different modes could represent upper-case characters, lower-case
characters, numeric and special characters, and control characters.
3. The underlying assumption is that lower-case letters are likely to follow
lower-case letters, numbers are likely to occur in groups, etc.
4. The occurrence of a mode symbol signi_es a mode change.
5. Our 5-bit code now represents 4 _ 28 = 112 di_erent values.
One advantage that the above technique has over Hu_man encoding is that
symbols are all fixed length, making encoding and decoding using table
lookups very efficient. In addition, it is more immune to transmission errors.
Run Length Encoding
Another alternative, run length encoding, is used to encode data containing
repetitive symbols. Consider binary strings of 0s and 1s. One way to handle
long runs of 0 is to use a k-bit symbol that tells how many 0 bits occurred
between consecutive 1s. A code word of all 1's means that the true distance is
2K � 1 plus the value of the following symbol(s). For example:
00010000101001100000000000000000000000100000001 (47 bits)
consists of runs of length 3, 4, 1, 2, 0, 23, and 7.
Using 4-bit symbols, it would be encoded as:
0011 0100 0001 0010 0000 1111 0100 0111, for 32 bits and
a savings of 15/47 = 30%.
Using 3-bit symbols, it would be encoded as:
011 100 001 010 000 111 111 111 010 111 000 for 33 bits.
Yet another variation is to encode the di_erence between the current value
and the previous value, as was used to reduce the number of bits needed in
pulse coded modulation (PCM).
85
OSI
Presentation
Layer
Protocol
Primitives:
Connection Release Primitive
Token Handling Primitive
P-RELEASE request
P-TOKEN-GIVE request
P-RELEASE indication
P-TOKEN-GIVE indication
P-RELEASE response
P-TOKEN-PLEASE request
P-RELEASE confirm
P-TOKEN-PLEASE indication
P-CONTROL-GIVE request
P-CONTROL-GIVE indication
Presentation Exception Reporting Activity Management Primitive
Primitive
P-P-EXCEPTION-REPORT indication
P-ACTIVITY-START request
P-U-EXCEPTION-REPORT request
P-ACTIVITY-START indication
P-U-EXCEPTION-REPORT indication
P-ACTIVITY-RESUME request
Synchronization
Primitive
P-ACTIVITY-RESUME indication
Services
P-SYNC-MINOR request
P-ACTIVITY-INTERRUPT request
P-SYNC-MINOR indication
P-ACTIVITY-INTERRUPT indication
P-SYNC-MINOR response
P-ACTIVITY-NTERRUPT response
P-SYNC-MINOR confirm
P-ACTIVITY-INTERRUPT confirm
P-SYNC-MAJOR request
P-ACTIVITY-DISCARD request
P-SYNC-MAJOR indication
P-ACTIVITY-DISCARD indication
P-SYNC-MAJOR response
P-ACTIVITY-DISCARD response
P-SYNC-MAJOR confirm
P-ACTIVITY-DISCARD confirm
P-ACTIVITY-END request
P-ACTIVITY-END indication
86
P-ACTIVITY-END response
P-ACTIVITY-END confirm
Services

Data conversion

Character code translation

Compression

Encryption and Decryption
Data conversion

Data conversion is the conversion of computer data from one format to
another. Throughout a computer environment, data is encoded in a variety of
ways. For example, computer hardware is built on the basis of certain
standards, which requires that data contains, for example, parity bit checks.
Similarly, the operating system is predicated on certain standards for data
and file handling. Furthermore, each computer program handles data in a
different manner. Whenever any one of these variable is changed, data must
be converted in some way before it can be used by a different computer,
operating system or program. Even different versions of these elements
usually involve different data structures. For example, the changing
of bits from one format to another, usually for the purpose of application
interoperability or of capability of using new features, is merely a data
conversion. Data conversions may as simple as the conversion of a text
file from one character encoding system to another; or more complex, such
as the conversion of office file formats, or the conversion of image and audio
file formats.
There are many ways in which data is converted within the computer
environment. This may be seamless, as in the case of upgrading to a newer
version of a computer program. Alternatively, the conversion may require
processing by the use of a special conversion program, or it may involve a
complex process of going through intermediary stages, or involving complex
"exporting" and "importing" procedures, which may converting to and from a
tab-delimited or comma-separated text file. In some cases, a program may
recognize several data file formats at the data input stage and then is also
capable of storing the output data in a number of different formats. Such a
program may be used to convert a file format. If the source format or target
format is not recognized, then at times third program may be available which
permits the conversion to an intermediate format, which can then be
reformatted using the first program. There are many possible scenarios.
87

Compression
In computer science and information theory, data compression, source
coding, or bit-rate
reduction involves encoding
information using
fewer bits than
the
original
representation.
Compression
can
be
either lossy or lossless. Lossless compression reduces bits by identifying and
eliminating statistical
redundancy.
No
information
is lost in
lossless
compression. Lossy compression reduces bits by identifying marginally
important information and removing it. The process of reducing the size of a
data file is popularly referred to as data compression, although its formal
name is source coding (coding done at the source of the data, before it is
stored or transmitted).
Compression is useful because it helps reduce resources usage, such as data
storage space or transmission capacity. Because compressed data must be
decompressed to use, this extra processing imposes computational or other
costs through decompression, this situation is far from being a free lunch.
Data compression is subject to a space-time complexity trade-off. For
instance,
a
compression
scheme
for
video
may
require
expensive hardware for the video to be decompressed fast enough to be
viewed as it is being decompressed, and the option to decompress the video
in full before watching it may be inconvenient or require additional storage.
The design of data compression schemes involve trade-offs among various
factors, including the degree of compression, the amount of distortion
introduced (e.g., when using lossy data compression), and the computational
resources required to compress and uncompress the data.
New alternatives to traditional ‘sample-sense-compress’ systems (which
sample a full resolution then compress), provide efficient resource usage
based on principles of compressed sensing. Compressed sensing techniques
circumvent the need for data-compression by sampling off a cleverly selected
basis.
88
Session 10
Application Layer
Application layer design issues:
There are several common issues that you must consider as your develop
your design. These issues can be categorized into specific areas of the design.
 Caching
 Communication
 Composition
 Exception Management
 Navigation
 User Experience
 User Interface
 Validation
 Caching improves application performance and UI responsiveness.
 You can use data caching in the presentation layer to optimize data
lookups and avoid network round trips, and to store the results of
expensive or repetitive processes to avoid unnecessary duplicated
processing.
 Guidelines for designing the caching strategy:
 Choose the appropriate location for your cache, such as in memory or
on disk.
Example: If your application is deployed in Web farm, avoid using local
caches that must be synchronized. In general, for Web and application
farm deployments, consider using a transactional resource manager such as
Microsoft SQL Server, or a product that supports distributed caching such
as the Danga Interactive "Memcached" technology or the Microsoft "Velocity"
caching mechanism.
 Consider caching data in a ready to use format when working with an
in-memory cache.
For example, use a specific object instead of caching raw database data.
However, avoid caching volatile data as the cost of caching may exceed that
of recreating or fetching the data again if it constantly changes.
 Do not cache sensitive data unless you encrypt it.
 Do not depend on data still being in your cache; it may have been
removed. Also, consider that the cached data may be stale.
 Consider authorization rights for cached data. Only cache data for
which you can apply appropriate authorization if users in different roles
may access the data.
 If you are using multiple threads, ensure that all access to the cache is
thread-safe.
 Communication
 Handle long-running requests with user responsiveness in mind, as well
as code maintainability and testability.
89
 Guidelines for designing request processing:
 Consider using asynchronous operations or worker threads to avoid
blocking the UI for long-running actions in Windows Forms and WPF
applications. In ASP.NET, consider using AJAX to perform asynchronous
requests. Provide feedback to the user on the progress of the long
running action.
 Avoid mixing your UI processing and rendering logic.
 When making expensive calls to remote sources or layers, such as
when calling Web services or querying a database, consider if it makes
more sense to make these callschatty (many smaller requests)
or chunky (one large request).
Composition
 Composition patterns help you to implement sharing, reuse, and
replacement of presentation logic and views.
 Guidelines for designing your UI composition strategy:
 Avoid dependencies between components.
 Consider creating templates with placeholders.
 Consider composing views from reusable modular parts.
 Be cautious when using layouts generated dynamically at run time,
which can be difficult to load and maintain. Investigate patterns and
third-party libraries that support dynamic layout and injection of views
and presentation at runtime.
 When communicating between presentation components, consider
using
loosely
coupled
communication
patterns
such
as
Publish/Subscribe. This will lower the coupling between the components
and improve testability and flexibility
Exception Management
.
 Design a centralized exception management mechanism for your
application that catches and manages unexpected exceptions in a
consistent way.
 Guidelines for designing your exception management strategy:
 Provide user friendly error messages to notify users of errors in the
application, but ensure that you avoid exposing sensitive data in error
pages, error messages, log files, and audit files.
 Ensure that you catch exceptions that will not be caught elsewhere
(such as in a global error handler), and clean up resources and state
after an exception occurs.
 Differentiate between system exceptions and business errors. In the
case of business errors, display a user friendly error message and allow
the user to retry the operation. In the case of system exceptions, check
to see if an issue such as a service or database failure caused the
90

exception, display a user friendly error message, and log the error
message to assist in troubleshooting.
Only catch exceptions that you can handle, and avoid the use of custom
exceptions when not necessary. Do not use exceptions to control
application logic flow.
 Navigation
 Design your navigation strategy so that users can navigate easily
through your screens or pages.
 Ensure that you display navigation links and controls in a consistent
way throughout your application to reduce user confusion and to hide
application complexity.
 Guidelines for designing your navigation strategy:
 Design toolbars and menus to help users find functionality provided by
the UI.
 Consider using wizards to implement navigation between forms in a
predictable way, and determine how you will preserve navigation state
between sessions if this is necessary.
 Avoid duplication of logic for navigation event handlers, and avoid hardcoding navigation paths where possible. Consider using the Command
pattern to handle common actions from multiple sources.
 User Experience
 Consider the following guidelines when designing for user experience:
 Do not design overloaded or over complex interfaces. Provide a clear
path through the application for each key user scenario, and consider
using colors and noninvasive animations to draw the user's attention to
important changes in the UI, such as state changes.
 Provide helpful and informative error messages, without exposing
sensitive data.
 For actions that might take longer to complete, try to avoid blocking
the user. At a minimum, provide feedback on the progress of the
action, and consider if the user should be able to cancel the process.
 Consider empowering the user by providing flexibility and customization
of
the
UI
through
configuration
and,
where
appropriate,
personalization.
 User Interface
 Guidelines to be considered when designing your user interface:
91
Consider using a Separated Presentation pattern such as MVP to
separate the layout design from interface processing. Use templates to
provide a common look and feel to all of the UI screens, and maintain a
common look and feel for all elements of your UI to maximize
accessibility and ease of use. Avoid over complex layouts.
 Consider using forms-based input controls for data collection tasks, a
document-based input mechanism for collecting more free form input
such as text or drawing documents, or a wizard-based approach for
more sequenced or workflow driven data collection tasks.
 Avoid using hard-coded strings, and using external resources for text
and layout information, especially if your application will be localized
 Consider accessibility in your design. You should consider users with
disabilities when designing your input strategy.
 Take into account different screen sizes and resolutions, and different
device and input types such as mobile devices, touch screens, and pen
and ink—enabled devices.
Validation

 Designing an effective input and data validation strategy is critical for
the security and correct operation of your application.
 Consider the following guidelines when designing your input and data
validation strategy:
 Input validation should be handled by the presentation layer, whilst
business rule validation should be handled by the business layer.
 Design your validation strategy to constrain, reject, and sanitize
malicious input. Investigate design patterns and third party libraries
that can assist in implementing validation. Identify business rules that
are appropriate for validation, such as transaction limits, and
implement comprehensive validation to ensure that these rules are not
compromised.
 Ensure that you correctly handle validation errors, and avoid exposing
sensitive information in error messages.
92
Session 11
The Application Layer, also known as Layer 7 of the OSI Reference Model, is
the top layer of the model and provides the user interface to a variety of
network-related information services. Together with the Presentation Layer, it
provides the interoperability element of the internetwork. Where the
Presentation Layer is about syntax, the Application Layer is about semantics.
It defines generalized services that applications need. Note that this layer is
not typically where the applications themselves reside. The applications you
use every day sit above the OSI Reference Model and draw services from the
interface to the software that implements the model in your computer system.
Applications services include:

File Transfer, Access, and Management (FTAM) services

General document and message interchange services, such as email.
The Application Layer also provides other services.

Identification of communication partner by name or address (directory
services)

Selection of dialogue discipline and agreement of Presentation Layer
services
Support for network standard virtual terminals


Printing services
93