NETS 3303 Networked Systems

1. NETS 3303 Networked Systems Application Layer

2. 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

3. Outline • Different types of applications • The old bunch • Telnet • FTP • SMTP • The new bunch • Multimedia apps

4. 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

5. Application types • Imagine Email: • Low bandwidth • No delay requirement • No errors • Imagine VOIP (telephony) • Delay critical • High Bandwidth • Some errors OK

6. Application Types

7. 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

8. 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!!!!!!!!!!!

9. 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)

10. 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: username@dns.site

11. 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

12. 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”

13. 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) • digit 3: particular meaning

14. 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

15. 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

16. 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

17. 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

18. WWW • WWW is NOT Internet!!!!!!!!!!!!! • WWW is one overlaid network architecture of many. Other examples are: • P2P apps • GRIDS • MBONE

19. 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

20. 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

21. 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

22. 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?

23. 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?

24. RTSP streaming • Solution RTSP • Use UDP for data flows, TCP for control • Separate streaming server • Meta file points to streaming server

25. 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

26. RTSP messages • DESCRIBE • Causes a server to return a description of the protocol using the Session Description Protocol. • ANNOUNCE • Allows a client or server to register a description of a presentation. • OPTIONS • Causes a server to return the list of supported methods. • SETUP • 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 • Starts a server recording an allocated stream. This manipulates state. • PAUSE • Temporarily halts transmission of a stream without freeing server resources. This manipulates state. • TEARDOWN • Frees resources associate with a stream, so that the RTSP session ceases to exist. This manipulates state. • GET_PARAMETER and SET_PARAMETER • 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.

27. 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

28. 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

29. If you have a network path consisting of two ISDN links and a OC3 link. How does this affect RTP?

30. In this case, RTP is completely unnecessary.

31. RTP Features • Streamlined • Network protocol independent • Can be extended in the future • Works with multicast • DATA / Control separated • Often implemented with UDP (programming API)

32. Source Capture Play-out Encoding Decoding UDP Source Capture Play-out Encoding Decoding UDP RTP RTP Encapsulation Decapsulation RTP RTP Encapsulation Decapsulation RTP Application Programming Application Specific OS API IP

33. 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

34. 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

35. Why is a flow identifier needed?

36. I multiple flows come from the same process (audio and video), the receiver has to separate them (same IP and port)

37. RTP 1 2 3 4 5 8 910 16 17 32 V CC P X M Sequence Number Payload Type 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 X – extension flag

38. 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

39. RTCP • Reports generated: • Frequency inv. Proportional to no members • Excellent scalability (BW limited) • Initial “storm”

40. Report calculations • Estimate total bandwidth of session • Sender period T: • Receiver period T: • Next packet = last packet + Max(5s, T) + random (0.5-1.5) • Random prevents “bunching”

41. 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

42. SIP Basics • Agnostic about • Application • Media • Description • A wrapper protocol for these functions • Used to initiate, control and terminate sessions

43. SIP Basics • Based on HTML, email, URL • Integrating communication Calling card Email: bob@abc.net Phone: +61 2 9531 99865 Fax: +61 2 9531 99844 Web: www.abc.net/~bob SIP, single identifier bob@abc.net

44. SIP Entities • SIP server • SIP Redirect Server • SIP proxy server • SIP Registrar • SIP User Agents

45. 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

46. SIP User Mobility • Registrar accepts user location registrations (SIP) • Registrar updates Location Server (other protocol) • Peers query Location server (other protocol)

47. SIP User Mobility ABC.net Location server Alice’s SIP server/registrar Abc.net 1.1 Alice is reachable at: SIP:alice@192.168.0.1 1.2 Alice: SIP:alice@192.168.0.1 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.4 Invite SIP:alice@192.168.0.1 2

48. SIP* Server • The server can operate in two modes: • Proxy (this slide) • Redirect (previous slide) 1.2 Invite SIP:alice@192.168.0.1 1.1 Invite SIP:alice@abc,net

49. 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

50. SIP UA • UA is an Application • Can have User Interface • SIP request processing • SIP Servers route SIP messages – SIP UA processes SIP messages