Internet Working 15th lecture (last but one) Chair of Communication Systems Department of Applied Sciences University of Freiburg 2005

Transcription

1 15th lecture (last but one) Chair of Communication Systems Department of Applied Sciences University of Freiburg

2 administrational stuff Next Thursday preliminary discussion of network seminars of the professorship (three different seminars, see homepage for description inaugural lecture at the faculty Next Friday written examination holidays : )) Grades in oral or written exams will be sent to the examinations office (an will be available there beginning of winter term) If you need a special printed paper please tell us, so we could prepare it it will be available at the secretaries of the computing department 2 43

3 Last lectures network security Firewalls for protecting machines from outside or outgoing traffic do not secure traffic in transit but try to block certain kinds of traffic operate on different layers of the OSI protocol stack MAC, IP, TCP/UDP header filtering Connection tracking (SYN ACK of TCP handshake, sessions,...) Special masquerading firewalls But security might be levelled with overcomplex firewalls Traffic can be tunneled over higher level protocols (piggybacking IP packets in DNS) IP over WAP2.0 tunnel (student project at our chair of CS) 3 43

4 Last lecture network security real time protocols Firewalls are only part of a network security concept often combined with VPN to span private networks of firms/organizations over insecure internet Firewalls do not protect by itself, but could be extended for spam, virus filters... (operating often as proxies on application level) Second part of last lecture introduced to real time services for video broadcasting, voice over IP, internet telephony We will introduce SIP session initialization protocol Telephony over IP networks Only session setup, but compression, packet transport left to other services like RTP and RTCP 4 43

5 application layer protocols internet telephony For a rather long time telephone and data networks were different entities remember the network taxonomy packet orientated vs. circuit switched packet orientation is rather efficient in bandwidth using but cannot give any guarantees on packet delivery bandwidth growth and optional QoS helped to offer service quality near to circuit switching Why to provide two completely different infrastructures for rather the same services? voice is just another piece of data (and not the biggest one compared to other applications and services in use) 5 43

6 application layer protocols internet telephony Voice over IP is a big hype at the moment every network equipment vendor has some products in its portfolio (even companies like Siemens are able to offer products conforming to standards!!) many new telephone companies evolve to offer services, the old providers have to think on new strategies all of them hope for reduce of costs and a source for roaring profits : ) so TCP/IP is just used for another application/service this service has to meet some requirements 6 43

7 internet telephony requirements security reduced costs might induce new type of SPAM spit (spam over internet telephony) how to know that the caller is the one he claims to, same for the called partner compatibility to existing services routing of emergency calls location of emergency presence rebustness of servers and routes permanent updates of clients (mobile devices move from network to network) 7 43

8 internet telephony requirements Voice over IP should offer higher robustness (e.g. alternate routes) better voice quality mobility, multimedia and conferencing secure communication gateways to other telephone systems (GSM, UMTS, PSTN) 100% open standards hope of a combination of lower costs with better functionality 8 43

9 internet telephony infrastructure (idialized : )) 9 43

10 internet telephony standards Requirements by VoIP services enough bandwidth for digitized audio stream (both directions!) minimal jitter and noise > later this lecture Two main VoIP standards H323 standard developed by Telcos ITU (last lecture) SIP internet standard SIP is session initialization protocol developed by Henning Schulzrinne (Feb. 1999) IETF Standard RFC 2543 (March 1999) current: RFC 3261 (June 2002) 10 43

11 internet telephony SIP SIP just for session setup not for transport of multimedia streams inspired by HTTP text based Peer to Peer application layer protocol using requests and replies to set up a connection 11 43

12 internet telephony SIP Requirements toward SIP localization of endpoints setup of connections exchange of media and presence information modification of sessions: rerouting and cancelling of calls complete a session scalability (more than one session should be possible) SIP addresses designed same way as addresses sip: userid@sipgateway.site 12 43

13 SIP entities Peers = User Agents (UA) a UA can fulfill on of the following roles user agent client (UAC) = initiator of a request user agent server (UAS) answers requests for him = application, which contacts the user and SIP clients telephones: as UAC or UAS Gateways: connections to other networks, translates between different audio and video codecs SIP server might act as proxy server and could be used for authentification, authorization secure routing and rerouting 13 43

14 SIP server SIP server redirect server = information service location server is the request address for the host on wich a given user might be reached on registrar server acts as registration service registers the current location of the clients often at the same place as proxy or redirect is not a required component for SIP, but useful in larger setups 14 43

15 SIP message types SIP defines messages for communication setup end ending 15 43

16 SIP direct example session direct SIP connection disadvantage: the calling party has to know the IP address of called party INVITE message contains the details, which type of session is to be initiated 16 43

17 SIP direct example session 17 43

18 SIP header fields Request URI, SIP version number VIA: SIP version number, protocol, every SIP entity adds host and port, which created or routed the message Max Forwards is decremented at every hop To, From: tags as identifier Call ID: sender creates local non ambiguous identifier which is globally unique in combination with the full qualified domain name CSeq: command sequence is incremented with every new request More optional fields Contact contains the SIP address of the current host, if connected over proxy messages could be sent directly Content Type and Length tell the style of the following SDP body 18 43

19 SIP trying message (message before ringing) 19 43

20 SIP ringing message 20 43

21 SIP ringing (cont.) To and From fields are the same as in INVITE direction of the initiating request is important connection over a proxy only answers to requests, does not send requests by itself no media abilities (does not handle media sessions) reads header and does not analyse body+ proxy may send request for clients location to location server 21 43

22 SIP OK (200) message 22 43

23 SIP redirect, registering & instant messaging redirection client sends INVITE to the SIP redirect server redirect server sends a request to the location server or requests the IP of the client to call current data is sent to the client, which ACK's from now on further on like direct connection registration REGISTER message to SIP registration server binding of the SIP URI with IP the users client/machine 200 OK instant messaging like the wellknown tools in that sector online status, buddy lists

24 SDP service dscription protocol session description protocol (SDP) IETF standard RFC 2327 text coded like SIP description syntax 24 43

25 SDP service dscription protocol example: v=0 o=calling IN IP s=phone Call c=in IP t=0 m=audio RTP/AVP a=rtpmap:0 PCMU/8000 Version is 0 (at the moment no other versions available) Origin o=username session id version network type adress type adress Subject s=subject 25 43

26 SDP service description protocol (cont.) Connection Data c=network type address type connection adress Time t=start time stop time Media Announcements m=media port transport format list Attributes a= This setup defines the multimedia session which usually uses RTP / RTCP explained later this lecture 26 43

27 SIP firewalls, NAT,... NAT SIP messages contain IP addresses in the data segments of its packets internal network addresses from the NATted network are not visible from the outside world A calls B, B gets the message from A, but not vice versa problem could be solved with a proxy server sitting in the internal and external LAN Firewalls RTP does not use fixed layer 4 port numbers variable in the range of

28 SIP firewalls, NAT,... (cont.) stun protocol simple traversal of UDP through NATs returning public's IP port can help to determine which kind of NAT is used most clients implement that protocol to produce the relevant SDP messages stun server will send its response to the IP:port the initial packet was sent to if change ip flag, then sends from different IP if change port flag from different port 28 43

29 real time services introduced SIP does not handle multimedia streams but only session setup setup is rather uncritical, the multimedia stream (the phone call taking place) is not requirements toward networks for real time audio and video at least short delay (delay is composed from several parameters) and enough bandwidth normally available in backbone networks But more problematic the the (private) end user over low bandwidth connections 29 43

30 real time services During maturing of the internet bandwidth was often scarce and expensive many solutions to bandwidth management addressed the whole end to end system connection but most concepts (e.g. the ToS flag in IP header) are not really used By now: It is often cheaper to add bandwidth than operating sophisticated bandwidth management But there are scenarios where quality of service (QoS) may improve the whole networks usability

31 requirements towards network Voice over IP and Quality of Service: Major challenges: delay and delay variation (jitter) Delay jitter is the variability of source to destination delays of packets within the same packet stream Voice applications are usually interactive delay requirement for a telephone system: 150ms 250ms We identified the sources of delay in a voice over IP system: OS delay: 10s 100s milliseconds (digitisazion of data, compression and inter software data handling)

32 requirements towards network Source jitter: Network: network conditions vary at different times. Non real time OS: samples processed at different time Jitter control buffering at the destination task of the application used QoS parameters which should be taken into account: Accuracy, latency Jitter and codec quality Talked on SIP after session establishment RTCP and RTP data streams Depending on codec used a data stream of e.g. ~80kbit/s is generated for each direction (64kbit/s of ISDN PCM plus IP and UDP header) 32 43

33 Real Time Protocol (RTP) Introduction of a special multimedia protocol Video and audio streaming Defined in RFC 1889 Used for transporting common formats such as PCM and GSM for sound, and MPEG1 and MPEG2 for video RTP can be viewed as a sublayer of the transport layer Usually on top of UDP 8byte header (faster transfer) No setup overhead like with TCP session no explicit connection handling (left to protocols like SIP) faster 33 43

34 SIP benefits over other protocols/solutions like H323 RTP packet header Payload type (7 bits): the type of audio/video encoding Sequence number (16 bits) Time stamp (32 bits): use for jitter removal derived from a sampling clock at the sender Synchronization Source Identifier (SSRC) (32 bits): identify the source of the RTP stream It is not the IP address of the sender (would violate the layering) but a number that the source assigns randomly when the new stream is started 34 43

35 real time protocol 35 43

36 RTP At the sender, the application puts its audio/video data with an RTP header and sends into the UDP socket The application in the receiver extracts the audio/video data from the RTP packet Uses the header fields of the RTP packet to properly decode and playback the audio/video data Helper protocol: RTCP (RTP Control Protocol) RTCP packets do not encapsulate audio/video data 36 43

37 RTCP RTCP packets sent periodically between sender and receivers to gather useful statistics number of packets sent number of packets lost interarrival jitter RTP and RTCP packets are distinguished from each other through the use of distinct port numbers 37 43

38 real time control protocol 38 43

39 RSVP RTP needs a bandwidth at least of the rate as packets are sent in each direction Otherwise packet loss or delays will occur and decrease the quality of data stream A special protocol was developed to add service quality parameters to the packet orientated internet RSVP part of a larger effort to enhance the current Internet architecture with support for Quality of Service flows RFC 2205 RSVP requests will generally result in resources being reserved in each node along the data path Resource we speak of is bandwidth (delay is much more complicated to reserve within IP networks) 39 43

40 RSVP Signaling protocol introduced to reserve bandwidth between a source and its corresponding destination Main features of RSVP are Use of soft state'' in the routers receiver controlled reservation requests flexible control over sharing of reservations forwarding of subflows the use of IP multicast for data distribution Source Destination: RSVP path message Destination Source: RSVP reserve message Nice try but

41 RSVP problems Routers cannot not store state information about packets often too slow Simpler technique: mark each packet with a simple flag indicating how to treat it Individual flows are classified into different traffic classes Each router sorts packets into queues via differentiated services (DS) flag Queues get different treatment (e.g. priority, share of bandwidth, probability of discard) 41 43

42 RSVP problems Result is coarsely predictable class of service for each differenciated services field value Cost of transmission varies by type of service Each traffic class is reserved a defined level of resources, e.g. buffer and bandwidth Different QoS guarantee policies can be applied in different traffic classes When congestion occurs, packets in low priority traffic classes will be dropped first The buffer and the bandwidth in a router for high priority traffic classes are more than low priority traffic classes More scalable than RSVP but cannot allocate resources precisely 42 43

43 literature SIP Kurose & Ross: Computer Networking, 3rd edition (international): Section SIP Tanenbaum: Computer Networks, 4th edition: Section Voice over IP 43 43