PowerPoint_merge (2).pdf

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Chapter 21
File Transfer:
FTP
and
TFTP
1
TCP/IP Protocol Suite

OBJECTIVES:
 To discuss FTP and two connections used in this protocol:
control connection and data connection.
 To discuss six classes of commands sent by the client to establish
communication with the server.
 To explain three types of file transfer transferred by FTP.
 To show some user-friendly commands used by some FTP
interfaces.
 To discuss anonymous FTP and its application.
 To discuss how file transfer can be done using a secure channel.
 To discuss TFTP as a simple file transfer protocol without the
complexities and sophistication of FTP.
2

OBJECTIVES (continued):
 To discuss five types of TFTP messages and their applications.
 To discuss the sorcerer’s apprentice bug related to TFTP’s flow-
and error-control mechanisms.
 To show how TFTP can be used in conjunction with DHCP to
initialize devices by downloading configuration files.
3

Chapter
Outline
21.1 FTP
21.2 TFTP
4

21-1 FTP
File Transfer Protocol (FTP) is the standard
mechanism provided by TCP/IP for copying a file from
one host to another. Although transferring files from
one system to another seems simple and
straightforward, some problems must be dealt with
first. For example, two systems may use different file
name conventions. Two systems may have different
ways to represent text and data. Two systems may
have different directory structures. All of these
problems have been solved by FTP in a very simple
and elegant approach.
5

Topics Discussed in the Section
 Connections
 Communication
 Command Processing
 File Transfer
 Anonymous FTP
 Security for FTP
 The sftp Program
6

FTP uses the services of TCP.
It needs two TCP connections. The well-
known port 21 is used for the control
connection and the well-known
port 20 for the data connection.
Note
7

Figure 21.1 FTP
8

Figure 21.2 Opening the control connection
9

Figure 21.3 Creating the data connection
10

Figure 21.4 Using the control connection
11

Figure 21.5 Using the data connection
12

Figure 21.6 Command processing
13

Figure 21.7 File transfer
22

Figure 21.8 shows an example of using FTP for retrieving a list
of items in a directory.
Example 21.1
23

Figure 21.8 Example 21.1
220 (Service ready)
USER forouzan
LIST /usr/user/forouzan/reports
PASS xxxxxx
125 (Data connection OK)
331 (User name OK. Password?)
PORT 8888
150 (Data connection opens shortly)
230 (User login OK)
1
2
3
4
5
6
7
8
9
List of files or directories
List of files or directories
10
11
QUIT
226 (Closing data connection)
221 (Service closing)
12
13
14
DATA
TRANSFER
24

The following shows an actual FTP session that parallels
Example 21.1. The colored lines show the responses from the
server control connection; the black lines show the commands
sent by the client. The lines in white with black background
show data transfer.
Example 21.2
25

Figure 21.9 shows an example of how an image (binary) file is
stored.
Example 21.3
26

220 (Service ready)
USER forouzan
TYPE EBCDIC
STRU R
STOR/usr/user/forouzan/reports/file1
PASS xxxxxx
200 (OK)
200 (OK)
250 (OK)
331 (User name OK. Password?)
PORT 1267
150 (Data connection opens shortly)
230 (User login OK)
1
2
3
4
5
6
7
8
9
10
11
12
13
DATA
TRANSFER
Records of file ..........
Records of file ..........
15
14
QUIT
226 (Closing data connection)
221 (Service closing)
16
17
18
27

We show an example of anonymous FTP. We assume that
some public data are available at internic.net.
Example 21.4
28

21-2 TFTP
There are occasions when we need to simply copy a
file without the need for all of the features of the FTP
protocol. For example, when a diskless workstation
or a router is booted, we need to download the
bootstrap and configuration files. Here we do not
need all of the sophistication provided in FTP. We
just need a protocol that quickly copies the files.
29

 Messages
 Connection
 Data Transfer
 UDP Ports
 TFTP Example
 TFTP Options
 Security
 Applications
30

TFTP uses the services of UDP on the
well-known port 69.
Note
31

Figure 21.10 Message categories
32

Figure 21.11 RRQ format
33

Figure 21.12 WRQ format
34

Figure 21.13 Data Format
35

Figure 21.14 ACK format
36

Figure 21.15 ERROR format
37

Figure 21.16 Connection establishment
39

Figure 21.17 Server’s apprentice bug
40

Figure 21.18 UDP port numbers used by TFTP
41

Figure 21.19 TFTP example
42

Figure 21.20 Use of TFTP with DHCP
1
2
3
4
5
43

Chapter 22
World Wide
Web
and
HTTP
44

OBJECTIVES:
 To discuss the architecture of WWW and describe the concepts
of hypertext and hypermedia.
 To describe Web clients and Web servers and their components.
 To define URL as a tool to identify a Web server.
 To introduce three different Web documents: static document,
dynamic document, and active document.
 To discuss HTTP and its transactions.
 To define and list the fields in a request message.
45

 To define non-persistent and persistent connections in HTTP.
 To introduce cookies and their applications in HTTP.
 To discuss Web caching, its application, and the method used to
update the cache.
46

Chapter
Outline
22.1 Architecture
22.2 Web Document
22.3 HTTP
47

22-1 ARCHITECTURE
The WWW today is a distributed client-server
service, in which a client using a browser can access
a service using a server. However, the service
provided is distributed over many locations called
sites. Each site holds one or more documents,
referred to as Web pages. Each Web page,
however, can contain some links to other Web pages
in the same or other sites. In other words, a Web
page can be simple or composite.
48

 Hypertext and Hypermedia
 Web Client (Browser)
 Web Server
 Uniform Resource Locator (URL)
49

Assume we need to retrieve a Web page that contains the
biography of a famous character with some pictures, which are
embedded in the page itself. Since the pictures are not stored
as separate files, the whole document is a simple Web page. It
can be retrieved using one single request/ response transaction,
as shown in Figure 22.1.
Example 22.1
50

Request
1
Response 2
51

Now assume we need to retrieve a scientific document that
contains one reference to another text file and one reference to
a large image. Figure 22.2 shows the situation. The main
document and the image are stored in two separate files in the
same site (file A and file B); the referenced text file is stored in
another site (file C). Since we are dealing with three different
files, we need three transactions if we want to see the whole
document. The first transaction (request/response) retrieves a
copy of the main document (file A), which has a reference
(pointer) to the second and the third files.
Example 22.2
52

Request 1
1
Response 1 2
Request 2
3
Response 2 4
Request 3
5
Response 3 6
53

A very important point we need to remember is that file A, file B,
and file C in Example 22.2 are independent Web pages, each
with independent names and addresses. Although references to
file B or C are included in file A, it does not mean that each of
these files cannot be retrieved independently. A second user
can retrieve file B with one transaction. A third user can retrieve
file C with one transaction.
Example 22.3
54

Figure 22.3 Browser
55

Figure 22.4 URL
56

22-2 WEB DOCUMENTS
The documents in the WWW can be grouped into
three broad categories: static, dynamic, and active.
The category is based on the time the contents of
the document are determined.
57

 Static Documents
 Dynamic Documents
 Active Documents
58

Figure 22.5 Static document
Request
1
Static document
2
59

HTML, XML, XSL, and XHTML are
discussed in Appendix E.
Note
60

Figure 22.6 Dynamic document using CGI
Request
1
Dynamic document
2
61

Figure 22.7 Dynamic document using server-site script
Request
1
Dynamic document
2
62

Dynamic documents are sometimes
referred to as server-site dynamic
documents.
Note
63

Figure 22.8 Active document using Java applet
Request
1
Result
Run the applet
to get the result
Active document
2
Applet
64

Figure 22.9 Active document using client-site script
Request
1
Run the JavaScript
(JS) to get the result
Result
2
JavaScript
JS
65

Active documents are sometimes
referred to as client-site dynamic
documents.
Note
66

22-3 HTTP
The Hypertext Transfer Protocol (HTTP) is a protocol
used mainly to access data on the World Wide Web.
HTTP functions like a combination of FTP (Chapter
21) and SMTP (Chapter 23). It is similar to FTP
because it transfers files and uses the services of
TCP. However, it is much simpler than FTP because
it uses only one TCP connection. There is no
separate control connection; only data are
transferred between the client and the server.
67

 HTTP Transaction
 Conditional Request
 Persistence
 Cookies
 Web Caching: Proxy Server
 HTTP Security
68

HTTP uses the services of TCP on well-
known port 80.
Note
69

Figure 22.10 HTTP transaction
1
Request message
Request line
Headers
Body
A blank line
2
Response message
Status line
Headers
Body
A blank line
70

Figure 22.11 Format of the request message
71

Figure 22.12 Format of the response message
74

This example retrieves a document (see Figure 22.13). We use
the GET method to retrieve an image with the path
/usr/bin/image1. The request line shows the method (GET), the
URL, and the HTTP version (1.1). The header has two lines that
show that the client can accept images in the GIF or JPEG
format. The request does not have a body. The response
message contains the status line and four lines of header. The
header lines define the date, server, MIME version, and length
of the document. The body of the document follows the header.
Example 22.4
77

78

In this example, the client wants to send data to the server. We
use the POST method. The request line shows the method
(POST), URL, and HTTP version (1.1). There are four lines of
headers. The request body contains the input information. The
response message contains the status line and four lines of
headers. The created document, which is a CGI document, is
included as the body (see Figure 22.14).
Example 22.5
79

80

HTTP uses ASCII characters. The following shows how a client
can directly connect to a server using TELNET, which logs into
port 80.
Example 22.6
81

The following shows how a client imposes the modification data
and time condition on a request.
Example 22.7
The status line in the responds shows the file is not modified
after the defined point of time. The body of the response
message is also empty.
82

Figure 22.15 shows an example of a nonpersistent connection.
The client needs to access a file that contains two links to
images. The text file and images are located on the same
server.
Example 22.8
83

84

HTTP version 1.1 specifies a persistent
connection by default.
Note
85

Figure 22.16 shows the same scenario as Example 22.8, but
using persistent connection.
Example 22.9
86

87

Figure 22.17 shows a scenario in which an electronic store can
benefit from the use of cookies. Assume a shopper wants to buy
a toy from an electronic store named BestToys. The shopper
browser (client) sends a request to the BestToys server.
Example 22.10
88

A customer file is
created with ID: 12343
Request
GET BestToys.com HTTP/1.1
1
Response
HTTP/1.1 200 OK
Set-Cookie: 12343
Page Representing the Toys
2
A vendor file is created
with cookie: 12343
Update
3
Request
GET image HTTP/1.1
Response
Cookie: 12343
Cookie
4
HTTP/1.1 200 OK
Page Representing the price
Update
5
Request
GET image HTTP/1.1
Cookie: 12343
Information about the payment
Cookie
6
Response
HTTP/1.1 200 OK
Order confirmation
Update
89

Chapter 23
Electronic
Mail:
SMTP, POP
IMAP, and
MIME
90

OBJECTIVES:
 To explain the architecture of electronic mail using four
scenarios.
 To explain the user agent (UA), services provided by it, and two
types of user agents.
 To explain the mechanism of sending and receiving e-mails.
 To introduce the role of a message transfer agent and Simple
Mail
 Transfer Protocol (SMTP) as the formal protocol that handles
MTA.
 To explain e-mail transfer phases.
 To discuss two message access agents (MAAs): POP and IMAP.
91

 To discuss MIME as a set of software functions that transforms
non-ASCII data to ASCII data and vice versa.
 To discuss the idea of Web-based e-mail.
 To explain the security of the e-mail system.
92

Chapter
Outline
23.1 Architecture
23.2 User Agent
23.3 Message Transfer Agent
23.4 Message Access Agent
23.5 MIME
23.6 Web-Based Mail
23.7 Electronic Mail Security
93

23-1 ARCHITECTURE
To explain the architecture of e-mail, we give four
scenarios. We begin with the simplest situation and
add complexity as we proceed. The fourth scenario
is the most common in the exchange of e-mail.
94

 First Scenario
 Second Scenario
 Third Scenario
 Fourth Scenario
95

Figure 23.1 First scenario
1
2
96

When the sender and the receiver of an
e-mail are on the same mail server,
we need only two user agents.
Note
97

Figure 23.2 Second scenario
1
2 3 4
5
98

When the sender and the receiver of an
e-mail are on different mail servers,
we need two UAs and a pair of MTAs
(client and server).
Note
99

Figure 23.3 Third scenario
1
2
3
4
5 6
7
100

When the sender is connected to the
mail server via a LAN or a WAN, we
need two UAs and two pairs of MTAs
(client and server).
Note
101

Figure 23.4 Fourth scenario
1
2
3
4
5
6
8
9
102

When both sender and receiver are
connected to the mail server via a LAN
or a WAN, we need two UAs, two pairs of
MTAs (client and server), and a pair of
MAAs (client and server). This is the
most common situation today.
Note
103

Figure 23.5 Push versus pull
104

23-2 USER AGENT
The first component of an electronic mail system is
the user agent (UA). It provides service to the user to
make the process of sending and receiving a
message easier.
105

 Services Provided by a User Agent
 User Agent Types
 Sending Mail
 Receiving Mail
 Addresses
 Mailing List or Group List
106

Some examples of command-driven
user agents are mail, pine, and elm.
Note
107

Some examples of GUI-based user
agents are Eudora, Outlook,
And Netscape.
Note
108

Figure 23.6 Format of an email
109

Figure 23.7 E-mail address
110

23-3 MESSAGE TRANSFER AGENT
The actual mail transfer is done through message
transfer agents (MTAs). To send mail, a system must
have the client MTA, and to receive mail, a system
must have a server MTA. The formal protocol that
defines the MTA client and server in the Internet is
called Simple Mail Transfer Protocol (SMTP). As we
said before, two pairs of MTA client-server programs
are used in the most common situation (fourth
scenario). Figure 23.8 shows the range of the SMTP
protocol in this scenario.
111

 Commands and Responses
 Mail Transfer Phases
112

Figure 23.8 SMTP range
113

Figure 23.9 Commands and responses
114

Figure 23.10 Connection establishment
220 service ready 1
HELO: deanza.edu
2
250 OK 3
117

Figure 23.11 Message transfer
118

Figure 23.12 Connection termination
1 QUIT
2
221 service closed
119

Let us see how we can directly use SMTP to send an e-mail and
simulate the commands and responses we described in this
section. We use TELNET to log into port 25 (the well-known port
for SMTP). We then use the commands directly to send an e-
mail. In this example, forouzanb@adelphia.net is sending an e-
mail to himself. The first few lines show TELNET trying to
connect to the adelphia mail server.
Example 23.1
After connection, we can type the SMTP commands and then
receive the responses as shown below. We have shown the
commands in black and the responses in color. Note that we
have added for clarification some comment lines, designated by
the “=” sign. These lines are not part of the e-mail procedure.
120

Example 19.1 Continued
121

23-4 MESSAGE ACCESS AGENT
The first and the second stages of mail delivery use
SMTP. However, SMTP is not involved in the third
stage because SMTP is a push protocol; it pushes
the message from the client to the server. In other
words, the direction of the bulk data (messages) is
from the client to the server. On the other hand, the
third stage needs a pull protocol; the client must pull
messages from the server. The direction of the bulk
data are from the server to the client. The third stage
uses a message access agent.
122

 POP3
 IMAP4
123

Figure 23.13 Pop3 and IMAP4
124

Figure 23.14 Pop3
125

23-5 MIME
Electronic mail has a simple structure. Its simplicity,
however, comes with a price. It can send messages
only in NVT 7-bit ASCII format. In other words, it has
some limitations. Multipurpose Internet Mail Extensions
(MIME) is a supplementary protocol that allows non-
ASCII data to be sent through e-mail. MIME transforms
non-ASCII data at the sender site to NVT ASCII data
and delivers it to the client MTA to be sent through the
Internet. The message at the receiving site is
transformed back to the original data.
126

 MIME Headers
127

Figure 23.15 MIME
128

Figure 23.16 MIME header
129

Figure 23.17 Base64
132

Figure 23.18 Quoted printable
134

23-6 WEB-BASED MAIL
E-mail is such a common application that some
websites today provide this service to anyone who
accesses the site. Three common sites are Hotmail,
Yahoo, and Google. The idea is very simple. Let us
go through two cases:
135

 Case I
 Case II
136

Figure 23.19 Web-based e-mail, case 1
1
2
3
4
HTTP
transactions
137

Figure 23.20 Web-based e-mail, case 2
HTTP
transactions
HTTP
transactions
1 2 3
138

23-6 E-MAIL SECURITY
The protocol discussed in this chapter does not
provide any security provisions per se. However, e-
mail exchanges can be secured using two
application-layer securities designed in particular for
e-mail systems. Two of these protocols, Pretty Good
Privacy (PGP) and Secure MIME (SMIME) are
discussed in Chapter 30 after we have discussed the
basic network security.
139

Chapter 24
Network
Management:
SNMP
140

OBJECTIVES:
 To discuss SNMP as a framework for managing devices in an
internet using the TCP/IP protocol suite.
 To define a manager as a host that runs SNMP client and any
agents as a router or host that runs a server program.
 Discuss SMI and MIB, which are used by SNMP.
 To show how SMI names objects, defines the type of data, and
encodes data.
 To show how data types are defined using ASN.1.
 To show how SMI uses BER to encode data.
 To show the functionality of SNMP using three methods.
141

OBJECTIVES:
 To show how SNMP uses two different ports of UDP.
 To show how SNMPv3 has enhanced security features over
previous versions.
142

Chapter
Outline
24.1 Concept
24.2 Management Components
24.3 SMI
24.4 MIB
24.5 SNMP
24.6 UDP Ports
24.7 Security
143

24-1 CONCEPT
SNMP uses the concept of manager and agent. That
is, a manager, usually a host, controls and monitors
a set of agents, usually routers or servers (see
Figure 24.1).
144

 Managers and Agents
145

Figure 24.1 SNMP concept
146

24-2 MANAGEMENT COMPONENTS
To do management tasks, SNMP uses two other
protocols: Structure of Management Information
(SMI) and Management Information Base (MIB). In
other words, management on the Internet is done
through the cooperation of three protocols: SNMP,
SMI, and MIB, as shown in Figure 24.2.
147

 Role of SNMP
 Role of SMI
 Role of MIB
 An Analogy
 An Overview
148

Figure 24.2 Companion of network management on the Internet
149

SNMP defines the format of packets
exchanged between a manager and an
agent. It reads and changes the status of
objects (values of variables) in SNMP
packets.
Note
150

SMI defines the general rules for naming
objects, defining object types (including
range and length), and showing how to
encode objects and values.
Note
151

MIB creates a collection of named
objects, their types, and their
relationships to each other in an entity
to be managed.
Note
152

Figure 24.3 Comparing computer programming and network management
153

Figure 24.4 Management overview
1
2
3
Get Request
SNMP packet
4
Response
SNMP packet
5
6
154

24-3 SMI
The Structure of Management Information is a
component for network management. Its functions
are:
1. To name objects.
2. To define the type of data that can be stored in an
object.
3. To show how to encode data for transmission
over the network.
SMI is a guideline for SNMP. It emphasizes three
attributes to handle an object: name, data type, and
encoding method.
155

 Name
 Type
 Encoding Method
156

Figure 24.5 Object identifier
157

All objects managed by SNMP are given
an object identifier.
The object identifier always starts with
1.3.6.1.2.1.
Note
158

Figure 24.6 Conceptual data types
160

Figure 24.7 Encoding format
161

Figure 24.8 shows how to define INTEGER 14. Note that we
have used both binary representation and hexadecimal
representation for the tag. The size of the length field is from
Table 24.1.
Example 24.1
163

Figure 24.8 Example 24.1: INTEGER 14
164

Figure 24.9 shows how to define the OCTET STRING “HI.”
Example 24.2
165

Figure 24.9 Example 24.2: OCTET STRING “HI”
166

Figure 24.10 shows how to define ObjectIdentifier 1.3.6.1
(iso.org.dod.internet).
Example 24.3
167

Figure 24.10 Example 24.3: ObjectIndentifier 1.3.6.1
168

Figure 24.11 shows how to define IPAddress 131.21.14.8.
Example 24.4
169

Figure 24.11 Example 24.4: IPAddress 131.21.14.8
170

24-4 MIB
The Management Information Base, version 2
(MIB2) is the second component used in network
management. Each agent has its own MIB2, which is
a collection of all the objects that the manager can
manage. The objects in MIB2 are categorized under
10 different groups: system, interface, address
translation, ip, icmp, tcp, udp, egp, transmission, and
snmp. These groups are under the mib-2 object in
the object identifier tree (see Figure 24.12). Each
group has defined variables and/or tables.
171

 Accessing MIB Variables
 Lexicographic Ordering
172

Figure 24.12 mib-2
173

Figure 24.13 udp group
174

Figure 24.14 udp variables and tables
175

Figure 24.15 Indexes for udpTable
176

Figure 24.16 Lexicographic ordering
177

24-5 SNMP
SNMP uses both SMI and MIB in Internet network
management. It is an application program that
allows:
1. A manager to retrieve the value of an object
defined in an agent.
2. A manager to store a value in an object defined in
an agent.
3. An agent to send an alarm message about an
abnormal situation to the manager.
178

 PDUs
 Format
 Messages
179

Figure 24.17 SNMP PDUs
180

Figure 24.18 SNMP PDU format
181

Figure 24.19 SNMP message
184

In this example, a manager station (SNMP client) uses a
message with GetRequest PDU to retrieve the number of UDP
datagrams that a router has received (Figure 24.20). There is
only one VarBind sequence. The corresponding MIB variable
related to this information is udpInDatagrams with the object
identifier 1.3.6.1.2.1.7.1.0. The manager wants to retrieve a
value (not to store a value), so the value defines a null entity.
The bytes to be sent are shown in hexadecimal representation.
Example 24.4
185

186

Figure 24.21 Actual message sent for Example 24.5
187

24-6 UDP PORTS
SNMP uses the services of UDP on two well-known
ports, 161 and 162. The well-known port 161 is used
by the server (agent), and the well-known port 162 is
used by the client (manager).
188

Figure 24.2 Port numbers for SNMP
189

24-7 SECURITY
SNMPv3 has added two new features to the
previous version: security and remote administration.
SNMPv3 allows a manager to choose one or more
levels of security when accessing an agent. Different
aspects of security can be configured by the
manager to allow message authentication,
confidentiality, and integrity.
SNMPv3 also allows remote configuration of
security aspects without requiring the administrator
to actually be at the place where the device is
located.
190

Chapter 25
Multimedia
191

OBJECTIVES:
 To show how audio/video files can be downloaded for future use
or broadcast to clients over the Internet. The Internet can also be
used for live audio/video interaction. Audio and video need to be
digitized before being sent over the Internet.
 To discuss how audio and video files are compressed for
transmission through the Internet.
 To discuss the phenomenon called Jitter that can be created on a
packet-switched network when transmitting real-time data.
 To introduce the Real-Time Transport Protocol (RTP) and Real-
Time Transport Control Protocol (RTCP) used in multimedia
applications.
 To discuss voice over IP as a real-time interactive audio/video
application.
192

 To introduce the Session Initiation Protocol (SIP) as an
application layer protocol that establishes, manages, and
terminates multimedia sessions.
 To introduce quality of service (QoS) and how it can be
improved using scheduling techniques and traffic shaping
techniques.
 To discuss Integrated Services and Differential Services and how
they can be implemented.
 To introduce Resource Reservation Protocol (RSVP) as a
signaling protocol that helps IP create a flow and makes a
resource reservation.
193

Chapter
Outline
25.1 Introduction
25.2 Digitizing Audio and Video
25.3 Audio/Video Compression
25.4 Streaming Stored
Audio/Video
25.5 Streaming Live
Audio/Video
25.6 Real-Time Interactive
Audio/Video
25.7 RTP
25.8 RTCP 194

Chapter
Outline
(continued)
25.9 Voice Over IP
25.10 Quality of Service
25.11 Integrated Services
25.12 Differentiated Services
195

25-1 INTRODUCTION
We can divide audio and video services into three
broad categories: streaming stored audio/video,
streaming live audio/video, and interactive
audio/video, as shown in Figure 25.1. Streaming
means a user can listen (or watch) the file after the
downloading has started.
196

Figure 25.1 Internet audio/video
197

Streaming stored audio/video refers to
on-demand requests for compressed
audio/video files.
Note
198

Streaming live audio/video refers to
the broadcasting of radio and TV
programs through the Internet.
Note
199

Interactive audio/video refers to the use
of the Internet for interactive
audio/video applications.
Note
200

25-2 DIGITIZING AUDIO AND VIDEO
Before audio or video signals can be sent on the
Internet, they need to be digitized. We discuss audio
and video separately.
201

 Digitizing Audio
 Digitizing Video
202

Compression is needed to send video
over the Internet.
Note
203

25-3 AUDIO AND VIDEO COMPRESSION
To send audio or video over the Internet requires
compression. In this section, we first discuss audio
compression and then video compression.
204

 Audio Compression
 Video Compression
205

Figure 25.2 JPEG gray scale
206

Figure 25.3 JPEG process
207

Figure 25.4 Case 1: uniform gray scale
208

Figure 25.5 Case2: two sections
209

Figure 25.6 Case 3 : gradient gray scale
210

Figure 25.7 Reading the table
211

Figure 25.8 MPEG frames
212

Figure 25.9 MPEG frame construction
213

25-4 STREAMING STORED
AUDIO/VIDEO
Now that we have discussed digitizing and
compressing audio/video, we turn our attention to
specific applications. The first is streaming stored
audio and video. Downloading these types of files
from a Web server can be different from
downloading other types of files. To understand the
concept, let us discuss three approaches, each with
a different complexity.
214

 First Approach: Using a Web Server
 Second Approach: Using a Web Server with Metafile
 Third Approach: Using a Media Server
 Fourth Approach: Using a Media Server and RTSP
215

Figure 25.10 Using a Web server
GET: audio/video file
1
RESPONSE
2
Audio/video
file
3
216

Figure 25.11 Using a Web server with a metafile
GET: metafile
1
RESPONSE
2
Metafile
3
4
RESPONSE
5
217

Figure 25.12 Using a media server
GET: metafile
1
RESPONSE
2
Metafile
3
4
RESPONSE
5
218

Figure 25.13 Using a media server and RSTP
GET: metafile
1
RESPONSE
2
Metafile
3
SETUP
4
RESPONSE
5
PLAY
6
RESPONSE
7
Audio/video
Stream
TEARDOWN
8
RESPONSE
9
219

25-5 STREAMING LIVE AUDIO/VIDEO
Streaming live audio/video is similar to the
broadcasting of audio and video by radio and TV
stations. Instead of broadcasting to the air, the
stations broadcast through the Internet. There are
several similarities between streaming stored
audio/video and streaming live audio/video. They are
both sensitive to delay; neither can accept
retransmission. However, there is a difference. In the
first application, the communication is unicast and
on-demand. In the second, the communication is
multicast and live.
220

25-6 REAL-TIME INTERACTIVE
AUDIO/VIDEO
In real-time interactive audio/video, people
communicate with one another in real time. The
Internet phone or voice over IP is an example of this
type of application. Video conferencing is another
example that allows people to communicate visually
and orally.
221

 Characteristics
222

Figure 25.14 Time relationship
223

Jitter is introduced in real-time data by
the delay between packets.
Note
224

Figure 25.15 Jitter
225

Figure 25.16 Timestamp
226

To prevent jitter, we can timestamp the
packets and separate the arrival time
from the playback time.
Note
227

Figure 25.17 Playback buffer
228

A playback buffer is required for
real-time traffic.
Note
229

A sequence number on each packet is
required for real-time traffic.
Note
230

Real-time traffic needs the support of
multicasting.
Note
231

Translation means changing the
encoding of a payload to a lower
quality to match the bandwidth
of the receiving network.
Note
232

Mixing means combining several
streams of traffic into one stream.
Note
233

TCP, with all its sophistication, is not
suitable for interactive multimedia
traffic because we cannot allow
retransmission of packets.
Note
234

UDP is more suitable than TCP for
interactive traffic. However, we need
the services of RTP, another
transport layer protocol, to make
up for the deficiencies of UDP.
Note
235

25-7 RTP
Real-time Transport Protocol (RTP) is the protocol
designed to handle real-time traffic on the Internet.
RTP does not have a delivery mechanism
(multicasting, port numbers, and so on); it must be
used with UDP. RTP stands between UDP and the
application program. The main contributions of RTP
are timestamping, sequencing, and mixing facilities.
236

 RTP Packet Format
 UDP Port
237

Figure 25.18 RTP packet header format
238

Figure 25.19 RTP packet header format
239

RTP uses a temporary even-numbered
UDP port.
Note
241

25-8 RTCP
RTP allows only one type of message, one that
carries data from the source to the destination. In
many cases, there is a need for other messages in a
session. These messages control the flow and
quality of data and allow the recipient to send
feedback to the source or sources. Real-Time
Transport Control Protocol (RTCP) is a protocol
designed for this purpose.
242

 Sender Report
 Receiver Report
 Source Description Message
 Bye Message
 Application-Specific Message
 UDP Port
243

Figure 25.20 RTCP message types
244

RTCP uses an odd-numbered UDP port
number that follows the port number
selected for RTP.
Note
245

25-9 VOICE OVER IP
Let us concentrate on one real-time interactive
audio/video application: voice over IP, or Internet
telephony. The idea is to use the Internet as a
telephone network with some additional capabilities.
Instead of communicating over a circuit-switched
network, this application allows communication
between two parties over the packet-switched
Internet. Two protocols have been designed to
handle this type of communication: SIP and H.323.
We briefly discuss both.
246

 SIP
 H.323
247

Figure 25.21 SIP messages
248

Figure 25.22 SIP formats
249

Figure 25.23 SIP simple session
INVITE: address, options
OK: address
ACK
Establishing
Communicating Exchanging audio
BYE
Terminating
250

Figure 25.24 Tracking the callee
INVITE
Lookup
Reply
INVITE
OK
OK
ACK
ACK
Exchanging audio
BYE
251

Figure 25.25 H.323 architecture
252

Figure 25.26 H.323 protocols
253

Figure 25.27 H.323 example
Find IP address
of gatekeeper
Q.931 message
for setup
RTP for audio exchange
RTCP for management
Q.931 message
for termination
254

25-10 QUALITY OF SERVICE
Quality of service (QoS) is an internetworking issue
that has been discussed more than defined. We can
informally define quality of service as something a
flow of data seeks to attain. Although QoS can be
applied to both textual data and multimedia, it is
more an issue when we are dealing with multimedia.
255

 Flow Characteristics
 Flow Classes
 Techniques to Improve QoS
 Resource Reservation
 Admission Control
256

Figure 25.28 Flow characteristics
257

Figure 25.29 FIFO queues
258

Figure 25.30 Priority queues
259

Figure 25.31 Weighted fair queuing
260

Figure 25.32 Leaky bucket
261

Figure 25.33 Leaky bucket implementation
262

A leaky bucket algorithm shapes bursty
traffic into fixed-rate traffic by
averaging the data rate.
It may drop the packets if the
bucket is full.
Note
263

Figure 25.34 Token bucket
264

The token bucket allows bursty traffic at
a regulated maximum rate.
Note
265

25-11 INTEGRATED SERVICES
IP was originally designed for best-effort delivery.
This means that every user receives the same level
of services. This type of delivery does not guarantee
the minimum of a service, such as bandwidth, to
applications such as real-time audio and video.
Integrated Services, sometimes called IntServ, is a
flow-based QoS model, which means that a user
needs to create a flow, a kind of virtual circuit, from
the source to the destination and inform all routers of
the resource requirement.
266

 Signaling
 Flow Specification
 Admission
 Service Classes
 RSVP
 Problems with Integrated Services
267

Integrated Services is a flow-based QoS
model designed for IP.
Note
268

Figure 25.35 Path messages
269

Figure 25.36 Resv messages
270

Figure 25.37 Reservation merging
271

Figure 25.38 Reservation styles
272

25-12 DIFFERENTIATED SERVICES
Differentiated Services (DS or Diffserv) was
introduced by the IETF (Internet Engineering Task
Force) to handle the shortcomings of Integrated
Services.
273

 DS Field
274

Differentiated Services is a class-based
QoS model designed for IP.
Note
275

Figure 25.39 DS field
276

Figure 25.40 Traffic conditioner
277

PowerPoint_merge (2).pdf

Recommended

Recommended

More Related Content

Similar to PowerPoint_merge (2).pdf

Similar to PowerPoint_merge (2).pdf (20)

Recently uploaded

Recently uploaded (20)

PowerPoint_merge (2).pdf