Integrated Services - Overview

Transcription

1 Multicast QoS Need bandwidth/delay guarantees On many links unknown to sender Fortunately QoS development after multicast Takes multicast into account RSVP reservations from receivers toward sender rules for merging QoS requests One QoS requirement emerges at sender Integrated Services - Overview A B Network Elements (nodes, routers) QoS Enabled QoS Aware non-qos Application Characteristics Real Time Applications Assume play out buffer to handle (some) jitter Tolerant can handle buffer emptying occasionally Intolerant cannot... Intolerant need absolute upper bound on delay Tolerant can handle desired delay occasionally being exceeded

2 Application Characteristics (2) Elastic Applications Can hand any delay any reasonable delay Prefer short delay As soon as possible IS: Service Classes Controlled Load deliver most packets as if network is not congested very little loss delay for most packets close to minimum possible Meets needs of both tolerant real time applications elastic applications IS: Service Classes (2) Guaranteed Service no delay outside bounds no packets discarded provided application stays within agreed traffic profile Meets needs of intolerant real time applications

3 Service Parameters Token bucket rate & size (r and b) bytes/second rate that tokens are added bytes that bucket can hold before overflow specify sustained rate, and maximum burst Peak data rate (p) maximum data rate of a burst Maximum packet size (M) used in queue & delay calculations Minimum policed unit (packet size) (m) Guaranteed Service Parameters All the above Rate R Slack S R bytes/second R >= r S microseconds R represents ideal delay bound S represents allowable deviation from R Implementing GS Two additional parameters (per Network Element) D Intrinsic Delay Processing,... C Rate Dependent Delay Transmission time,... NE s accumulate delays Dtot accumulated D Ctot accumulated C S = Dreq - (b/r + Ctot/R + Dtot) Where Dreq was original delay bound

4 Routing Nothing Special IS uses normal shortest path route If that can handle the new flow good If not refused no attempt to use some other idle path Avoids having to Design a whole new routing method And get it deployed Path Setup Not specified by Integrated Services Manual path setup OK network operators SNMP path setup OK Simple Network Management Protocol signalling protocol for path setup OK This is the expected method RSVP Répondez s il vous plaît (excuse my French...) "Please Answer" Resource Reservation Protocol Observation: It isn t sender who cares about QoS It is recipient

5 RSVP (2) Can be used for other than QoS will ignore that here assume QoS application of RSVP Sender initiates RSVP path setup source of flow Sends to recipient(s) special IP packet PATH message Contains flow characteristics SENDER_TSPEC Contains space for routers to calculate ADSPEC RSVP (3) Routers process PATH message Examine SENDER_TSPEC Adjust ADSPEC Recipient receives PATH message Returns a RESV message Containing a FLOWSPEC The desired QoS parameters RESV travels back along path travelled by PATH packets in reverse naturally Routers agree to provide service in FLOWSPEC Or do not... RSVP (4) A Normal routing reverse path not guaranteed to be useful Routers that will process forward traffic must see RESV B

6 RSVP (5) A B As part of state (soft state) retained when PATH processed Router remembers immediate source of PATH message RESV message not routed normally follows inverse of route used by PATH RSVP - Path & Multicast PATH message transmitted same way as data To same destination address Multicast destination address Transmitted over multicast tree Causes path setup over full tree to all recipients RSVP - Reservation RESV message transmitted From recipient To sender

7 RSVP - Reservation (2) Every node sends RESV message RESV reaches router that has seen one already Reservations combined Only one RESV sent "upstream" RSVP - Reservation (3) Same happens for all nodes RESV travels upstream Until it reaches a router that has processed one already Reservations combined Multicast QoS Differentiated Services Just a request for queueing Multicast/unicast irrelevant Once outgoing interface(s) selected appropriate QoS for DSCP used Multicast & QoS not incompatible Both are hard Both have scaling issues Implementing both together makes sense

8 Multicast Security Authentication No issues Source is authenticated Source is unicast address Authentication proceeds as normal Non-repudiation Aspect of authentication Privacy Wanted with multicast? packets are sent everywhere YES private groups can use multicast group spread over Internet communicate amongst themselves Multicast Security Privacy Encrypted packets Encryption not a problem Just algorithm to apply to packet data Decryption? Where does key com from? Key Distribution Big problem for multicast Key needs to go to many recipients perhaps thousands Key needs to remain secret! Hard with many recipients Multicast Security Public Key Encryption Common solution to key distribution One party invents shared key Encrypts with public key of other party Only the other can decrypt Using their secret private key Transmits to other Other decrypts Uses key obtained for later communication No-one else can obtain shared key Multicast What public key? Recipients need private key private key shared amongst thousands Not very private

9 Multicast Applications Almost any application could be multicast Any application class Not specific application/protocol Just requires multiple recipients For example File transfer Distributed Database Conferencing audio/video/data No real limits Hence no typical application Multicast Applications Driving applications Those for which unicast does not work File transfer works using unicast Just uses more bandwidth than if multicast If there are many recipients Real Time high bandwidth Does not work unicast Insufficient bandwidth for unicast Too many distinct streams Relay sites partial solution but just faking multicast Multicast Applications Audio Conferencing vat rat others Video Conferencing vic nv others Data Conferencing wb nte others File transfer imm

10 Inter Domain Multicast Still an open topic No good solution Nothing yet actually deployed proven to work Issues Scaling Scaling Scaling (get the point...) Also incompatible M-IGP protocols Different rules for multicast forwarding Scaling Problems Flooding All multicast routing DVMRP PIM-DM Packet flooding & prune MOSPF Link state advertisement PIM-SM CBT Rendezvous Point locations Acceptable in local domain Not on full internet Scaling Problems Router State Flood & Prune (DVMRP, PIM-DM) per group, source, link prune information significant if much pruning MOSPF all groups at all locations significant in large net Rendezvous Point (PIM-SM, CBT) RP for each group prune info per group, link

11 M-IGP Problems RPF or not must multicast packets originated from particular source or appear to Source Specific state Can distribution differ based upon source address Unidirectional or bidirectional relationships between routers Explicit join or implicit Wide Area Multicast Can assume sparse multicast Unlikely to be many receivers Compared to size of Internet Use Rendezvous Point type techniques Designated sender to group Transport policy issues As for unicast Configured peering Inter Domain Multicast HDVMRP Hierarchical DVMRP HPIM Hierarchical PIM Multicast Source Discovery Protocol MSDP Allows peers to learn of multicast groups Border Gateway Multicast Protocol BGMP Domains are multicast receivers Must explicitly join groups Root domain selected based upon multicast address

12 MSDP Multicast Source Discovery Protocol RFC3618 (Oct, 2003) (ex Connects PIM-SM domains Possibly others Unspecified how Configured MSDP Peers TCP sessions Defined client/server RP in PIM-SM domain Discovers new source PIM register procedure Sends Source Active message to local MSDP peers source address multicast group ID MSDP (2) MSDP peer Receives SA from local RP Distributes to its MSDP peers Entire MSDP world learns of active source For particular multicast group MSDP SA distribution variant RPF flooding send everywhere ignore messages from more distant senders rate limited smoothing buffer called cache in RFC distribute regularly provided being refreshed no forwarding arriving SA refreshes buffer MSDP (3) Flood and Join Flooding of SA as described Network learns of all active groups all active senders for each group If any local receivers local RP joins distribution tree receives traffic multicasts to local area Scaling filtering permitted even required only permit certain groups or certain senders SA distribution rate limited Uses TCP point to point ack d & reliable sends large messages

13 BGMP Border Gateway Multicast Protocol RFC3913 Unlike MSDP actually defines data transmission Hybrid PIM-SM / CBT distribution tree mechanism Net divided into domains Each owns a set of multicast groups prefix based group assignment works best with IPv6 Domain is root of distribution tree for multicast groups in its block Prefers bi-directional routing no RPF checks BGMP (2) BGMP & Intra-domain multicast routing DVMRP & PIM-DM RPF Flood & Prune BGMP entry router must be RPF for source easy for single connect point all traffic comes that way with multiple connections BGMP peer-peer forwarding PIM-SM BGMP peer attempts to become RP for external sourced groups complicated when switch to source based tree CBT CBT most similar to BGMP bi-directional shared trees But BGMP (3) (Sep 29, 2004) (ex MOSPF Hardest to handle Most different internal philosophy No source-specific join/prune faked by joining all sources