47th IETF 3/29/00 Information Model for describing network policy and services John Strassner - Cisco Walter Weiss - Lucent Andrea Westerinen - SNIA David Durham - Intel

47th IETF 3/29/00 Policy Layers Administrator-defined: device- and mechanism-independent IF User is Subscribed to Gold Service, THEN Allow use of NetMeeting and provide premium data services Device-independent policy rules If SourceIPAddress == /15, THEN Mark Voice with EF and Data with AF11 Device-independent, mechanism-dependent policy configuration take three forms... –configure component so it can be used to condition forwarded traffic –configure component so it can act on traffic directly –trigger action based on network or system event (e.g., link failure) … And perform a set of device-dependent actions: –configure classifier –configure filter and bind to classifier

47th IETF 3/29/00 Info Model vs. Device policies Mechanism-independent, info model policy is based on packet arrival: –If SourcePort == 80 Then qpSetDSCPvalue = 12 Mechanism-dependent, QoS Device policies based on configuration model: –If TRUE Then HttpClassifier.SourcePort = 80 HttpMarker.DSCP = 12 Classifier.NextTCBElement = HttpMarker

47th IETF 3/29/00 Implications Mechanism-independent policies do not ensure interoperability between devices –If a single policy server controls devices with different implementations of the same QoS mechanisms (e.g., droppers), then these devices will interpret policy differently unless there is common device information model –This is exacerbated when multiple policy servers are present

47th IETF 3/29/00 Implications (2) Mechanism-independent policies do not ensure interoperability between policy servers –Different policy servers can interpret high level info model policies differently for droppers (i.e., WRED, FRED, Tail, etc.) or schedulers (i.e., CBQ, PQ, WRR, etc.) –This means that mechanism-dependent policies are necessary to define dropper and scheduler class details.

47th IETF 3/29/00 Class Hierarchy Hierarchy specifies: –“Generic” classes higher in the structure –Subclassing to more specific services/classes –Product specific subclasses at the bottom Inheritance and abstraction of common attributes Allows specification/differentiation of peer services

47th IETF 3/29/00 Class Hierarchy Example

47th IETF 3/29/00 Class Associations Specify relationships between QoS mechanisms and services –Component, binding and dependency relationships Examples –QoSSubService: Construction of QoSService from more specific sub-services such as DiffServ and 802 –QoSTCBSubService: Binding of DSCPs or 1Q priorities to TCBs –NextTCBElement: Sequencing of TCB sub- services

47th IETF 3/29/00 Capabilities Determine the run-time characteristics and capabilities of a particular device or scoped aggregation of devices At run-time, instances of capabilities classes specify: –Supported Classes –Supported Attributes/Properties within a class –Run-time constraints on the applicable values of a particular class, attribute, or relationship

47th IETF 3/29/00 Examples of Capabilities Determine classes/attributes: –Device 1 supports classifier class A and action classes B & C –Device 2 supports only DSCP (behavior aggregate) attribute in classifier class Determine run-time constraints: –Device 1 supports ranges in Class A’s port range attribute between & –Device 2 supports enumerations in Class D’s security algorithms (MD5 and SHA1) Scoped groupings of devices –Take the intersection of all capabilities of all devices within the defined group

47th IETF 3/29/00 QoS Device Model Overview QoSService –conceptualizes QoS as a set of coordinated mechanisms –enables administratively-defined rules to be mapped to QoS mechanisms –describes how sub-services, such as TCBs, are used to construct QoS services such as Gold or High Availability service

47th IETF 3/29/00 Types of QoS Services DiffServService –Binds DSCPs to TCBs in order to construct a DiffServ service 8021PService –Binds 1Q priority values to TCBs in order to construct 802 service semantics Gold Service –An instance of QoSService that could use services like the ones above to specify a customized QoS definition (called Gold)

47th IETF 3/29/00 Modeling Forwarding of Traffic PacketScheduler, BufferManager and TCB work together to govern traffic flow TCB coordinates application of components to condition traffic –Classifier, Marker, Meter, Dropper and Queue are services that can be glued together