1. 1 Policy-Based Networking Policy-Based Networking Introduction, Concepts, Protocols, Products Presented by Andreas Polyrakis apolyr@softlab.ntua.gr 04.04.2003 Greek Research Network (GRNET), National Technical University of Athens (NTUA)

2. 2 What is Policy-Based Networking? “A modern network management approach that attempts to control the network through abstract high-level policies.”

3. 3 RoadMap  Part I: Policy Based Networks  The need for PBN  Policy-Based Networks Architecture, advantages, entities  Part II: COPS  The COPS base protocol  COPS-RSVP  COPS-PR PIB, example  Part III: Current Status  Part IV: QoS and PBN

4. 4 PART I: Introduction to Policy-Based Networking

5. 5 Properties of Modern Networks  Exponential Growth (size/volume)  Big variety of managed devices (not only routers/switches anymore…) and resources.  Large number of different network services  Converging networks (data, voice, video, web)  New services (VPN, VoIP)  Increased complexity (MPLS, DiffServ, RSVP)  Level of abstraction & automation in Network Management must be raised  Scalable NM solutions are necessary

6. 6 Traditional NM techniques: CLI  Command Line Interface NM  Goals set by the Network Manager  Each device was programmed to implement these goals  The devices had to be programmed independently, although they served similar goals  When the goals/topology changed, the administrator had to update all nodes independently  SIGNIFICANT scalability problems  Consistency issues  Difficult to implement complex policies  Lack of automation  Need for highly-specialized personnel  Hard to monitor the network

7. 7 Traditional NM techniques: SNMP  Simple Network Management Protocol (SNMP)  Managed objects on the devices handled in a unified way  Raised the level of abstraction  Allowed some automation  But…  SNMP was designed for monitoring – not for configuring devices  Scalability & efficiency issues  Still device/vendor dependent  Configuration still depends on device’s role, capabilities/limitations, manufacturer and overall network topology

8. 8 Policy Based Networking (PBN)  A modern Network Management approach  Based on policies  E.g., give administrators high priority  Policies are Abstract, Goal oriented  (“what” instead of “how”)  PBN attempts to  Raise the abstraction level  Automate NM  Centralize & simplify network configurations  Simplify supervision  Increase management flexibility

9. 9 PBN Architecture Key Entities:  Policy Decision Point (PDP)  Policy Enforcement Point (PEP) Operation Concept:  The Administrator edits abstract Policies with an editing tool  Policies are sent to the describe network behavior with a high level of abstraction (What, not How)  The policies are processed by the PDPs – late binding with network details  Policies are distributed to the PEPs as configuration data - commands (after being transformed to the appropriate form)

10. 10 Advantages of PBN Advantages: Centralized management Scalability High abstraction  easy to determine and control behavior Automation  Consistency Dynamic binding of policies  new types of policies, flexibility e.g: Give engineers higher priority

11. 11 Policy Decision Point (PDP)  Role of the PDP:  Receives the high-level policies  Monitors the network events  Records the capabilities/limitations of the PEPs  Produces and updates the configuration data of the PEPs according to the network policies and network state  The PDP DOES NOT simply distribute policies:  Binds the policies with the network state  Produces the APPROPRIATE configuration data according to the type of each specific PEP, its role, its capabilities and its limitations  The intelligence of the model is mainly concentrated at the PDP level

12. 12 Policy Enforcement Point (PEP)  Role of the PEP:  Receives configuration data from the PDP  Always enforces the PDP directions  The PEP may contain more than one clients  Different client-types serve non- overlapping management area (Security, QoS, Accounting, …)

13. 13 Policy Console Policies: What instead of How: E.g: The engineers (10.1.1.x) must have high priority (DSCP=6) HOW approach: Remark 10.1.1.x traffic with DSCP=6 WHAT approach: Give high priority to Engineers The policy is still valid even if:  topology changes (nodes are added/removed/replaced)  the “engineers” subnet is changed/expanded  Network services change (e.g. DiffServ is replaced with RSVP) Also, “engineers” do not need to be associated with a specific subnet!!!

14. 14 Directory Server  Secondary role in PBN  Directories  Store policy-related information Users & application profiles Groups Role of the network devices Etc  Store policies & distribute them to the PDPs Standard or non-standard representation of policies

15. 15 Operation Modes Policy Server Device Initialization 1. The PEP connects to the PDP, reports its capabilities/limitations and requests configuration data 2. The PDP generates the initial policies according to the global policies and current network state 3. The PDP sends the initial policies in the form of configuration data 4. The PEP stores these data and determines the behavior of the device according to them PEP PDP REQ DEC BOOT PROCESS INSTALL Policies Current state 1 2 3 4

16. 16 PDP Operation Modes (Cont’d) Device Outsourcing (PULL): 1. A new event is detected that cannot be treated with the existing configuration data 2. The PEP requests directions to treat the event 3. The PDP process the request according to the current policies/network state 4. The PDP downloads the appropriate configuration data 5. The PEP serves this event and all similar events according to this data Provisioning (PUSH): A. The PDP detects changes B. The PDP sends commands that add, update or delete configuration data C. The PEP updates its behavior and treats future events according to them PEP Policies Current state DEC CHANGE INSTALL, UPDATE, DELETE CONFIGURATION DATA A B C Device PEP PDP REQ DEC New Event PROCESS INSTALL Policies 2 3 4 5 Current state 1

17. 17 PART II: COPS, the IETF protocol for PBN

18. 18 IETF Standardization  Policy Framework  Architecture, terminology, building blocks  Core and QoS Schema  RAP (Resource Allocation Protocol)  COPS  COPS-RSVP, COPS-PR  PIB (Policy Information Base) definition  …  Other WGs

19. 19 The COPS Protocol (RFC 2748)  COPS: Common Open Policy Service  Developed by the IETF RAP WG  Standardizes the communication between PDPs and PEPs  Design Principles:  Statefull Client-Server protocol, uses TCP  Reliable, Efficient, fault-tolerant and secure  PDP @ Policy Server, PEP @ Managed Entity  The PEP always obeys the PDP  Both Outsourcing (Pull) and Provisioning (Push) models  A communication protocol - Does NOT define the semantics of the exchanged policy data

20. 20 The COPS Protocol (Cont’d)  The COPS BASE protocol  Provides a way to communicate policy-related information between the PDP to the PEP  Determines the behavior of the entities, as far as the communication is concerned  Does not define the semantics of the exchanged data  Does not describe HOW this data is produced by the PDP or HOW this data will be interpreted by the PEP  COPS client-types  Control different management areas (DiffServ, RSVP, accounting, Security, etc)  Each PEP implements one or more clients of various client-types  Client-types are defined on extra documents (standard or vendor-specific)  COPS-RSVP and COPS-PR are such clients

21. 21 COPS Basic Messages  OPN: Open Connection  CAT: Connection Accept  CC: Connection Close  KA: Keep Alive PEP PDP1 OPN CAT CC PDP2 OPN CAT KA

22. 22 COPS Basic Messages (Cont’d)  REQ: Request  DEC: Decision  RPT: Report  SSQ: Synch. Request  SSC: Synch. Complete PEP PDP REQ DEC RPT DEC RPT SSQ SSC

23. 23 COPS vs. SNMP

24. 24 Discussion  Is PBN going to replace SNMP?  Most probably, no: SNMPv3 addresses some issues Legacy devices – existing software – trained personnel Good for Monitoring  Is PBN the only attempt for management automation?  No, other technologies also exist, e.g., Directory-Enabled Networking (Directories are good for static configuration data, such as IP, DNS, default PDP, etc)

25. 25 COPS usage for RSVP (RFC 2749) COPS-RSVP:  Defines a client-type of COPS for RSVP  Provides centralized monitoring and control of RSVP  COPS-RSVP PDPs control COPS-RSVP clients on detwork devices  PEP performs (though PDP directions):  Admission control  Data classification  Bandwidth management (queuing)  Data policing  RSVP usage report  Simplified operation example  A Router receives PATH / RESV  Attempts to process and serve locally  If unable to serve locally, forwards to the PDP  Perform admission control according to PDP decision

26. 26 The COPS-PR Protocol (RFC 3084) COPS for Policy PRovisioning:  Extends COPS (Common Open Policy Service)  A client-type of COPS  PRovisioning mode: The PEP always serves events according to pre- downloaded policies-the PDP keeps these policies updated  Simpler than COPS (Provisioning mode only)  Not suitable for all management areas (e.g., RSVP)  Initially designed for DiffServ, but seems suitable for several management areas  Does NOT address a specific management area.

27. 27 Policy Information Base  A structure similar to a MIB structure  A tree of PRovisioning Classes (PRCs)  PRovisioning Instances (PRIs)  Policies can be constructed as a set of PRIs  PIBs are pre-defined  Different PIBs for different policing areas (Diffserv, Accounting, IP filtering, etc)

28. 28 PIB Example VALUEPRID (128.1.1.2,6)2.2.1.1.2 (128.1.1.1,6)2.2.1.1.1 (100,1,11)2.2.1.2.2 (100,2,10)2.2.1.2.1 (4,NO)2.1.3.1.2 (100,2)2.1.3.2.1

29. 29 COPS-PR Example 1 Policy: if traffic to IPs 128.1.1.1 or 128.1.1.2 has DSCP=4 then remark it with DSCP=6 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10) 2.2.1.2.2  (100,1,11) 2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.2  (128.1.1.2,4) Install: 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10) 2.2.1.2.2  (100,1,11) 2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.2  (128.1.1.2,4) PEP connects PDP->PEP DECEvent:PIB (@ PEP)

30. 30 COPS-PR Example 2 Policy: if traffic to engineers has DSCP=4 then remark it with DSCP=6 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10) 2.2.1.1.1  (128.1.1.1,4) Remove: 2.2.1.2.2 2.2.1.1.2 Engineer at 128.1.1.2 logs out if traffic to 128.1.1.1 has DSCP=4 then remark with DSCP=6 PEP connects No Engineer is logged Similar to the first case Install: 2.2.1.2.2  (100,1,11) 2.2.1.1.2  (128.1.1.3,4) An Engineer logs to 128.1.1.3 (similar to the first case) 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10) 2.2.1.2.2  (100,1,11) 2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.2  (128.1.1.2,4) Install: 2.1.3.2.1  (100,2) 2.1.3.1.2  (6,NO) 2.2.1.2.1  (100,2,10) 2.2.1.2.2  (100,1,11) 2.2.1.1.1  (128.1.1.1,4) 2.2.1.1.2  (128.1.1.2,4) Two Engineers log on at 128.1.1.1 and 128.1.1.2 if traffic to 128.1.1.1 or 128.1.1.2 has DSCP=4 then remark with DSCP=6 PIB (@ PEP)PDP->PEP DECEvent:

31. 31 PIB Reuse

32. 32 My MSc Thesis in 60’’ Definition of a supplementary COPS-PR client type that increases:  Efficiency ( Bandwidth, monitoring, PDP resources )  Distribution ( Intelligent PEPs, de-centralized decision and monitoring )  Robustness ( PDP loaded, smaller messages )  Fault-tolerance ( less PDP dependence ) Related Publications: R. Boutaba and A. Polyrakis, "COPS-PR with Meta-Policy Support", IETF, Internet-Draft, April 2001 (www.ietf.org/internet- drafts/draft-boutaba-copsprmp-00.txt). R. Boutaba and A. Polyrakis, “Towards Extensible Policy Enforcement Points”, IEEE Workshop on Policies for Distributed Systems and Networks, Bristol, U.K., 29-31 January 2001, pp. 247-261. R. Boutaba and A. Polyrakis, “Projecting FCAPS to Active Networks”, Proc. IEEE Enterprise Applications and Services Conference (EntNet@Supercomm 2001), Atlanta, GA, USA, June 2001. R. Boutaba and A. Polyrakis, “Extending COPS-PR with Meta-Policies for scalable management of IP networks”, Journal of Network and Systems Management, Special Issue on Management of Converged Networks, Vol. 10, No. 1, March 2002. R. Boutaba and A. Polyrakis; “Projecting Advanced Enterprise Network and Service Management to Active Networks”, IEEE Network Magazine, Vol.16 No.1, January 2002, pp 28-33. A. Polyrakis and R. Boutaba; “The Meta-Policy Information Base”; IEEE Network Magazine, Special issue on Policy Based Networking, Vol.16 No.2, March/April 2002, pp 40-48. A. Polyrakis and R. Boutaba; “The Meta-Policy Information Base”, IETF, Internet-Draft, April 2002 (www.ietf.org/internet- drafts/draft-polyrakis-mpib-00.txt).

33. 33 Part III: Current Status

34. 34 COPS Products  COPS stack implementations  COPS servers  COPS clients

35. 35 Vovida COPS implementation  Open source COPS stack  COPS-PR support  Basic COPS Server, extensible  Can be used in buliding applications such as:  Implementing policy based QoS  Implemetating application level AAA (Authorization, Authentication and Accouting) functions in IP telephony  …

36. 36 Intel COPS Implementation COPS client SDK:  Open source COPS stack  COPS-RSVP client  COPS-PR client DiffServ PIB  Test PDP (non-extensible)

37. 37 HP PolicyXpert PBN platform, controls through COPS or CLI:  Cisco routers  hewlett-packard pro-curve switches  Packeteer packetshapers  Microsoft Windows NT servers  Uses an hp-defined COPS type  No Directory integration

38. 38 Cisco COPS QoS Policy Manager Cisco COPS-QPM:  COPS Server  Controls devices through COPS and SMNP  Supports COPS – RSVP  Catalyst 6000 5.4(1) and 5.4(2)  Cisco 7200 and 7500/RSP routers Cisco IOS® 12.1(1)T  Cisco 2600, 3600, 4500, and 4700 routers  Supports COPS-PR  Catalyst 6000 switch CatOS 5.4(1) and 5.4(2)  Catalyst 5000 switch CatOS 5.3, 5.4, 5.5 and 6.1  No Directory integration

39. 39 CISCO COPS-RSVP support  Appears in IOS 12.1(1)T and later  COPS-RSVP PDP: COPS-QPM.  COPS-RSVP PEP: on the router Enabling COPS-RSVP on a Cisco Router: Router(config)# ip rsvp policy cops servers 161.44.130.168 161.44.129.6 (Tells the router to request RSVP policy decisions from the servers listed, Also enables a COPS-RSVP client (PEP) on the router. ) Supported protocols:  RFC 2749, COPS Usage for RSVP  RFC 2205, Resource ReSerVation Protocol (RSVP)  RFC 2748, The COPS (Common Open Policy Service) Protocol

40. 40 Intel® Local Policy Module for COPS COPS-LPM: COPS-LPM: Allows Windows 2000 hosts accept bandwidth, security, and access policies from a policy server:  The Win2k ACS (Admission Control Service) acts as a SBM (Subnet Bandwidth Manager) in the domain  The ACS outsources admission control to a policy server through COPS-LPM  COPS-LPM is used in conjunction with resource RSVP  Part of the Win2k Resource Kit

41. 41 Nortel Optivity Policy Services  Designed to manage traffic prioritization and network access security  Targets specific Bay/Passport routers  Targets DiffServ (only)  COPS-PR, DiffServ PIB  CLI  802.1p  Centralized management for DiffServ policies  LDAP support (ships with iPlanet 5)

42. 42 Part IV: QoS and PBN

43. 43 Why PBN is necessary  Need for new types of dynamic policies  Need for automation  Need for high-level management

44. 44 How?  COPS-RSVP  COPS-PR/Diffser PIB  Other standard COPS clients COPS-LPM …  Other non-standard COPS clients see the PolicyXpert approach  Other non-IETF approaches

45. 45 Difficulties Too many technologies/protocols/architectures:  Insufficient COPS products  LDAP necessary  User authentication in the network. How?  RSVP vs Diffserv. Mapping.  SBM, 802.1p…  Inter-domain policies for user-specific requests. How?

46. 46 Case study: the GRNET approach  Solve the problem at the LAN, solve it at the WAN, police in the boundary  LAN approach  Directory service  RSVP  Custom tools for non RSVP-enabled applications  Custom tools for user authentication  Traffic marked before entering the WAN  Traffic policed before entering the LAN according to its own policies  NO COPS at this time, can be supported later  WAN approach  DiffServ Domain  Egress - Shengen Model (Check on Exit, travel free)  Ingress – Visa Model (Check on entrance)  SLAs between LANs-WAN or among LANs

47. 47 ? Presented by Andreas Polyrakis apolyr@softlab.ntua.gr