Transcript Document

Departamento de
Tecnología Electrónica
Some of these slides are
copyrighted by:
Chapter 1
Network Services
Network services
Computer Networking:
A Top Down Approach
5th edition.
Jim Kurose, Keith Ross
Addison-Wesley, April
2009.
1
Chapter 1: Network Services
 Chapter goals:
 understand most common data services in
networks:
Domain Name Servers (DNS)
 Remote access services
 File transfer services
 e-mail services
 Streaming services

Network services
2
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
3
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
4
Introduction
 Network Services -> key in companies and
organizations
 Work based in shared network resources &
distributed services
 Great diversity of services
Network services
5
Types of Network Services
Configuration and management
 Management of hosts.
 e.g. DHCP.
Remote Access
 Remote hosts are allowed to access to a network.
 e.g. SSH
File management
 File transfer, storage and management
 e.g. FTP.
Print services
 Printer share.
Information
 Information sharing and querying
 e.g. WWW, video sharing, IPTV
Communication
 User communication by means of text, audio and/or video messages
 e.g. e-mail, chat, videoconference, IP telephony, games online.
Network services
6
Architecture of Network Services
 Approaches
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P
Network services
7
Client/Server architecture
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:
client/server




communicate with server
may be intermittently
connected
may have dynamic IP
addresses
do not communicate
directly with each other
Network services
8
P2P architecture

no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses
Highly scalable but
difficult to manage
Network services
9
Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote
party:
 client-client connection: direct (not through
server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence
detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies
Network services
10
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
11
DNS: Domain Name System
Problem:
 Web browsing
Resource
holder’s host
Internet
User’s host
Network services
12
DNS: Domain Name System
Approach:
 From the user’s point of view
o Identifies resource holder by means of an address
(www.dte.us.es)
Network services
13
DNS: Domain Name System
Approach:
 May www.dte.us.es be used as an identifier of the queried
resource?
www.dte.us.es
Internet
User’s host
Resource
holder’s host
Network services
14
DNS: Domain Name System
Approach:
 From the network’s point of view
o IP addresses are used (routing & addressing)
IP
Internet
User’s host
Resource
holder’s host
Network services
15
DNS: Domain Name System
Approach:
 A mechanism to translate names into IP addresses is
necessary
www.dte.us.es
DNS
IP
Internet
User’s host
Resource
holder’s host
Network services
16
DNS: Domain Name System
Hosts, routers:
 IP address (32 bits) – used to address datagrama
 “name”, e.g.: www.google.es – used by human beings
How is the name generated?
Resource
holder’s host
130.213.40.3
Myserver.dte.us.es
Network services
17
DNS: Domain Name System
Name systems:
 Plain
o Non-hierarchic
o No location info
o E.g: ID card
 Hierarchic
o Structured
o Location info
o E.g: ZIP code
Network services
18
DNS: Domain Name System
Name Systems:
 Plain: simple -> centralized management
 Hierarchic -> distributed management (easier) - DNS
PLAIN
Hierarchic
Company X
Company Y
Company X
Company Y
pc1
pc1
pc1
pc1
Network services
19
DNS: Domain Name System
Name space:
 Inverted tree structure
 Every node is labelled with a name (max 63 characters)
 Start of the tree -> root (empty label)
 Variable depth (max 127 levels)
 Structure is similar to OS directories.
 To build a name : (root -> leave)
com.google.www
 Reading: www.google.com
Network services
20
DNS: Domain Name System
Name Space:
Important





Root is not labelled
Each domain is a subtree
Domains organized in levels
Top-level domains (TLD)
The same label may be assigned to two different hosts
unless they are brothers (in the tree)
Network services
21
DNS: Domain Name System
Name space:
my-pc.cont.fake.es.
Host
name
domain
Network services
22
DNS: Domain Name System
Space name:
my-pc.cont.fake.es.
Host
name
domain
FQDN
Network services
23
DNS: Domain Name System
IP Address
 4 bytes in decimal format (69.146.202.8)
 Hierarchical structure -> precise information about host
location
Name
 No host location information except maybe the country
Q: map between IP addresses and name ?
Network services
24
DNS: Domain Name System
Domain Name System:

distributed database

application-layer protocol
implemented in hierarchy of
many name servers
DNS services
 hostname to IP
address translation
 host aliasing
 Canonical, alias names
host, routers, name servers to
communicate to resolve names  mail server aliasing
(address/name translation)
 load distribution
 DNS uses UDP services
 replicated Web
servers: set of IP
addresses for one
canonical name
Network services
25
DNS: Domain Name System
Basic foundations
1.
2.
3.
4.
5.
Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized
database
 maintenance
App needs to know a remote
IP address associated to a
name
App requests IP address to
DNS client
DNS client sends a request to
the network
doesn’t
DNS client rcvs a reply
including IP addr
DNS client gives IP address to
app
scale!
Network services
26
Distributed, Hierarchical Database
 Big number of DNS servers hierarchically
organised and distributed all around the
world
 Database is also distributed by those servers
 Three types of servers:
o Root name servers
o Top-Level Domain (TLD) servers
o Authoritative servers
Network services
27
Distributed, Hierarchical Database
Root DNS Servers
com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
org DNS servers
pbs.org
DNS servers
edu DNS servers
poly.edu
umass.edu
DNS serversDNS servers
Client wants IP for www.amazon.com; 1st approx:
 client queries a root server to find com DNS server
 client queries com DNS server to get amazon.com
DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com
Network services
28
DNS: Root name servers
 contacted by local name server that can not resolve name
 root name server:



contacts authoritative name server if name mapping not known
gets mapping
returns mapping to local name server
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 21 locations)
e NASA Mt View, CA
f Internet Software C. Palo Alto,
k RIPE London (also 16 other locations)
i Autonomica, Stockholm (plus
28 other locations)
m WIDE Tokyo (also Seoul,
Paris, SF)
CA (and 36 other locations)
13 root name servers
worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
Network services
29
TLD and Authoritative Servers
 Top-level domain (TLD) servers:
 responsible for com, org, net, edu, etc, and all
top-level country domains uk, fr, es, jp.
 Network Solutions maintains servers for com TLD
 Educause for edu TLD
 Types
 Generic (gTLD)
 ≥ 3 characters
 Sponsored
 Unsponsored
Network services
30
TLD and Authoritative Servers

(Top-level domain, TLD) :
o
Types
o Geographic
 2 characters
 Represent countries (managed by the country
authorities)
 ICANN -> IANA
o .arpa
o Reserved
.test -> DNS tests
 .example -> documents
 .invalid -> installation & DNS tests for new servers
 .localhost -> loopback

Network services
31
TLD and Authoritative Servers
 Authoritative DNS servers:
 organization’s DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
 can be maintained by organization or service
provider
Network services
32
Local Name Server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company,
university) has one.

also called “default name server”
 when host makes DNS query, query is sent
to its local DNS server

acts as proxy, forwards query into hierarchy
Network services
33
DNS name
resolution example
root DNS server
 Host at cis.poly.edu
wants IP address for
gaia.cs.umass.edu
TLD DNS server
iterated query:
 contacted server replies
with name of server to
contact
 “I don’t know this name,
but ask this server”
recursive query:
 puts burden of name
resolution on contacted
name server
local DNS server
dns.poly.edu
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu
Network services
34
DNS name resolution example
iterative query
recursive query
root DNS
server
root DNS server
2
3
2
4
3
6
7
5 TLD DNS server
TLD DNS
server
6
1
8
local DNS server
7
dns.poly.edu
authoritative DNS server
dns.cs.umass.edu
1
5 4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu
gaia.cs.umass.edu
Network services
35
DNS: caching and updating records
 once (any) name server learns mapping, it
caches
mapping
 cache entries timeout (disappear) after some
time
 TLD servers typically cached in local name
servers
• Thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
Network services
36
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name,
 Type=A


name is hostname
value is IP address
 Type=NS
 name is domain (e.g.
foo.com)
 value is hostname of
authoritative name
server for this domain
value, type, ttl)
 Type=CNAME
name is alias name for some
“canonical” (the real) name
www.ibm.com is really

servereast.backup2.ibm.com

value is canonical name
 Type=MX

value is name of mailserver
associated with name
Network services
37
DNS protocol, messages
Name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used
Network services
38
DNS protocol, messages
Header, 6 fields, 2 bytes each
Network services
39
Inserting records into DNS
 example: new startup “Network Utopia”
 register name networkuptopia.com at DNS
(e.g., Network Solutions)


registrar
provide names, IP addresses of authoritative name server
(primary and secondary)
registrar inserts two RRs into com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 create authoritative server Type A record for
www.networkuptopia.com; Type MX record for
networkutopia.com
 How do people get IP address of your Web site?
Network services
40
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
41
Access remote services
 Virtual connection to a remote terminal
 “Substitutes” a direct cable
 Access remote services
 Telnet
 SSH
Network services
42
Telnet
 Basically -> TCP connection (port 23)
 Some other features negotiated in handshake
Telnet
client
Client reads
from terminal
Telnet
server
Server receives
from client
Client sends
to server
Operative
system
Server sends to
pseudo-terminal
Operative
system
TCP/IP
Internet
 No security –> even passwds are visible
 Solution: encryptation -> SSH
 Telnet is now quite obsolete
Network services
43
SSH
 SSH (Secure Shell): RFC 4251
 Aims similar to telnet -> provides security!
 TCP connection (port 22)
 Other additional functions
o Secure FTP
o support any insecure protocol -> tunneling
o secure connections for X Windows servers
-> graphic apps
Network services
44
SSH. Features
 Reduces security menaces:
o Man in the middle -> sniffer
o Spoofing
 Cyphered data -> 128-bit encryptation
 Security scheme -> public/private key (RSA)
 Client-server arquitecture.
 Two versions
o SSHv1 (1995) -> vulnerabilities
o SSHv2 (1997)
 Improvements over SSHv1
 Current standard
Network services
45
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
46
File Transfer Services
 File transfer between remote hosts
 Aims:
 Remote hosts may share files
 Client & server file systems are independent
 Efficient data transfer
 Two main protocols
 FTP (File Transfer Protocol): uses TCP -> reliable
• RFC 959

TFTP (Trivial File Transfer Protocol): uses UDP -> more
simple
• RFC 1350
Network services
47
TFTP
 Trivial File Transfer Protocol
File transfer
 Very simple protocol
 Non reliable -> UDP (port 69)
 No folders; no encryptation
 For transfering small files

Network services
48
TFTP
 TFTP messages
Opcode
(2 bytes)

Opcode: type of message
•
•
•
•
•

Variable length
data
01: RRQ (Read Request)
02: WRQ (Write Request)
03: DATA
04: ACK
05: Error message
Variable length data: depend on the opcode
Network services
49
TFTP
 TFTP messages -> RRQ & WRQ
Opcode
= 01
File
name
00
Transmission
mode
00
Option
N
00
Value
N
00
N options






RRQ is the first msg the client sends to server’s port
69 when getting a file
After RRQ -> DATA or Error
Transmission mode: ‘netascii’ or ‘octet’ (binary files)
N possible options with N values (one for each option)
WRQ message format is the same as RRQ -> but
opcode value = 02
After WRQ -> ACK (server must give permission) or
Error
Network services
50
TFTP
 TFTP messages -> DATA & ACK
Opcode
= 03
# block
(2 bytes)
Data block
of the transmitted file
0-512 bytes




# block -> 1-65535 (guarantees order of data -> UDP
can’t!)
Last block is recognised as its size < 512 bytes (what
happens if total file lenght is a multiple of 512 bytes?)
Problem: long files -> a lost msg means a complete retx.
ACK message format is the same as DATA -> but
opcode value = 04 & there are no data blocks
Network services
51
TFTP
 TFTP messages -> Error
Opcode
= 05


Error
code
Error
description
00
Error code: cause of the error.
Examples
•
•
•
•
…
•
0 -> Not defined. See error description
1 -> File not found
2 -> Access violation
3 -> Disk full
6 -> File already exists
Network services
52
FTP: the file transfer protocol
user
at host
file transfer
FTP
FTP
user
client
interface
local file
system
FTP
server
remote file
system
 transfer file to/from remote host
 client/server model

client: side that initiates transfer (either to/from
remote)
 server: remote host
 ftp: RFC 959
 Uses TCP: ports 20, 21 -> reliable transfer
Network services
53
FTP
 Two TCP connections


Data: transferred data (port 20)
Control: allows the user moving through the
directory structure and downloading & uploading
files (port 21)
FTP Client
Data
transfer
FTP Server
Control
dialogue
Control
dialogue
Data
transfer
TCP
protocol
Network services
54
FTP Client/Server model
 FTP Client initiates connection (server’s port 21)
 Connection parameters are negotiated in handshake



Data port
Connection mode: active/pasive
Transfer mode: ASCII/binary
FTP Client
Data
transfer
FTP Server
Control
dialogue
Control
dialogue
Data
transfer
TCP
protocol
Network services
55
Active connection mode
 Standard mode
 2 TCP connections
 Control: Client’s
random port (>1024)
to server’s port 21
 Data: when server
ACK -> from server’s
port 20 to client’s
port (indicated in
first control
command)
FTP Client
FTP Server
Control
port (e.g.
1033)
Data port
(e.g. 1034)
Control
port (21)
Data port
(20)
Command
PORT 1034
Command
ACK
DATA
Comando
ACK
 Data connection is
initiated from the
server
Network services
56
Pasive connection mode
 2 TCP connections
 Control: Client’s
random port (>1024)
to server’s port 21 ->
PASV command.
Server indicates a
random port for data
connection (>1024)
 Data: client
establishes
connection
FTP Client
FTP Server
Control
port (e.g.
1033)
Data port
(e.g. 1034)
Control
port (21)
Data port
(e.g. 1820)
Data port
(20)
PASV
command
Connection
establishment
PORT 1820
command
ACK
command
Network services
57
FTP Servers
 Configuration parameters
 Control port (default: port 21)
 Max # of connections to server & max # of connections per
IP
 Connection timeout
 Welcome & goodbye msgs
 Passive mode port numbers
 Users & groups
 Authenticated users: have login & passwd -> registered in
server
 Anonymous users
 Groups: share the same properties in FTP server
Network services
58
FTP Servers
 Permissions
 Read, write, execution (rwx)
 Permissions for the owner, for groups & for the rest of
users
 Bandwidth limit
 Server may limit transfer rate for the users
 Logs
 Register data or any other info about user connections &
errors
Network services
59
FTP Clients
 ftp <ip_addr>
 Commands
 cd
 get
 put
 mkdir
 exit
 …
 Do not mistake FTP
commands typed by client
for FTP control commands
Network services
60
FTP commands, responses
Sample commands:
Sample return codes
 sent as ASCII text over
 status code and phrase (as
control channel
 USER username
 PASS password
 LIST return list of file in


current directory
 RETR filename retrieves

 STOR filename stores

(gets) file
(puts) file onto remote
host
in HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
Network services
61
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
62
E-mail services
Main features:
 One of the most important services on the
Internet
 Allows users to exchange mails in an easy, fast
and cheap way
 Multiple receivers
 Client-server scheme
 Types of client apps



Graphic interfaces (Microsoft Outlook, Mozilla
Thunderbird, Apple Mail)
Text (pine, elm, mail)
Web (Gmail, Hotmail, SquirrelMail)
Network services
63
E-mail services
Related concepts:
 Mail account

Associated to user name & passwd
[email protected]
 Mailbox
 Mail alias
 Mail list
Network services
64
E-mail services
Standards:
 SMTP (Simple Mail Transfer Protocol)
 IMF (Internet Mail Format)
 MIME (Multipurpose Internet Mail Extensions)
 POP (Post Office Protocol)
 IMAP (Internet Message Access Protocol)
Network services
65
E-mail services
Components:
SMTP
 Mail User Agent (MUA)
 Mail Transfer Agent (MTA)
MTA
 Mail Delivery Agent (MDA)
POP
IMAP
SMTP
Mail User Agents (MUA)
MUA
MUA
MTA
MUA
 Mail client
 Compose, edit, read mail
messages
 Use two mail servers:


Outgoing mail server (SMTP)
Incoming mail server (POP or
IMAP)
MTA
SMTP
MUA
MUA
Network services
MUA
Outgoing
mail queue
User mailbox
66
E-mail services
Mail Agent Transfer
(MTA)
 Mail server
SMTP
MTA
 Stores sender’s mails for
Mail Delivery Agent (MDA)
POP
IMAP
SMTP
delivery (outgoing queue)
 Stores incoming mails for
their users
MTA
MUA
SMTP
MUA
MTA
MUA
MUA
 In charge of copying incoming
messages to user mailbox
MUA
MUA
Network services
Outgoing
mail queue
User mailbox
67
Scenario: Alice sends message to Bob
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent
to read message
1) Alice uses UA to compose
message and “to”
[email protected]
2) Alice’s UA sends message
to her mail server; message
placed in message queue
3) Client side of SMTP opens
TCP connection with Bob’s
mail server
1
user
agent
2
mail
server
3
mail
server
4
6
user
agent
5
Network services
68
Message format
 IMF (RFC 5322)
 Headers




To:
From:
Subject:
Date:
 Body

Headers
Blank
line
Body
Simple text messages (no
extended ASCII ) up to
998 characters(no CRLF)
Network services
69
Message format
MIME extensions:
 Add funcionality


Attached files
Extended ASCII
 New headers
 Mime-Version:
 Content-Type:
 Default -> text/plain
 Attachments ->
Multipart


 Types de encoding
 7 bits
 8 bits & binary
 quoted-printable &
base64.
Example quoted-printable
F3 = ó & F1 = ñ
Transmisión de ñ
Transmisi=F3n de =F1
Content-Description:
Content-TransferEncoding:
Network services
70
SMTP [RFC 5321]
Features:
 Simple functioning: client – server
 Used in communication between MUA –> MTA & MTA ->
MTA
 Uses TCP connection -> port 25
 Three phases
handshaking
 Message transfer (may be several ones)
 Connection closure
 Messages encoded in 7-bit ASCII



Binary -> ASCII (delivery)
ASCII -> Binary (reception)
Network services
71
SMTP [RFC 5321]
Features:
 command/response
response: free text & state code (3
figures):
 First figure shows command
success/fail
 4xx -> Temporary error
 5xx -> Permanent error
commands: ASCII text
 HELO: handshake after TCP
connection
 MAIL FROM: identifes
sender
 RCPT TO: identifies receiver
 DATA: message init
 End of line message -> ‘.’

QUIT: Closes SMTP session
Network services
72
Sample SMTP interaction
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
Network services
73
POP [RFC 1939]
Features:
 Very simple
 Allows the access to the incoming messages in mailbox
 Default -> Delete accessed msgs, but allows saving them
 Uses TCP connection -> port 110

Requires user authentication
 Three phases



authorization
transaction
Update
Network services
74
POP [RFC 1939]
authorization phase
 client commands:
user: declare username
 pass: password
 server responses
 +OK
 -ERR

transaction phase, client:
 list: list message numbers
 retr: retrieve message by
number
 dele: delete
 quit
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
Network services
75
on
IMAP [RFC 3501]
Features
 More complex than POP
 Allows the access to the incoming messages in mailbox
 Allows msg organization in folders in the server
 When receiving a new mail ->INBOX folder in user
mailbox
 Allows the access to single components of a msg
 Keeps information about the state between IMAP
sessions
Network services
76
Web access
Features:
 A browser is used instead of a mail client
 MUA is integrated in a web page
 Host uses HTTP to communicate with web server
 Web server habitually uses IMPA for the access to the
incoming msgs in the mail server
Network services
77
Problems
Main problems:
 Unencrypted msgs are transmitted

Use mechanisms of security (PGP, PEM, s/MIME)
 Bad uses

SPAM
Network services
78
SPAM
 Contact with many -> low cost
 Non-requested massive mail
 Types




Commercial
Nigerian (fraud)
Phishing
Others
 Origin



Personal Computer
Bad configured mail servers
Bad configured proxy servers
Network services
79
SPAM
 How are destination e-mail addresses obtained?
 guessing
 web page
 infected PC
 Mail headers falsification (FROM)
 How to stop them
 stop/make difficult to obtain mail addresses
 Identify them efficiently
 Measures
 Do not disclose our mail address
 When publishing our mail address -> protected data
 use alternative addresses
 Care about our PC security
Network services
80
Chapter 1: Network Services
 1.1 Introduction
 1.2 Domain Name
Server (DNS)
 1.3 Access remote
services


Telnet
SSH
 1.4 File transfer
services


TFTP
FTP
 1.5 e-mail services
 SMTP
 POP3
 1.6 Streaming services
Network services
81
MM Networking Applications
Fundamental
characteristics:
 typically delay sensitive
end-to-end delay
 delay jitter
 loss tolerant: infrequent
losses cause minor
glitches
 antithesis of data, which
are loss intolerant but
delay tolerant.

Classes of MM
applications:
1) stored streaming
2) live streaming
3) interactive, real-time
Network services
82
Streaming Stored Multimedia
Stored streaming:
 media stored at source
 transmitted to client

streaming: client playout begins
before all data has arrived
o
timing constraint for still-to-be transmitted data:
in time for playout
Network services
83
Streaming Live Multimedia
Examples:
 Internet radio talk show
 live sporting event
Streaming (as with streaming stored multimedia)
 playback buffer
 playback can lag tens of seconds after
transmission
 still have timing constraint
Interactivity
 fast forward impossible
 rewind, pause possible!
Network services
84
Real-Time Interactive
Multimedia
 applications: IP telephony, video
conference, new services not
supported by traditional networks
 end-end delay requirements:
 audio: < 150 msec good, < 400 msec OK
Network services
85
Streaming Stored Multimedia
 audio or video stored
in file
 files transferred as
HTTP object
 received in entirety
at client
 then passed to
player
 browser GETs metafile
 browser launches player, passing metafile
 player contacts server
 server streams audio/video to player
Network services
86
Streaming Multimedia: UDP or
TCP?
UDP
 server sends at rate appropriate for client (oblivious to
network congestion !)
 often send rate = encoding rate = constant rate
 then, fill rate = constant rate - packet loss
 short playout delay (2-5 seconds) to remove network jitter
 worse QoS due to packet loss
TCP
 send at maximum possible rate under TCP
 fill rate fluctuates due to TCP congestion control
 larger playout delay: congestion and flow control
 HTTP/TCP passes more easily through firewalls
Network services
87
User Control of Streaming
Media: RTSP
HTTP
What it doesn’t do:
 does not target
 doesn’t define how
multimedia content
 no commands for fast
forward, etc.
RTSP: RFC 2326
 Real-Time Streaming
Protocol: client-server
application layer protocol
 user control: rewind,
fast forward, pause,
resume, repositioning,
etc…
audio/video is
encapsulated for
streaming over network
 doesn’t restrict how
streamed media is
transported (UDP or TCP
possible)
 doesn’t specify how media
player buffers
audio/video
Network services
88
User Control of Streaming
Media: RTSP
RTSP messages sent
out-of-band:
RTSP control messages
use different port
numbers than media
stream: out-of-band.
 port 554
 Similar functioning
to FTP (control &
data)
 media stream is
considered “in-band”.

Network services
89
User Control of Streaming
Media: RTSP
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
Network services
90
Real-Time Protocol (RTP)
 RTP specifies packet structure for packets
carrying audio, video data
 RFC 3550
 RTP packet provides
 payload type identification
 packet sequence numbering
 time stamping
 interoperability: if two Internet phone
applications run RTP, then they may be able to
work together
Network services
91
Real-Time Protocol (RTP)
 RTP libraries provide transport-layer
interface that extends UDP:
 port numbers, IP addresses
 payload type identification
 packet sequence numbering
 time-stamping
Network services
92
RTP header
Payload Type (7 bits): Indicates type of encoding currently being
used. If sender changes encoding in middle of conference, sender
informs receiver via payload type field.
Payload type 0: PCM mu-law, 64 kbps
Payload type 3, GSM, 13 kbps
Payload type 26, Motion JPEG
Payload type 33, MPEG2 video
Sequence Number (16 bits): Increments by one for each RTP packet
sent, and may be used to detect packet loss and to restore packet
sequence.
Network services
93
RTP header
Timestamp field (32 bytes long): sampling instant of first byte in this
RTP data packet for audio, timestamp clock typically increments by
one for each sampling period
SSRC field (32 bits long): identifies source of RTP stream. Each
stream in RTP session should have distinct SSRC.
Network services
94
Real-Time Control Protocol
(RTCP)
 works in conjunction with
 feedback can be used to
control performance
RTP.
 sender may modify its
 each participant in RTP
transmissions based on
session periodically transmits
feedback
RTCP control packets to all
 RTP, RTCP packets
other participants.
distinguished from each
 each RTCP packet contains
other via distinct port
sender and/or receiver
numbers.
reports
 to limit traffic, each
 report statistics useful to
participant reduces RTCP
application: # packets sent,
traffic as number of
# packets lost, interarrival
conference participants
jitter, etc.
increases
Network services
95
Real-Time Control Protocol
(RTCP)
Receiver report packets:
 fraction of packets
lost, last sequence
number, average
interarrival jitter
Sender report packets:
 SSRC of RTP stream,
current time, number of
packets sent, number of
bytes sent
Network services
96