Transcript Week11

NETS 3303
Networked Systems
Application Layer
Björn Landfeldt
School of Information Technologies
Outcomes
• Knowledge about some common applications
• Understanding of application behaviour and
requirements from the network
• Knowledge about application layer protocols
• Understanding how the Internet concepts integrate
different services
Björn Landfeldt
School of Information Technologies
Outline
• Different types of applications
• The old bunch
– Telnet
– FTP
– SMTP
• The new bunch
– Multimedia apps
Björn Landfeldt
School of Information Technologies
Application types
• Imagine Telnet (one character at a time)
• Properties:
– Low bandwidth
– Low delay requirement
– No errors
• Imagine FTP (bulk data transfer)
– Delay unimportant
– High Bandwidth
– No errors
Björn Landfeldt
School of Information Technologies
Application types
• Imagine Email:
– Low bandwidth
– No delay requirement
– No errors
• Imagine VOIP (telephony)
– Delay critical
– High Bandwidth
– Some errors OK
Björn Landfeldt
School of Information Technologies
Application Types
App
Elasti Nonc
elastic
Telnet
X
Delay
sensitive
BW
critical
X
FTP
X
X
Email
X
Hmm
Streaming
X
VOIP
Björn Landfeldt
School of Information Technologies
X
Errors
Moderate
X
X
X
X
X
Application types
• Which applications should use TCP? UDP?
• Point-to-multipoint (multicast)
– Has to use UDP
• Streaming and real time
– Low jitter and no retransmissions, use UDP
• No errors, no delay constraints
– Use TCP
• No errors, delay constraints
– Use UDP and FEC
Björn Landfeldt
School of Information Technologies
Telnet
•
•
•
•
•
Opens a network virtual terminal on server
Maps a “real” terminal onto NVT (xterm)
Sends ASCII characters between client and server
Byte by byte (line mode possible)
Can be used to debug app protocols
– Connect to IP:port, send commands
• Use SSH instead!!!!!!!!!!!
Björn Landfeldt
School of Information Technologies
FTP
• Classic IETF file transfer protocol
• Used for transferring single files not
browsing (limited usefulness)
• Can transfer multiple files (mput, mget)
• Can’t transfer tree structures (unless tar is
used)
Björn Landfeldt
School of Information Technologies
Anonymous FTP
• anonymous ftp servers offers up files on server
with no need to for password for user
convenience, server security isn’t impaired
• unix anon-ftp server runs via chroot(2) call to
/usr/ftp (or wherever), appears to client (and
server) as root of file system
anon login:
– user: ftp (or anonymous)
– password: [email protected]
Björn Landfeldt
School of Information Technologies
FTP protocol
• ftp uses ASCII commands for ftp protocol on TCP
port 21
• protocol commands are simple verb object <cr>
<nl> RETR filename <cr> <nl> (get a file)
• ASCII success/error status comes back from
server; e.g., 226 transfer complete
• separate socket channel used for data xfer
• after client RETR, server connects from port 20
to client port sent via client PORT command OR
• PASV command can be used to tell server to wait
for client connection
Björn Landfeldt
School of Information Technologies
Protocol vs. Client
• understand that an ftp client uses the ftp protocol
to talk to a server
• the client “get file” command is translated
somehow into the ftp protocol command; e.g.
• BSD ftp client has command: get file
• ftp protocol uses RETR file to implement “get”
Björn Landfeldt
School of Information Technologies
Result codes
• every command must have at least 1 reply
• reply can be multi-line (e.g., SYST, STAT, etc. are
most common)
• format: 3 digit number<sp>text
• multiline: replace <sp> with -, last line has space
• theory: 3 digit number for “machine”, text for
people
– digit 1: good, bad, incomplete
– digit 2: function groupings
(syntax/info/connection/authentication/file system)
Björn Landfeldt
– digit 3: particular meaning
School of Information Technologies
Result Codes First Digit
•
•
•
•
1yz - positive preliminary reply
2yz - positive completion reply
3yz - positive intermediate reply
4yz - transient negative completion reply
(try again later)
• 5yz - permanent negative completion reply
Björn Landfeldt
School of Information Technologies
Example replies
•
•
•
•
200 okay
226 Transfer complete
550 foobar: No such file or directory
150 Opening ASCII mode data connection
for /bin/ls
• 331 Guest login ok, send “guest” as
password
Björn Landfeldt
School of Information Technologies
EMAIL
•
•
•
•
very simple protocol, 7-bit ASCII chars
uses TCP, port 25
typically uses DNS MX records
MIME Multipurpose Internet Mail
Extensions,allow “multimedia” mail
Björn Landfeldt
School of Information Technologies
SMTP, Request/response
protocol
• HELO client.dns.name - say hello to other side
– 250 server-dns “Howdy”
• MAIL From: user@dns-site - id originator
• RCTP To: user@dns-site - id recipient
• DATA
– text
– . - DOT in column 1 for EOF
• QUIT - end of transmission
Björn Landfeldt
School of Information Technologies
WWW
• WWW is NOT Internet!!!!!!!!!!!!!
• WWW is one overlaid network architecture
of many. Other examples are:
– P2P apps
– GRIDS
– MBONE
Björn Landfeldt
School of Information Technologies
HTTP
• Browsers use two basic components
– HTML (SGML, XML etc.)
– HTTP
• HTML describes content of a web page
• HTTP shuffles the components across the
network
Björn Landfeldt
School of Information Technologies
HTML
• We refrain from digging deep here, you
know it.
• Hyperlinks very nifty idea. Disruptive
addressing between resource providers.
• Uses URL, example:
– http://www.usyd.edu.au
Björn Landfeldt
School of Information Technologies
HTTP
• Simple ASCII based protocol
• commands called “methods”, but for the most
part, just a variation on “get file”
• server status and errors similar to error strings
found in ftp/email
–
–
–
–
200 - successful
300 - not done yet; e.g., 301 is moved permanently
400 - client error; e.g., 403 forbidden (server refuses)
500 - server error; 503 service unavailable at the
moment
Björn Landfeldt
School of Information Technologies
HTTP Streaming
• Method One:
– User clicks on hyper link
– Web browser reads mime type and starts player
app.
– Browser downloads object
– Browser passes object to player
– Player plays object
• Long delay, real time?
Björn Landfeldt
School of Information Technologies
HTTP Streaming
• Method two:
–
–
–
–
–
User clicks hyper link
Web browser reads meta-file
Meta file passed to player application
Player application reads object using HTTP
Buffering, then play
• Shorter delay, real time OK
• BUT, TCP not suitable WHY?
Björn Landfeldt
School of Information Technologies
RTSP streaming
•
•
•
•
Solution RTSP
Use UDP for data flows, TCP for control
Separate streaming server
Meta file points to streaming server
Björn Landfeldt
School of Information Technologies
RTSP
•
•
•
•
Acts as “remote control” for MM servers
Builds on HTTP (ease of implementation)
URIs prepended with RTSP://
Simple control protocol, to be used with
other transport protocol, e.g. RTP
Björn Landfeldt
School of Information Technologies
RTSP messages
•
DESCRIBE
•
ANNOUNCE
–
–
Causes a server to return a description of the protocol using the Session Description Protocol.
Allows a client or server to register a description of a presentation.
•
OPTIONS
•
SETUP
–
–
•
Causes a server to return the list of supported methods.
Causes a server to allocate resources for a stream and starts an RTSP session. This manipulates state.
PLAY
–
Starts data transmission on a stream allocated by SETUP. This manipulates state.
•
RECORD
•
PAUSE
–
–
Starts a server recording an allocated stream. This manipulates state.
Temporarily halts transmission of a stream without freeing server resources. This manipulates state.
•
TEARDOWN
•
GET_PARAMETER and SET_PARAMETER
–
–
•
Frees resources associate with a stream, so that the RTSP session ceases to exist. This manipulates state.
Placeholder methods to allow parameters of presentations and sessions to be manipulated.
REDIRECT
–
Causes a client to go to another server for parts of a presentation.
Björn Landfeldt
School of Information Technologies
RTSP use scenario
• Client sends DESCRIBE
– Server returns description
– Client selects applications
• Client sends SETUP
– Server returns session identifier
– Server allocates states (resources, ports etc.)
• Client sends PLAY
– Includes URI, start and stop time etc.
• Client might PAUSE during play out session
• Client sends TEARDOWN
– Server de-allocates resources
Björn Landfeldt
School of Information Technologies
RTP
• HAMMER! TCP unsuitable for RT media
• UDP has two major drawbacks:
– Lack support for lost or reordered packets
– Lack support for jitter compensation
• RTP provides these functions
Björn Landfeldt
School of Information Technologies
If you have a network path
consisting of two ISDN links
and a OC3 link. How does this
affect RTP?
Björn Landfeldt
School of Information Technologies
In this case, RTP is completely
unnecessary.
Björn Landfeldt
School of Information Technologies
RTP Features
•
•
•
•
•
•
Streamlined
Network protocol independent
Can be extended in the future
Works with multicast
DATA / Control separated
Often implemented with UDP
(programming API)
Björn Landfeldt
School of Information Technologies
RTP Application Programming
Source Capture
Source Capture
Play-out
Encoding
Decoding
RTP
Encapsulation
Application
Specific
Björn Landfeldt
School of Information Technologies
Encoding
Decoding
RTP
Encapsulation
RTP
Decapsulation
UDP
Play-out
OS API
IP
RTP
Decapsulation
UDP
RTP
• Sending a packet, RTP adds:
– A timestamp per Application Data Unit (not per
packet)
– A Synchronisation Source Identifier (SSRC)
• Randomly generated
• Conflicts resolved
• Uniquely identifies flows to receivers
Björn Landfeldt
School of Information Technologies
RTP
• Two network functions with RTP:
– Mixer, mix different sources to one stream
• New Synchronisation Source Identifier
• Add old SSRC as Contributing Source Identifiers
– Translator, manipulates the content, e.g. a
transcoder
Björn Landfeldt
School of Information Technologies
Why is a flow identifier
needed?
Björn Landfeldt
School of Information Technologies
I multiple flows come from the
same process (audio and video),
the receiver has to separate
them (same IP and port)
Björn Landfeldt
School of Information Technologies
RTP
8 910
16 17
12345
V P X CC M Payload Type
32
Sequence Number
Time-Stamp
Synchronisation source (SSRC) Identifier
Contributing source (CSRC) Identifier (1)
:
Contributing source (CSRC) Identifier (N)
DATA (1-N audio and/or video frames)
V – version
CC – CSRC count (N < 16)
P – pad
M – marker bit
Björn Landfeldt
X
– extension flag
School of Information Technologies
RTCP
• Out of band control signalling (usually RTP
port +1)
• Used to:
– Integrate different streams
– Inform about QoS (delay, jitter, packet loss)
– Distribute information about participants
• Who is participating in session
• Who is speaking now
Björn Landfeldt
School of Information Technologies
RTCP
• Reports generated:
– Frequency inv. Proportional to no members
• Excellent scalability (BW limited)
• Initial “storm”
Björn Landfeldt
School of Information Technologies
Report calculations
• Estimate total bandwidth of session
• Sender period T:
• Receiver period T:
T
#Participa nts
 avg._RTCP_packet_size
0.25  0.05  SessionBW
T
#Participa nts
 avg._RTCP_packet_size
0.75  0.05  SessionBW
• Next packet = last packet + Max(5s, T) + random (0.51.5)
• Random prevents “bunching”
Björn Landfeldt
School of Information Technologies
SIP
• Bob wants to call Alice
– In circuit switched networks easy, send voltage
pulse to telephone, it rings.
– In the Internet?
• A protocol called SIP
• SIP is used to invite to
– New sessions
– Existing sessions
Björn Landfeldt
School of Information Technologies
SIP Basics
• Agnostic about
– Application
– Media
– Description
• A wrapper protocol for these functions
• Used to initiate, control and terminate
sessions
Björn Landfeldt
School of Information Technologies
SIP Basics
• Based on HTML, email, URL
– Integrating communication
Calling card
Email: [email protected]
Phone: +61 2 9531 99865
Fax: +61 2 9531 99844
Web: www.abc.net/~bob
Björn Landfeldt
School of Information Technologies
SIP, single
identifier
[email protected]
SIP Entities
• SIP server
– SIP Redirect Server
– SIP proxy server
• SIP Registrar
• SIP User Agents
Björn Landfeldt
School of Information Technologies
SIP User mobility
•
•
•
•
•
User move around
Users have different devices
Devices get dynamic IP addresses
Where to locate a user?
SIP uses URL (mail addresses) to identify
domain
Björn Landfeldt
School of Information Technologies
SIP User Mobility
• Registrar accepts user location registrations
(SIP)
• Registrar updates Location Server (other
protocol)
• Peers query Location server (other protocol)
Björn Landfeldt
School of Information Technologies
SIP User Mobility
1.1 Alice is reachable at:
SIP:[email protected]
ABC.net
Location server
Alice’s SIP server/registrar
Abc.net
1.2 Alice: SIP:[email protected]
1
2.2 Where is SIP:alice@abc,net
192.168.0.1
2.3 SIP:alice@abc,net
is at: 192.168.0.1
2.1 Invite SIP:alice@abc,net
2
Björn Landfeldt
School of Information Technologies
SIP* Server
• The server can operate
in two modes:
1.2 Invite SIP:[email protected]
– Proxy (this slide)
– Redirect (previous
slide)
1.1 Invite SIP:alice@abc,net
Björn Landfeldt
School of Information Technologies
Proxy location
• A SIP proxy can be located using a
discovery protocol, e.g.
– Dynamic Host Configuration Protocol, DHCP
– Service Location Protocol, SLP
• Or statically entered in the application
Björn Landfeldt
School of Information Technologies
SIP UA
• UA is an Application
• Can have User Interface
• SIP request processing
• SIP Servers route SIP messages – SIP UA
processes SIP messages
Björn Landfeldt
School of Information Technologies
SIP Operation
• Request – response (client – server)
– User agent client, UAC
– User agent server, UAS
• Responses:
Range
100-199
200-299
300-399
400-499
500-599
600-699
Response class
Informational
Success
Redirection
Client error
Server error
Global failure
• Contain status code and phrase
Björn Landfeldt
School of Information Technologies
Example Responses
•
•
•
•
•
•
•
•
100 Trying
180 Ringing
200 OK
202 Accepted
305 Use proxy
400 Bad request
403 Forbidden
404 Not found
Björn Landfeldt
School of Information Technologies
•
•
•
•
•
408 Request timeout
415 Unsupported media type
500 Internal server error
503 Service unavailable
505 SIP version not
supported
• 603 Decline
Requests
• INVITE
– Carries session description (SDP)
– Typical scenario:
BOB
Björn Landfeldt
School of Information Technologies
ALICE
Requests (Methods)
• ACK
– Issued by client upon receiving final response
– Three way handshake (tell server client still
there after long delay)
• CANCEL
– Cancels pending invite requests
– Server returns 200 OK
Björn Landfeldt
School of Information Technologies
Requests (Methods)
• BYE
– Two party sessions, terminate session
– Multi-party sessions, notify leaving – session continues
– Reply 200 OK
• REGISTER
– Tell registrar of user location
– Reply 200 OK
• OPTIONS
– List what methods a server supports + misc. info.
– Reply 200 OK
Björn Landfeldt
School of Information Technologies
SIP format
• Text based protocol
– Flexible – inefficient?
Request format
Request line
Several headers
Empty line
Message body
Björn Landfeldt
School of Information Technologies
Response format
Status line
Several headers
Empty line
Message body
• Request line
SIP format
– Method, next hop URI, protocol version
Alice’s UA
Bob’s Proxy (abc.net)
usyd.edu.au
telstra.com.au
INVITE SIP:[email protected] SIP/2.0
INVITE SIP:bob@
usyd.edu.au SIP/2.0
INVITE SIP:bob@
telstra.com.au SIP/2.0
Status line: version, status code, reason string (SIP/2.0 200 OK)
Björn Landfeldt
School of Information Technologies
SIP declares that final responses
have to be transmitted using a
reliable transport protocol, but
provisional responses not, why?
Björn Landfeldt
School of Information Technologies
Reliable transmission
• Simply because the information whether or
not a session has been established is vital.
Session progress is optional information.
Björn Landfeldt
School of Information Technologies
SIP Headers
• Example headers:
– From: Bjorn Landfeldt [email protected]
– Call-ID: [email protected] (distinguish
between two sessions with same participants)
– Contact: Bjorn Landfeldt [email protected] (direct
route)
– Record-Route: <SIP:[email protected];
maddr=192.168.0.125> (tell that proxy has to be in
signalling path)
Björn Landfeldt
School of Information Technologies
SIP Bodies
• Separated from headers by blank line
• Proxies ignore bodies
– Can be encrypted end-to-end
• Typically contains session descriptions
• A SIP message can contain several bodies
– E.g. SDP description and callers photo
Björn Landfeldt
School of Information Technologies
SIP Example
Alice
SIP proxy
(1) INVITE
Bob
(2) INVITE
(3) 180 RINGING
(4) 180 RINGING
(5) 200 OK
(6) 200 OK
(7) ACK
SESSION
(8) BYE
Björn Landfeldt
School of Information Technologies
(9) 200 OK