Transcript Part I: Introduction

Greek Research Network (GRNET),
National Technical University of Athens (NTUA)
Policy-Based Networking
Introduction, Concepts, Protocols, Products
Presented by
Andreas Polyrakis
[email protected]
04.04.2003
1
What is Policy-Based Networking?
“A modern network management approach
that attempts to control the network
through abstract high-level policies.”
2
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
3
PART I:
Introduction to
Policy-Based Networking
4
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
5
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
6
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
7
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
8
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)
9
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
10
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
11
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 nonoverlapping management area
(Security, QoS, Accounting, …)
12
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!!!
13
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
14
Operation Modes
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
PDP
Policies
Current
state
2 PROCESS
3
DEC
1.
Policy Server
REQ
Initialization
1
BOOT
4 INSTALL
PEP
Device
15
Operation Modes (Cont’d)
Outsourcing (PULL):
Policies
Current
state
4
treated with the existing configuration
data
2. The PEP requests directions to treat
the event
3. The PDP process the request according
PDP
4. The PDP downloads the appropriate
Device
A CHANGE
B
to the current policies/network state
New
Event
5
1
INSTALL
Current
state
Policies
DEC
2
PDP
DEC
REQ
3 PROCESS
1. A new event is detected that cannot be
configuration data
5. The PEP serves this event and all
similar events according to this data
Provisioning (PUSH):
PEP 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
C
INSTALL, UPDATE,
DELETE
CONFIGURATION
DATA
PEP
Device
16
PART II:
COPS, the IETF protocol for PBN
17
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
18
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

19
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
20
COPS Basic Messages
 OPN: Open Connection
OPN
 CAT: Connection Accept
CAT
 CC: Connection Close
KA
PDP1
KA
 KA: Keep Alive
KA
PEP
CC
OPN
CAT
PDP2
CC
21
COPS Basic Messages (Cont’d)
 REQ: Request
REQ
 DEC: Decision
DEC
 RPT: Report
RPT
 SSQ: Synch. Request
 SSC: Synch. Complete
DEC
PEP
RPT
PDP
SSQ
SSC
RPT
22
COPS vs. SNMP
23
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)
24
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
25
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 predownloaded 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.
26
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)
27
PIB Example
PRID
2.1.3.2.1
2.1.3.1.2
2.2.1.2.1
2.2.1.2.2
2.2.1.1.1
2.2.1.1.2
VALUE
(100,2)
(4,NO)
(100,2,10)
(100,1,11)
(128.1.1.1,6)
(128.1.1.2,6)
28
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
Event:
PDP->PEP DEC
PEP connects
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)
PIB (@ PEP)
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)
29
COPS-PR Example 2
Policy:
if traffic to engineers has DSCP=4 then remark it with DSCP=6
Event:
PDP->PEP DEC
PEP connects
No Engineer is logged
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
<NULL>
Engineer at 128.1.1.2 logs out
if traffic to 128.1.1.1 has
DSCP=4
then remark with DSCP=6
Remove:
An Engineer logs to 128.1.1.3
(similar to the first case)
Install:
PIB (@ PEP)
<EMPTY>
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)
2.2.1.2.2
2.2.1.1.2
2.2.1.2.2  (100,1,11)
2.2.1.1.2  (128.1.1.3,4)
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)
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)
Similar to the first case
30
PIB Reuse
31
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/internetdrafts/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/internetdrafts/draft-polyrakis-mpib-00.txt).
32
Part III:
Current Status
33
COPS Products
 COPS stack implementations
 COPS servers
 COPS clients
34
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
…
35
Intel COPS Implementation
COPS client SDK:
 Open source COPS stack
COPS-RSVP client
 COPS-PR client

• DiffServ PIB

Test PDP (non-extensible)
36
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
37
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
38
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
39
Intel® Local Policy Module for COPS
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
40
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)
41
Part IV:
QoS and PBN
42
Why PBN is necessary
 Need for new types of dynamic policies
 Need for automation
 Need for high-level management
43
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
44
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?
45
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
46
Presented by Andreas Polyrakis
[email protected]
47