1 / 9

Reliable Unicast Requirements for the COPS Protocol

This document discusses the reliable unicast requirements for the COPS (Common Open Policy Service) protocol, including the need for outsourcing policy decisions to a server, the client/server model, dynamic configuration of routers/switches, and more.

gjoel
Download Presentation

Reliable Unicast Requirements for the COPS Protocol

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. Reliable Unicast Requirementsforthe COPS Protocol IETF, January 20 Shai HerzogFounder and CTO

  2. COPSCommon Open Policy Service • Outsourcing policy decisions to a server • PDP: Policy Decision Point • PEP: Policy Enforcement Point • Client/Server model • Query/response (decision) • Stateful (only updates are exchanges) • Dynamic configuration of routers / switches • Simple for PEPs (complications fall on PDPs) • Extensible • Client extensions: RSVP, DiffServ, … • Developed at the RAP WG IPHighway Inc.

  3. COPS scenario PDP PDP COPS COPS REQ DEC RSVP RSVP or Diff-Serv RSVP PEP PEP IPHighway Inc.

  4. Transport Requirements • UDP vs. TCP • TCP was close enough • Won based on requirements + simplicity • Thinking: lets not re-invent the wheel • Requirements • Reliable, in sequence delivery • Large / Streaming payload • Real-Time response / quick delivery • Connection failure discovery IPHighway Inc.

  5. Reliable, in sequence delivery • Order is critical • COPS transactions are not numbered • Protocol cannot afford to loose transactions • COPS communicates Updates / accounting info • Loosing updates would get COPS out of synch • Control is most critical when network is in trouble • Retransmitting a fragment vs. a large UDP packet • TCP is doing fine here IPHighway Inc.

  6. Large / Streaming payload • COPS may carry large payload • Certificates may be large • Many certificates may be included • Protocols details (RSVP or DS) could be quite large • TCP is doing fine here IPHighway Inc.

  7. Real-Time response / quick delivery • COPS reacts to real-time requests/traffic • Slow response delays RSVP setup time and DS installation • TCP shortcomings • Slow-Start vs. real-time priority traffic • Can’t wait for the window size to open up • Don’t want to yield on congestion • Transactions may be short and bursty • RTT estimation not be good for bursts • Windowing mechanisms may respond too slowly IPHighway Inc.

  8. Connection failure detection • COPS is Stateful • Quiet means nothing changed • Relies on quick failure detection, otherwise • Permissions may be unjustly assumed • Accounting may continue unjustly • TCP shortcomings • TCP may take too long to discover connection failure • COPS uses keep-alive outside of TCP IPHighway Inc.

  9. Summary • UDP was inappropriate for COPS • TCP was good enough • A better streaming protocol would have to address • Real-time delivery for priority bursty transactions • More dependable connection failure facilities IPHighway Inc.

More Related