RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 1 High-Level Interface to the Traffic Flow Measurement Architecture Jürgen Quittek C&C Research Laboratories NEC Europe Ltd. Heidelberg, Germany Marcelo Pias Department of Computer Science University College London UK draft-quittek-rtfm-generic-interface-00.txt

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 2 Outline o Motivation åProblems with RTFM architecture åApplication Scenarios o Requirements o Approach o Interface Description (so far) o Open Issues

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 3 Motivation o The interface for flow measurements defined by the RTFM architecture and offered by the Meter MIB is powerful. o However, it is not always really easy to use åinteraction between manager, reader, and meter årule set specifications are procedurally defined åwriting rule sets is a non-trivial task åmeter delivers measured traffic data in pull mode only o Several management applications require less functionality, and they would benefit from a simpler interface.

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 4 RTFM Architecture Manager Meter Control (basic settings, rule sets, registration) Data (Pull Mode) User / Application Reader

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 5 Rule Sets o Single rule: & = :, ;  Actions: Ignore, NoMatch, Count, CountPkt, Return, GoSub, GoSubAct, Assign, AssignAct, Goto, GotoAct, PushRuleTo, PushRuleToAct, PushPktTo, PushPktToAct o Format statement o Statistics statement o Example SET 13 RULES SourcePeerType & 255 = IP: PushtoAct, IP_pkt; Null & 0 = 0: Ignore, 0; # IP_pkt: # Tally IP traffic by (Class C) subnet SourcePeerAddress & = 0: PushPktToAct, Next; DestPeerAddress & = 0: CountPkt, 0; # FORMAT FlowRuleSet FlowIndex FirstTime " " SourcePeerType SourcePeerAddress DestPeerAddress " " SourceTransType SourceTransAddress DestTransAddress " " ToPDUs FromPDUs " " ToOctets FromOctets;

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 6 RTFM Architecture Applications There are two typical kinds of applications: 1Plain (standalone) traffic measurement applications åwell supported by architecture åhigh flexibility in rule definition åRule files written manually or in SRL åTraffic data is read in pull mode åmetered data stored for further processing 2Applications with integrated traffic measurement åtypically less low-level metering functionality required åautomatic rule set generation åpush mode for traffic data may be desirable ågathering of traffic data for immediate processing

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 7 Meter Customer ATariff Translator Service Provider Customer BTariff Translator Meter 1.Tariff Multicast 2. Tariff 3. Meter Policies 4. Control (Rule Set) 3. Meter Policies 4. Control (Rule Set) 5. Data (Pull Mode) 6. Data (unicast) 5. Data (Push Mode) 6. Data (unicast) Accounting and Charging for QoS

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 8 Steps (1) Service Provider multicasts Tariffs to accounting modules of his Customers (2, 3) The Customer accounting module loads a module called Tariff Translator in order to create Meter Policies from the Tariff. (4) The Meter Policies are transformed to Meter specific control (e.g. RTFM Rule Set) (5, 6) The metering/accounting data is collected either using: - Pull Mode or Proactive - Push Mode or Reactive

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 9 Policy Server Network Node PEP PDP May use LDAP, SNMP, … for accessing policy database, authentication, etc. May monitor the network o Policy server according to policy framework RFC 2753 o May require current overall traffic and current individual traffic information in order to decide on admission control, QoS assignments, and traffic engineering actions.

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 10 Requirements for Application Type 2 o Control traffic measurement on a high level of abstraction o Abstraction from details of RTFM architecture as high as possible åSimplification of model åSimplification of meter policies (rule sets) o Abstraction as low a necessary in order to provide the functionality required by different kinds of applications åAccounting åQoS monitoring å... o Gathering traffic data in pull and push mode

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 11 Application RTFM Interface RTFM Architecture Control (Meter Policies) Data (Pull or Push Mode) Control (Rule Set) Data (Pull Mode) Approach

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 12 Interface Design o 5 Groups of data structures and functions åFlow Attribute åFlow Description åManager åReader åMeter o Trade of simplicity against functionality RTFM Interface: group usage graph Flow Attribute Flow Description Meter ReaderManager RTFM Interface: group usage graph Flow Description Meter ReaderManager

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 13 Flow Attribute o Attribute Value Pair o Data structure åAttribute type according to RFC 2722 and RFC 2724 åAttribute value o Funtions ånone

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 14 Flow Description o Declarative specification instead of procedural rule sets o Data structure åsourceIPAddress ådestinationIPAddress åsourceMask number of significant bits & treatment of wildcards ådestinationMask number of significant bits & treatment of wildcards åtransportType set of predefined numbers åsourcePort ådestinationPort ådirection independent, forward, backward åfurtherAttributeSet set of Flow Attributes o No functions o Open question: Would just an attribute set be sufficient?

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 15 Manager o Data Structure åMeter(s) ( set of) meter to be used å... o Functions åmeasureFlow returns Reader flowDescription Meter Policy flowAttributes Set of attributes to be reported meter meter to be used firstTimeInterpretation absolute, relative, relative-incremental collectTimeInterval polling interval for flow data å...

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 16 Reader o Data Structure åempty (so far) o Functions ågetFlowData ågetFlowDescription(s) ågetMeter(s) åInstallFlowDataListener åRemoveFlowDataListener å... o Open issue: One Reader per Flow Description?

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 17 Meter o Just specifying location and access to Meter o Data Structure åIPAddress åport åcommunity (user) / credentials o Functions ånone o Open Issue: åglobal Meter settings

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 18 Plan for RTFM High-Level Interface o Complete interface requirements and specification draft until March 2001 o Decision on mapping to (protocol, API, MIB, none) in March 2001 o First version of (Protocol, API, MIB) until August 2001 o Implementation and final versions in 2001

RTFM2 BOF 49th IETF Meeting San Diego, CA December 2000 slide 19 Open Issues o Is the interface description style appropriate? o Should Flow Attributes also contain attribute masks? o Flow Description: Just a set of Flow Attributes? o One Reader per Flow Description? o How to implement the specification? åMIB module? åMeter MIB extension? åa new protocol? åan API? o Is this an appropriate issue for an RTFM2 WG ?