Deliverable 4 “Architecture Components and Interactions”

Deliverable 4“Architecture Components and Interactions” INTERMON Project Review Brussels March 2003

INTERMON Project • Goals: • to enhance the inter-domain QoS and traffic analysis in large-scale, multi-domain Internet infrastructures • to collect, process and present (in an automatic fashion) information about • Network topology • Traffic • Quality of Service • SLA fulfillment • Instruments: • Visual Data Mining techniques • Analytical models and Simulations based on measurement • Distributed information base • Topology and Measurement tools

Extended INTERMON Architecture • Due to the sensitive and costly nature of data stored in the INTERMON databases, the basic INTERMON architecture has been extended with a set of new components which aim at providing a controlled access to such data, in the form of services • Monitoring services for QoS and traffic • Inter-domain topology discovery • Inter-domain modelling and simulation • Visual Data Mining with algorithms for traffic matrices and spatio-temporal QoS analysis • Starting from the semantic description of Intermon architecture functionality stated in previous deliverables we deployed a new design deliverable (D4) in order to address the following topics: • Scalability • Reliability • Security

Deliverable 4 • It is an intermediate outcome of work done in WP3 (Specification of integrated inter-domain QoS analysis architecture) • It states the current view of the INTERMON architecture useful for next steps in both implementation and integration phases • It reflects latest advances in work done by other WPs • It is mainly focused on components roles and interfaces without providing technical details

Deliverable 4 – cont’d • It explains and extends the previous INTERMON architecture (which is included in the new one) in its interfaces, interactions and roles so to make it more scalable, manageable and understandable • The new architecture can actually be considered as a general framework which allows to deploy an ever more complete monitoring activity • Three main components: • Global Controller (coarse grained data) • Local Controller (fine grained data) • Tool Manager (tool specific data) • A new document to exchange monitoring information: Service Level Indication (SLI)

+ + Visual Data Mining Client GUI + Global Controller GC-GC interaction User-GC interaction Another GC Document Repository Task Processing AAA Report Management Naming Service Global DB GC-GDB interaction Simulation Data Post Processing Tool Manager Local Controller Tool Configuration Data Collection Task Processing LC-LDB interaction Local DB + + + Topology Detector Active Meter Passive Meter Tools

Global Controller (GC) • Each Autonomous System (AS) is represented by a (logically unique) Global Controller which provides the monitoring related services • A service involving several ASs could be provided by exchanging data among the respective GCs through a well defined INTERMON interface • By doing this, several issues could be addressed: • scalability: a number of GC instances can share the overall workload thus leading to better system response time • reliability: a big GC, which provides monitoring service for several ASs, represents a single point of failure for a large number of users. If it crashes, all of the ASs loose their GC functionality • security: by using a GC for each AS, it is easier to control what information is allowed to be shared with the other ASs • a smaller GC is easier to be implemented than a bigger one

Local Controller (LC) • The Local Controller is the intermediate component of the INTERMON architecture • Within a given AS one or more Local Controllers may exist: • Different technology “islands” • Geographically spread networks • Load balancing • Replication

ISP2 ISP1 ISP3 Example of ISP’s federation International links Wholesale AS (ISPs’ Federation) GC LC Corporate Customers Customers

Inter-domain data exchange Client GUI GC1 GC2 LC1.1 LC1.2 AAA + Service_rqst Rqst_acceptance Request splitting Data_request Data_request Data_request Result_data Result_data Result_data Service_completed

Tool Manager (TM) • Each TM is responsible for a set of homogeneous tools: • Passive meters (IPFIX, MonRes) • Active meters (CM Toolset) • Topology discovery (BGP-4) • Main functionalities • Remote control of tool by mean of proper tool-specific client (optional: wrapping) • Data adaptation and storing in the INTERMON database

Global Controller GC-GC interaction User-GC interaction Global DB (coarse grain) Task Processing Report Management Local DB (fine grain) GC-GDB interaction CM Toolset IM-DB Local Controller Task Processing LC-LDB interaction Topology Traces

Tool Manager Tool Configuration Data Collection + + + BGP-4 Topology Detector CM Toolset Active Meter IPFIX, MonRes Passive Meter Tools

Document Repository • It stores XML documents resulting from a service request • Useful to: • Intermediate data storage (before VDM) • Accounting and billing • Inter-domain data exchange • Based upon an XML database • Server: XINDICE • Query language: XPATH (W3C)

Service Level Indication (SLI) • A new document schema especially suited for monitoring activity • Contains monitoring information with different abstraction levels • Useful in both intra-domain and inter-domain scenarios • Is produced with the cooperation of all of the distributed components in order to obtain a detailed picture aboutthe currently offered level of service

SLI – cont’d • Four documents with different abstraction levels: • Local SLI: contains detailed information about resource utilization provided by a single Local Controller • Global SLI: summarizes information provided by several LCs within an AS. Useful to data exchange in an inter-domain scenario • Template SLI: contains information about what data have to be collected and how to present them to the user • User SLI: the final document forwarded to the user

Deliverable 4 “Architecture Components and Interactions”