Network Policy Languages:
`A Survey and a New Approach
`
`Gary N. Stone, Bert Lundy, and Geoffrey G. Xie, U.S Department of Defense
`
`Abstract
`In this article a survey of current network policy languages is presented. Next, a sum-
`mary of the techniques for detecting policy conflicts is given. Finally, a new lan-
`guage, Path-Based Policy Language, which offers improvements to these is
`introduced. Previous network policy languages vary from the very specific, using
`packet filters at the bit level, to the more abstract where concepts are represented,
`with implementation details left up to individual network devices. As background
`information a policy framework model and policy-based routing protocols are discussed.
`PPL’s path-based approach for representing network policies is advantageous in that
`quality of service and security policies can be associated with an explicit path
`through the network. This assignment of policies to network flows aids in new initia-
`tives such as integrated services. The more stringent requirement of supporting path-based
`policies can easily be relaxed with the use of wild card characters to also support
`differentiated services and best-effort service, which is provided by the Internet
`today.
`
`MM
`
`illions of dollars are lost, a company folds, and
`thousands of employees are let go, throwing a
`community into economic chaos. These events
`could result from discontinued funding from
`Silicon Valley investors becoming aware of continued reports
`of poor quality of service (QoS), security problems, and the
`inability of clients to access the company’s Web sites. This
`ingenious company was the first to integrate voice, video, and
`data all on the same network based on a company’s policies.
`The company’s untimely demise was the result of conflicting
`network policies that were disseminated automatically through-
`out the network’s policy servers, causing erratic network per-
`formance. This scenario, although extreme, shows the
`importance of being able to represent the network policy
`goals of a company while simultaneously verifying that those
`goals do not conflict with each other.
`To understand how policy can play a role in managing a
`network, policy must be defined and applied to communica-
`tions networks. The Internet Engineering Task Force (IETF)
`has proposed an Internet-draft of terminology for describing
`network policy [1] and provides many of the definitions used
`throughout this article.
`A policy is formally defined as an aggregation of policy rules
`[1]. Each policy rule is made up of a set of conditions and a
`
`This work was supported in part by DARPA under the NGI program and
`a grant from NASA Ames Research Center.
`
`corresponding set of actions. The conditions define when the
`policy rule is applicable. Once a policy rule is so activated, one
`or more actions contained by that policy rule may then be exe-
`cuted. These actions are associated with either meeting or not
`meeting the set of conditions specified in the policy rule. In
`other words, a policy specifies what action(s) must be taken
`when a set of associated conditions are met.
`A simple view of policy in regard to networks is that policy
`constrains communications. Specifically, network policy
`defines the relationship between clients using network
`resources and the network elements that provide those
`resources. A client in this case refers to users as well as appli-
`cations and services.
`Network policy allows administrators to manage network
`elements to provide service to a set of clients. If every system
`were permitted to communicate with all other systems without
`restriction, there would be no need for network policies.
`Increasingly, networks that once only supported best-effort
`traffic are integrating voice and data as well. Without a means
`for network managers to control the use of the network, mis-
`sion-critical applications and general network performance
`are going to suffer, and there will be little hope of supporting
`future real-time applications.
`Network policies are grouped into three general areas:
`• How the policy is used
`• How the policy is triggered
`• At which level the policy is applied
`A usage policy describes which services will be used to
`
`10
`
`U.S. Government Work Not Protected by U.S. Copyright
`
`IEEE Network • January/February 2001
`
`1
`
`SAMSUNG 1046
`
`

`

`maintain the current state of the network or to transition to a
`new state. Services which may be available in the network are
`differentiated service classes, virtual private networks, encryp-
`tion capability, and so on. A usage policy also describes how
`those services will be used. For example, the ability to differ-
`entiate the handling of separate flows of traffic based on the
`service class in which they reside or to which virtual channel
`they belong describes how a service is used.
`Policies can be triggered in two ways, either statically or
`dynamically. “Static policies apply a fixed set of actions in a
`pre-determined way according to a set of pre-defined parame-
`ters that determine how the policy is used” [1]. Examples of
`static policies are: transit traffic is not permitted during nor-
`mal working hours; Internet radio is only permitted after 4:00
`p.m.; for security reasons certain network addresses are
`denied access to network resources.
`Dynamic policies are only enforced when needed, and are
`based on changing conditions of the network such as conges-
`tion, packet loss, or the loss of a network router. To support
`the dynamic and sometimes unexpected nature of the net-
`work, actions can be triggered when an event causes a policy
`condition to be met. Examples of dynamic polices are: when
`the network gets congested, streaming video traffic is disal-
`lowed; or when a particular service class of user is utilizing the
`network, lower best-effort traffic to only 25 percent of link
`capacity.
`Last, the level of the policy is applied as a category. These
`policies are differentiated by their granularity, such as the
`application level, user level, class level, or service level. For
`example, a mission-critical application may be given priority
`over all other network traffic, or all users in the silver class
`(differentiated services) have priority over the bronze class,
`but must succumb to the gold class.
`Later in this article the authors introduce a policy lan-
`guage based on path. Path-based policy is defined as a policy
`were all attributes associated with the policy, which include
`the service type of the traffic, conditions used to trigger the
`policy, and the actions executed when the policy is triggered,
`are all bound to a predefined path. Using the path as the
`fundamental building block of a policy statement provides
`great control and flexibility. The ability to specify an explicit
`path, which represents each node from source to destination,
`enables us to create virtual channels where resources are
`reserved to support real-time applications. These paths can
`be specified by either a user or a network administrator. If a
`path had the restriction of always including each node in the
`path, the number of unique paths needed to support a net-
`work could soon become overwhelming. This is why a path
`may include wild card characters, and thus adds great flexibil-
`ity to the way policies are specified. The use of a wild card
`character allows for path aggregation, which greatly reduces
`the number of paths that have to be specified, and at the
`extreme one path statement can specify all possible paths
`under an administrator’s control.
`Policy-based networking — the ability to control a network-
`ing environment by specifying and enforcing policies — is
`gaining increased interest among the network community.
`Policy-based networking helps manage user and application
`priority, QoS, and security rights based on management poli-
`cies. Because of an increasing industry trend to deploy busi-
`ness applications over the network and the convergence of
`voice, video, and data applications on the same network,
`major network vendors such as Cisco, Nortel, and Lucent
`Technologies are developing products to support network
`management. These products allow network managers to cre-
`ate and implement policies that can prioritize the use of net-
`work resources by different network applications so that
`
`bandwidth will be guaranteed to the most business-critical
`applications during times of network congestion. For example,
`a company that offers IP telephony — which has strict timing
`requirements — must not permit a large data file transfer to
`interfere. Network management also provides the ability to
`restrict the use of network segments by denying access to
`unwanted and perhaps malicious traffic. The ability to create
`and enforce network policies adds intelligence to a network
`that was previously based only on best-effort packet traffic.
`Rather than adding more bandwidth, which is expensive and
`time-consuming, to solve existing network congestion, compa-
`nies can use network policies to allow for important applica-
`tions and user groups to receive network priority over
`secondary network users. It is important to have an underlying
`mechanism to support and enforce these defined network
`policies. The IETF has attempted to define such an architec-
`ture in the working draft, “Policy Framework Core Informa-
`tion Model” [2].
`Many of the aspects of this mechanism needed to support
`policy-based networking are being addressed, such as policy
`storage structures, policy servers, and protocols to deliver
`translated policies to enforcement points. One aspect of poli-
`cy-based networking that does not seem to be receiving much
`attention is the verification of policies that are going to be
`applied to the network. Consistent enforcement of network
`policies, often specified by different people at different times,
`is impossible if those policies conflict with each other. Thus, a
`method is needed to detect and deal with conflicting policies
`before they are distributed throughout the network to the pol-
`icy enforcement points.
`
`IETF Policy Framework Core Information Model — With the
`emergence of service models such as differentiated services
`(DS) [3, 4], integrated services (IS) [3, 4], and multiprotocol
`label switching (MPLS) [4], the IETF has published a working
`draft for terminology to describe network policies and services
`[2]. The IETF tries to standardize a mechanism as well as a
`language in this draft by developing a scalable architecture for
`policy administration and distribution of network policies. A
`key to this architecture is a common language to represent
`and provide a consistent implementation of policy.
`An underlying assumption of this draft is that policies are
`stored in a centralized repository. The policy repository is one
`of three important entities of the model. The other entities
`are the policy enforcement points (PEPs) and policy decision
`point (PDP).
`A PEP is a component of a network node (e.g., a router,
`switch, or hub) where the policy decisions are actually
`enforced. When the PEP requires a policy decision about a
`new flow of traffic or authentication, for example, the PEP
`will send a request to a PDP.
`The PDP is the entity in the network where policy decisions
`are made. This PDP, which may reside on a remote server,
`will make policy decisions using information retrieved from
`policy repositories.
`Communication is needed to and from the policy repository
`as well as between the PDP and the PEP. In many proposals
`the policy repository is a directory, and therefore the appro-
`priate access protocol would be the Lightweight Directory
`Access Protocol (LDAP). Examples of a policy protocol,
`which is used to request and reply to policy decisions, could
`be the Common Open Policy Service (COPS) protocol [5] and
`Simple Network Management Protocol (SNMP) [6].
`Since the PEPs can potentially be from multiple vendors, a
`common policy language is needed to support the dissemina-
`tion of policy information to these devices. In the Policy
`Framework Core Information Model [2], policy is defined as
`
`IEEE Network • January/February 2001
`
`11
`
`2
`
`

`

`(( Hs, ARs, ARent ), (Hd, ARd, ARexit ), UCI, Cg)
`
`where:
`Hs is the source host address
`ARs is the source AR
`ARent is the entry AR (previous hop)
`Hd is the destination host address
`ARd is the destination AR
`ARexit is the exit (last hop)
`UCI is the User Class Id (e.g., Gold, Silver Bronze service levels)
`Cg are any global conditions
`
`■ Figure 1. A policy term.
`
`an aggregation of policy rules. Each of these policy rules is
`composed of a set of conditions and a set of actions to per-
`form if the conditions are met. The general form of these con-
`ditional statements is
`IF <condition 1> AND <condition 2> … AND <condition N>
`THEN <action 1> … AND <action N>
`The policy representation includes a means to prioritize
`and order both the conditional statements as well as the poli-
`cy actions. This is crucial when multiple policies exist and con-
`flict. A conflict occurs when the conditions of at least two
`policies are simultaneously satisfied, but the actions of at least
`one of the policies cannot be simultaneously executed. For
`example, a router may have two access control rules where
`their conditions are simultaneously satisfied, but one contains
`that action deny, the other permit. For example:
`access-list 1 permit 131.1.30.00.0.0.255
`access-list 1 deny 131.1.0.00.0.255.255
`The first permits traffic with IP addresses beginning with
`131.1.30 to pass. The second rule conflicts with the previous
`one by denying traffic with any IP address beginning with
`131.1. The first rule in an access list that satisfies the condi-
`tional requirement is executed. This procedure resolves con-
`flicts but puts the onus on the operator to enter the rules in
`the correct order.
`The rest of this article is organized into six sections. We
`review policy-based routing protocols. A lot of early work on
`the use of polices in networks occurred in the context of these
`protocols. We discuss languages used to represent network
`policies. These languages are at a more abstract level and can
`be used to describe policies without low-level details. An
`abstract language is beneficial when multiple devices and ven-
`dors are involved. We will discuss languages used to describe
`network traffic at a low level such as the protocol data unit
`(PDU) level. These languages are more adept at defining pat-
`terns for the selection of network traffic in the conditional
`section of a policy. This article contains a review of research
`efforts that involved using formal logic to determine consis-
`tency between policies. This formal logic section provides
`background information for features introduced with our new
`language. We introduce our language, the Path-Based Policy
`Language (PPL). Our goal is to represent network policies at
`an abstract level in order to support heterogeneous networks,
`while also providing translation of those policies into formal
`logic. Having policies represented in logic will provide the
`ability for theorem provers to detect conflicts. We then sum-
`marize the article.
`
`Policy-Based Routing Protocols
`In this section three policy-based routing protocols are
`reviewed. They provided a lot of early work on the use of
`policies in networks. All of these protocols enable policies to
`be enforced based on the elements of an explicit path through
`the network.
`
`Border Gateway Protocol
`Lougheed and Rekhter define an interau-
`tonomous routing protocol, Border Gateway Pro-
`tocol (BGP) [7–9], where routers share
`reachability information by passing autonomous
`system1 (AS) information between neighbors.
`This exchange of routing information contains
`full AS paths the traffic will transit to reach a dis-
`tant network. Path information is not only useful
`in removing loops in the network, but also allows
`policy decisions to be made at the AS level. Policy enforce-
`ment is not part of the protocol itself, but instead is manually
`configured at each BGP router.
`Policy decisions made by BGP [10, 11] are based on config-
`uration information manually configured into each router by
`an AS administrator. The enforcement of policies is accom-
`plished in two ways. The first is by specifying the procedure
`used by the AS router itself to select the best paths, and the
`second is by controlling the redistribution of routing informa-
`tion to neighboring ASs.
`Policy decisions can be based on various preferences and
`constraints. Since the complete AS path is advertised to
`neighboring routers, particular paths can be rejected based on
`an AS that is contained in the path. The reasons a particular
`path are rejected vary. For example, a particular AS whose
`control is under that of a major competitor may want to be
`avoided, causing one or more paths that include this AS to be
`eliminated from consideration. Performance information can
`also be used to eliminate paths from consideration. If an AS
`has access to metrics related to performance such as link
`speed, delay or capacity, these measurements can be used to
`rate multiple paths for selection.
`BGP, allowing an AS to control redistribution of routing
`information, is the means by which an AS can enforce policies
`on others. For example, if an AS does not want to be used for
`transit traffic, it does not advertise routes to networks other
`than those directly connected to it.
`Fundamentally, BGP is a distance-vector protocol, but instead
`of maintaining just the cost to each destination, BGP keeps track
`of the exact path used. This use of the path categorizes BGP as a
`path-vector protocol. As mentioned earlier, policies are not part
`of the BGP protocol itself; therefore, each AS may have its own
`means of evaluating paths. Each router contains a module for
`examining paths to a given destination and scoring them. This
`scoring mechanism, which may include local policy information,
`is then used to choose the best path to a destination. BGP
`routers can only advertise paths they themselves use. This pre-
`vents an AS from sending datagrams to a distant network using
`one path, but advertising an alternative path for others to use.
`Inter-Domain Routing Protocol (IDRP)
`Kunzinger and Thomas describe the Inter-Domain Routing
`Protocol (IDRP) [12, 13], which is the International Organiza-
`tion for Standardization (ISO) protocol for routing between
`ASs. IDRP came out of the same work as BGP, and may be
`considered a follow-on to BGP. Just as in BGP, IDRP sup-
`ports policy-based routing, but is not concerned with the
`implementation details of those policies. Policy-based routing
`can restrict access, and therefore enforce policy, by controlling
`the distribution of routing information to neighboring routers.
`
`1 AS and administrative region (AR) are a set of routers under a single
`technical administration, using one or more interior gateway protocols to
`route packets within the AS, and using an exterior gateway protocol to
`route packets to other ASs [3].
`
`12
`
`IEEE Network • January/February 2001
`
`3
`
`

`

`IP = 216.32.74.53
`
`AR
`2
`
`IP = 216.32.74.50
`
`IP = 216.34.20.1
`
`AR
`12
`
`AR
`5
`
`AR
`36
`
`IP = 131.120.1.13
`
`AR
`20
`
`This selective distribution of information can enable
`the AS to deny all transit traffic, or deny access to
`only certain network paths.
`The IDRP router accepts router information from
`neighboring routers, which express their views of the
`network, and uses this gathered information to con-
`struct its own view of the network. The IDRP router
`at this point can use local policy information to select
`or reject routes accordingly. The IDRP router adver-
`tises its view of the network with internal gateway pro-
`tocols such as Open Shortest Path First (OSPF) or
`Routing Information Protocol (RIP) so that all routers
`within the AS have a consistent view of the network.
`Just as ASs were used to refer to an entire set of IP net-
`works, IDRP supports a concept called routing confederations.
`A routing confederation is a grouping of ASs to make manag-
`ing the Internet more manageable. As the Internet has grown,
`the number of ASs has also grown, making its management
`less efficient. These routing confederations are quite flexible
`in that they can be subsets of and even overlap each other.
`IDRP uses path-vector routing to propagate routing infor-
`mation. Path-vector routing, as used in BGP, explicitly lists
`the entire path to each destination. This concept can alleviate
`network loops as well as enforce policy constraints based on
`the ASs or confederations that make up the path.
`Another feature supported in IDRP is the ability to reduce
`the number of path vectors by using route aggregation. Route
`aggregation lets an IDRP router combine multiple IP address
`prefixes or destinations to create a single advertisement for
`them all. This feature greatly reduces the number of individual
`destinations a router must support as well as reducing the
`amount of data that has to be sent during the advertising phase.
`Inter-Domain Policy Routing
`Steenstrup presents a set of protocols [14] and architecture in
`[15] for Inter-Doman Policy Routing (IDPR). Unlike BGP
`and IDRP, IDPR uses link state routing to provide policy
`routing among administrative domains (ADs).2 The primary
`objective of IDPR is to provide traffic with routes that satisfy
`the users’ service requirements while respecting the service
`providers’ service restrictions [16]. Source policies represent
`the users’ requirements and can consist of parameters such as
`throughput, acceptable delay, cost of session, and domains to
`avoid. Service providers specify transit policies, which specify
`offered services and the conditions of their use.
`The generation and selection of policy routes is based on
`distributed routing information and the source policies speci-
`fied by the domain administrator. IDPR forwards messages
`across paths established using the policy routes generated.
`Route generation is inherently complex and the most compu-
`tationally intensive part of IDPR. The general policy route
`generation problem involves a combination of service con-
`straints, for example, finding a route delay of no more than S
`seconds and a cost no greater than C. Most of these multicon-
`straint routing problems are NP-Complete.
`To reduce the size of the link state database, IDPR sup-
`ports the ability to group ADs into superdomains. The exis-
`tence of superdomains imposes a domain hierarchy within the
`network. With a hierarchical approach only domain-level
`information is needed to construct routes. This greatly
`
`■ Figure 2. A sample network diagram.
`
`reduces the information needed to be maintained by a route
`server. The size of the database will now depend on the num-
`ber of domains and the policies associated with each.
`A variant of Clark’s policy term was chosen to represent
`policies in [15]. This variant allows for policies to be associat-
`ed with a set of network elements that represents a path. A
`policy based on paths is a great asset to policy-based routing
`protocols.
`
`Network Policy Languages
`In this section all the major policy languages are discussed.
`These languages are used to represent varying types of net-
`work policies such as routing, access, and QoS.
`Clark’s Policy Term
`Seeing the importance of using network resources differently
`and more efficiently, Clark proposed a template to represent
`network policies [17]. This template, called a policy term, was
`designed to enable a wide range of network policies to be rep-
`resented. The work is based on the fundamental assumption
`that Internet resources are grouped into administrative
`regions (ARs). AR resources included such items as networks,
`links, routers, and gateways. The format of a policy term is
`shown in Fig. 1.
`The first two “elements” of the policy term represent the
`source and destination points, respectively. Each of these
`consists of three parts, which provide for a wide range of
`granularity while specifying the endpoints. To show the gran-
`ularity available with this schema, here are some examples of
`source and destination points that could be represented by
`the diagram in Fig. 2. These source and destination points
`use the special characters “*” and “-.” The “*” represents
`the wild-card match, and the “-” is used to make sure the
`AR entry or AR exit fields match the source AR or destina-
`tion AR, respectively. These examples could be applied to
`AR 2.
`
`(*, *, *) (*,*,*)
`No restrictions, allow all traffic flows to traverse without
`restriction.
`
`(*, 36, -) (*, 12,*)
`Allow all hosts directly attached to AR 36 to pass if their
`destination goes through AR 12 (e.g., host 131.120.1.13
`may communicate with 216.34.20.1).
`
`(131.120.1.13, 36, -) (216.32.74.53, 2, - )
`The host with IP address 131.120.1.13 in AR 36 may
`communicate with the host with IP address 216.32.74.53
`in AR 2.
`
`As the reader can see, the endpoints can be as explicit as
`specifying a host or generic enough to allow all Internet
`traffic. Although the use of these first two elements pro-
`
`2 Administrative domain refers to any collection of contiguous networks,
`gateways, links, and hosts governed by a single administrative authority
`who selects the intradomain routing procedures and addressing schemes,
`specifies service restrictions for transit traffic, and defines service require-
`ments for locally generated traffic.
`
`IEEE Network • January/February 2001
`
`13
`
`4
`
`

`

`Policy Framework Definition
`Language
`
`ComplexPolicy
`
`1 ..n
`
`SimplePolicy
`
`1 ..n
`
`PolicyRules
`
`PolicyConditions
`
`1 ..n
`
`ORed
`
`PolicyConditionList
`
`1 ..n
`
`ANDed
`
`PolicyConditionStatement
`
`PolicyConditionCategory
`
`PolicyConditionValue
`
`■ Figure 3. A PFDL hierarchy.
`
`PolicyActions
`
`1 ..n
`
`PolicyActionList
`
`1 ..n
`
`PolicyActionStatement
`
`PolicyActionCategory
`
`PolicyActionValue
`
`Strassner and Schliemier define the
`Policy Framework Definition Lan-
`guage (PFDL) [18] which provides a
`mapping of network service require-
`ments from a business specification
`to a vendor- and device-indepen-
`dent format. The benefit of such a
`language is that network policy can
`exist in a heterogeneous environ-
`ment of devices that support policy
`enforcement.
`With the development of stan-
`dards to provide QoS, like integrat-
`ed
`services with Resource
`Reservation Protocol (RSVP)3 and
`differentiated services, the IETF
`working group on Policy Manage-
`ment has proposed this language.
`The belief is that without a means
`of representing, administering, and
`distributing consistent policy infor-
`mation, these QoS standards that
`classify and give preferential treat-
`ment to certain types of traffic flows
`will not see widescale deployment.
`In this first release of the draft,
`the grammar was only available in
`Backus-Naur Form (BNF), and no explicit examples were pre-
`sented. Attributes the authors believe should be supported by
`the language are discussed. As with many of these efforts to
`represent policy, the authors believe that having a language
`which supports multiple network devices and vendors is the
`key to successful policy deployment.
`The design of PFDL is based on the Common Information
`Model (CIM) [2] being designed by the Distributed Manage-
`ment Task Force (DMTF). This model defines a hierarchy of
`object classes that can be used to represent policy information.
`The class and relationship hierarchy of the CIM model are
`used to help define the structure of the PFDL grammar, see
`Fig. 3. The basic premise is that a policy is an aggregation4 of
`policy rules. A policy rule defines a sequence of actions to be
`initiated when a corresponding set of conditions is satisfied.
`Five classes defined to support the CIM are the ComplexPoli-
`cy class, SimplePolicy class, PolicyRule class, PolicyCondition
`class, and PolicyAction class. Their relationship to each other
`is shown in Fig. 3.
`A PolicyRule contains a set of PolicyConditions and a set of
`PolicyActions. When the set of PolicyConditions are meet, the
`set of PolicyActions will be executed.
`A PolicyConditionStatement is composed of a category and
`value pair. These two components are specific to a particular
`knowledge domain, whether QoS, security, or any other
`domain. Providing conditions and actions for a given knowl-
`edge domain accommodates the interoperability requirement
`for the language. It will provide the means for multiple ven-
`dors to supply components to a general policy architecture.
`A PolicyAction is a class in the PFDL model that consists of
`
`vides for a flexible way to permit traffic flow, it can become
`cumbersome at times. If, for example, the reader wanted to
`allow only traffic from universities to flow across an AR, it
`could be accomplished by creating many policy terms, one
`for each university. This list of policy terms could become
`quite large, so the third “element” of the policy term, UCI,
`can be used to make the implementation of this policy
`more manageable. A policy term that would only allow uni-
`versity traffic to flow across an AR could be represented
`like this:
`
`((*,*,*), (*,*,*), University, *)
`The endpoints are such that if the UCI element was not
`used, all traffic would flow across the AR. Using the
`UCI as a filter, only traffic marked with a University tag
`would be permitted to pass.
`
`The last element field of the policy term, Cg, is used for
`global conditions. Examples of information that might be held
`in this field are, “unauthenticated UCI,” “no-per-packet
`charge,” and “limited to n% of available bandwidth.”
`
`((*,*,*),(*,*,*), University, {unauthenticated UCI})
`This would allow only traffic marked as University to flow
`through the AR. There is no need to verify that the packet
`traffic was really from a university host.
`
`Although this was a good start for an abstract network poli-
`cy representation, which is needed for heterogeneous environ-
`ments, it has limitations. There is no ability to represent
`explicit paths formed by a sequence of ARs as part of the
`term. Only single ARs and the wild card character “*” are
`allowed. Without this capability, support of Integrated Ser-
`vices requires several network policies distributed throughout
`the network to be combined for verification of a path. Conse-
`quently, there is no ability to exclude a set of ARs from a
`term to which a general policy is applied.
`
`3 RSVP defines how applications can place reservations, and how they can
`relinquish those resources once their need ends.
`
`4 An aggregation is a string form of an association. An aggregation is usu-
`ally used to represent a “whole-part” relationship.
`
`14
`
`IEEE Network • January/February 2001
`
`5
`
`

`

`AS1
`
`AS2
`
`AS3
`
`AS4
`
`AS5
`
`AS2
`CAT-NET
`Catatonic State University
`from AS1 accept ANY
`from AS3 accept <^AS3+$>
`to AS3 announce ANY
`to AS1 announce AS2 AS3
`AO36-RIPE
`CO19-RIPE
`OPS4-RIPE
`CO19-RIPE
`OPS4-RIPE
`orange@ripe.net
`RIPE
`
`aut-num:
`as-name:
`deser:
`import:
`import:
`export:
`export:
`admin-c:
`tech-c:
`mnt-by:
`tech-c:
`mnt-by:
`changed:
`source:
`
`■ Figure 4. An RPSL diagram and policy example.
`
`an action or a list of actions that will be executed when the
`conditions associated with a policy are evaluated to true.
`These actions can be executed in either a specific order or any
`order, which is the default. Along with the ordering of policy
`actions, the ability exists for the conditional execution of one
`or more actions based on the results of previous actions. The
`reader can see from Fig. 3 that the hierarchy of the PolicyAc-
`tions class is similar to the PolicyConditions class.
`With possibly hundreds, perhaps thousands, of policies to
`be supported in a network, the ability to detect conflicting
`policies is crucial. The authors of PFDL are aware of the need
`to both detect as well as support facilities to resolve conflicts.
`This proposal groups policy conflicts into two different cate-
`gories, intra- and interpolicy conflicts.
`Intrapolicy conflicts are caused when the conditions of at
`least two policies are simultaneously satisfied, but the execu-
`tion of the actions of these policies cannot be executed at the
`same time. Interpolicy conflicts are described as two or more
`policies that, when applied to the network, result in conflicting
`configuration commands specified for one or more network
`devices. In this case, the conflict exists when the policy is
`applied to a specific network or device(s). An example given
`in the proposal is when two policies are executed such that
`the number of queues in one network device is such that it
`does not match the number of queues allocated in a second
`device supporting the same traffic flow.
`Once conflicting policies are detected, they may be resolved
`in several different ways. The most obvious would be to modi-
`fy the conditions or actions of the policies to remove the con-
`flict. If this cannot be accomplished and the conflicting
`policies must exist in the system, there are three different
`ways to resolve them:
`• Resolve the conflict by only executing the first policy in the
`conflicting set.
`• Use a priority schem