1 / 14

EE 122: Integrated Services

EE 122: Integrated Services. Ion Stoica November 13, 2002. Integrated Services (Intserv). Provide three services (see last lecture) Best-effort (“elastic” applications) Hard real-time (“real-time” applications) Soft real-time (“tolerant” applications). An Intserv Node Architecture.

huong
Télécharger la présentation

EE 122: Integrated Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EE 122: Integrated Services Ion Stoica November 13, 2002

  2. Integrated Services (Intserv) • Provide three services (see last lecture) • Best-effort (“elastic” applications) • Hard real-time (“real-time” applications) • Soft real-time (“tolerant” applications) istoica@cs.berkeley.edu

  3. An Intserv Node Architecture Routing Messages Routing RSVP RSVP messages Control Plane Admission Control Data Plane Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out istoica@cs.berkeley.edu

  4. Data Plane • Input interface: • Lookup: use forwarding table to select the router’s output interface to forward the packet • Output interface: • Classification: classify each packet to the flow it belongs to • A flow identified by source and destination IP addresses, source and destination port numbers, protocol type • Buffer management • Scheduling: schedule each packet such that each flow achieves the promised service • E.g., Weighted Fair Queueing istoica@cs.berkeley.edu

  5. Control Plane: Resource Reservation Protocol (RSVP) • Signaling protocol for establishing per flow state required for • Admission control • Classification, buffer management, and scheduling • Carry resource requests from hosts to routers • Collect needed information from routers to hosts • At each hop • Consult admission control and policy module • Set up admission state or informs the requester of the failure

  6. RSVP Design Features • IP Multicast centric design • Receiver initiated reservation • Different reservation styles (we skip this…) • Soft state inside network • Decouple routing from reservation istoica@cs.berkeley.edu

  7. The Big Picture Network Sender PATH Msg Receiver

  8. The Big Picture Network Sender PATH Msg Receiver RESV Msg

  9. RSVP Basic Operations • Two message types: PATH and RESV • Sender sends PATH message via the data delivery path • Set up the path state each router including the address of previous hop • Receiver sends RESV message on the reverse path • Specify the reservation style, QoS desired • set up the reservation state at each router • Things to notice • Receiver initiated reservation • Decouple the routing from reservation • Two types of state: path and reservation istoica@cs.berkeley.edu

  10. IP routing PATH RESV Route Pinning • Problem: asymmetric routes • You may reserve resources on RS3S5S4S1S, but data travels on SS1S2S3R ! • Solution: use PATH to remember direct path from S to R, i.e., perform route pinning S2 R S S1 S3 S4 S5 istoica@cs.berkeley.edu

  11. PATH and RESV messages • PATH also specifies • Source traffic characteristics – use token bucket • Reservation style – specify whether a RESV message will be forwarded to this server • RESV specifies • Queueing delay and bandwidth requirements • Source traffic characteristics (from PATH) • Filter specification, i.e., what senders can use reservation • Based on these routers perform reservation istoica@cs.berkeley.edu

  12. Soft State • Per session state has a timer associated with it • Path state, reservation state • State lost when timer expires • Sender/Receiver periodically refreshes the state, resends PATH/RESV messages, resets timer • Claimed advantages • No need to clean up dangling state after failure • Can tolerate lost signaling packets • Signaling message need not be reliably transmitted • Easy to adapt to route changes • State can be explicitly deleted by a Teardown message istoica@cs.berkeley.edu

  13. RSVP and Routing • RSVP designed to work with variety of routing protocols • Minimal routing service • RSVP asks routing how to route a PATH message • Route pinning • Addresses QoS changes due to “avoidable” route changes while session in progress • QoS routing • RSVP route selection based on QoS parameters • Granularity of reservation and routing may differ • Explicit routing • Use RSVP to set up routes for reserved traffic istoica@cs.berkeley.edu

  14. Recap of RSVP • PATH message • Sender template and traffic spec • Advertisement • Mark route for RESV message • Follow data path • RESV message • Reservation request, including flow and filter spec • Reservation style and merging rules (relevant in the case of IP multicast) • Follow reverse data path • Other messages • PathTear, ResvTear, PathErr, ResvErr istoica@cs.berkeley.edu

More Related