PROTOTYPE IMPLEMENTATION OF A DEMAND DRIVEN NETWORK MONITORING ARCHITECTURE Augusto Ciuffoletti, Yari Marchetti INFN-CNAF ...
Summary  <ul><li>Intro (3 slides) </li></ul><ul><li>Architecture (11 slides) </li></ul><ul><li>Prototype (5 slides) </li><...
Network Monitoring  <ul><li>Accounting </li></ul><ul><li>Fault detection and QoS enforcement </li></ul><ul><li>User side m...
On demand network monitoring  <ul><li>Hardwired  monitoring exhibits serious issues: </li></ul><ul><ul><li>ignores user ne...
Hardwired monitoring On Demand Monitoring Monitoring sessions  <ul><li>A unique infrastructure regulates the activation of...
Produces a network monitoring request Transport infrastructure Passive monitoring effector Architecture layout Client Sens...
The Client <ul><li>Represents the entity that is interested in network monitoring results (e.g. a Workflow Manager) </li><...
The Sensor <ul><li>The component which is in charge of effecting the observations: located on a possibly specialized host,...
The Agent <ul><li>The basic component of the transport infrastructure </li></ul><ul><li>Two basic functionalities: </li></...
Security issues <ul><li>Traffic between Agents is  authenticated  using public keys certified by a CA, stored in the globa...
Domains <ul><li>A Domain is a set of Clients and Sensors that operate under control of one or more Agents  </li></ul><ul><...
Insight of a domain Sensor Client Sensor Sensor Client Agent Agent
<ul><li>Agents offer a  SOAP  interface to accept Requests </li></ul><ul><li>A Request is an  XML document  (a demo XSD ha...
Communication: Data streams <ul><li>A stream is implemented as a sequence of  UDP  packets (a single session may generate ...
<ul><li>It implements the  global state  of the infrastructure: </li></ul><ul><ul><li>Sensors  capabilities and managing a...
Request Ok! Example Agent A Client Global DB Agent B Sensor Performs Measuremens Submits a request Lookup Data stream
The prototype: targets <ul><li>To assess the feasibility of the whole design (complex, with many components) </li></ul><ul...
The prototype: methodology <ul><li>Select well known, well supported technologies to concentrate on real issues </li></ul>...
The prototype: a sample <ul><li>Agent (requests): </li></ul><ul><li>DB info retriever: transparent API to query the distri...
The prototype: the testbed
<ul><li>Request submission (approx. 2300 octets): </li></ul><ul><ul><li>TCP (280 octets) </li></ul></ul><ul><ul><li>SOAP (...
<ul><li>The infrastructure we have designed and prototyped is a step towards a network monitoring infrastructure for a Gri...
Upcoming SlideShare
Loading in...5
×

Prototype Implementation of a Demand Driven Network Monitoring Architecture

693
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
693
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Prototype Implementation of a Demand Driven Network Monitoring Architecture

  1. 1. PROTOTYPE IMPLEMENTATION OF A DEMAND DRIVEN NETWORK MONITORING ARCHITECTURE Augusto Ciuffoletti, Yari Marchetti INFN-CNAF (Italy) Antonis Papadogiannakis, Michalis Polychronakis FORTH (Greece)
  2. 2. Summary <ul><li>Intro (3 slides) </li></ul><ul><li>Architecture (11 slides) </li></ul><ul><li>Prototype (5 slides) </li></ul>
  3. 3. Network Monitoring <ul><li>Accounting </li></ul><ul><li>Fault detection and QoS enforcement </li></ul><ul><li>User side monitoring </li></ul><ul><li>How To? </li></ul><ul><ul><li>Dedicated tools </li></ul></ul><ul><ul><li>Timed measurements </li></ul></ul><ul><ul><li>Pre-scheduled sessions </li></ul></ul><ul><li>Presently mostly addressing admin usage </li></ul>
  4. 4. On demand network monitoring <ul><li>Hardwired monitoring exhibits serious issues: </li></ul><ul><ul><li>ignores user needs </li></ul></ul><ul><ul><li>quadratic growth with system size (data, computation and traffic) </li></ul></ul><ul><li>On demand network monitoring: </li></ul><ul><ul><li>suits user needs (timing and modality) </li></ul></ul><ul><ul><li>grows linearly with system load </li></ul></ul><ul><ul><li>security management simplified </li></ul></ul><ul><ul><li>observation rendered at once </li></ul></ul>
  5. 5. Hardwired monitoring On Demand Monitoring Monitoring sessions <ul><li>A unique infrastructure regulates the activation of monitoring sessions </li></ul><ul><li>Distinct agents implement distinct functionalities </li></ul>Network Monitoring Client Agent Sensor
  6. 6. Produces a network monitoring request Transport infrastructure Passive monitoring effector Architecture layout Client Sensor Agent Network monitoring takes place here
  7. 7. The Client <ul><li>Represents the entity that is interested in network monitoring results (e.g. a Workflow Manager) </li></ul><ul><li>Submits a request to an agent specifying, traffic description (e.g. endpoints, ports), and the expected results </li></ul><ul><li>Expectation includes traffic description (e.g. endpoints, ports), syntax (e.g. precision), semantics (e.g. tool name), metadata (e.g. max bandwidth) </li></ul><ul><li>Requests are submitted to a “well known” local Agent </li></ul>
  8. 8. The Sensor <ul><li>The component which is in charge of effecting the observations: located on a possibly specialized host, uses passive monitoring techniques </li></ul><ul><li>Receives monitoring request from the client, delivered by a “well known” local Agent, containing the specs of the traffic to monitor, and expected results </li></ul><ul><li>Configures traffic filters and formats response packets </li></ul><ul><li>Packets containing observations are delivered at once , embedded into a UDP stream </li></ul>
  9. 9. The Agent <ul><li>The basic component of the transport infrastructure </li></ul><ul><li>Two basic functionalities: </li></ul><ul><ul><li>Routes requests from Clients to Sensors </li></ul></ul><ul><ul><li>Maintains streams from Sensors to Clients </li></ul></ul><ul><li>Routes are computed using a global database representing the partitioning of the system into domains </li></ul><ul><li>Clients and Sensors are aware of Agents located in the same domain </li></ul>
  10. 10. Security issues <ul><li>Traffic between Agents is authenticated using public keys certified by a CA, stored in the global database </li></ul><ul><li>Authentication is needed to avoid spoofing, encryption seems unnecessary in most cases </li></ul><ul><li>Traffic between Agents and Sensors or Clients is authenticated using public keys managed using criteria local to the Domain </li></ul><ul><li>Response payload may be encrypted according to criteria negotiated between the Client and the Sensor </li></ul>
  11. 11. Domains <ul><li>A Domain is a set of Clients and Sensors that operate under control of one or more Agents </li></ul><ul><li>A hierarchical arrangement of domains seems pointless </li></ul><ul><li>Domains composition is recorded in a global database </li></ul><ul><li>The global database can be implemented using LDAP or DNS (a hyperscalable gossip based solution is under study) </li></ul>Dom Σ Dom Δ Dom Ψ Dom Ω
  12. 12. Insight of a domain Sensor Client Sensor Sensor Client Agent Agent
  13. 13. <ul><li>Agents offer a SOAP interface to accept Requests </li></ul><ul><li>A Request is an XML document (a demo XSD has been produced) divided into two parts: </li></ul><ul><ul><li>an envelope which is modified en route by the Agents (per hop authentication , route record) </li></ul></ul><ul><ul><li>a session description , which is delivered untouched to the Sensor (traffic description, expected results) </li></ul></ul>Communication: Requests
  14. 14. Communication: Data streams <ul><li>A stream is implemented as a sequence of UDP packets (a single session may generate several streams) </li></ul><ul><li>Packet loss events entail detectable unavailability of some observations </li></ul><ul><li>Route is determined using request route records, plus some immediate shortcut recipes </li></ul><ul><li>Payload may be encrypted if network observations are considered sensitive information </li></ul><ul><li>Multicast is in principle possible </li></ul>
  15. 15. <ul><li>It implements the global state of the infrastructure: </li></ul><ul><ul><li>Sensors capabilities and managing agent </li></ul></ul><ul><ul><li>Agents public key </li></ul></ul><ul><li>We envision a distributed implementation: </li></ul><ul><ul><li>each agent has access to a local proxy with part of the whole database </li></ul></ul><ul><ul><li>requests out of the cache and updates are propagated </li></ul></ul><ul><ul><li>implemented in LDAP (prototype) </li></ul></ul>The global database
  16. 16. Request Ok! Example Agent A Client Global DB Agent B Sensor Performs Measuremens Submits a request Lookup Data stream
  17. 17. The prototype: targets <ul><li>To assess the feasibility of the whole design (complex, with many components) </li></ul><ul><li>To identify existing techniques to implement the various functionalities </li></ul><ul><li>To layout exhaustively the design of the proposal </li></ul><ul><li>To assess the integration between the work of the two partners </li></ul><ul><li>NON TARGETS : demonstration of scalability, performance, user satisfaction. </li></ul>
  18. 18. The prototype: methodology <ul><li>Select well known, well supported technologies to concentrate on real issues </li></ul><ul><li>Cleanly modularize the design to obtain a usable layout </li></ul><ul><li>Make the prototype fully portable to support cooperation between partners </li></ul><ul><li>OUR OPTIONS : </li></ul><ul><li>Java for the language, SOAP and UDP for communication, LDAP for the database and virtualize the testbed (NETKIT) </li></ul>
  19. 19. The prototype: a sample <ul><li>Agent (requests): </li></ul><ul><li>DB info retriever: transparent API to query the distributed database </li></ul><ul><li>Request/Response Proxy: effects routing </li></ul><ul><li>Local request Manager: interacts with Sensors </li></ul><ul><li>Softstate: records requests and controls routing </li></ul>
  20. 20. The prototype: the testbed
  21. 21. <ul><li>Request submission (approx. 2300 octets): </li></ul><ul><ul><li>TCP (280 octets) </li></ul></ul><ul><ul><li>SOAP (420 octets) </li></ul></ul><ul><ul><li>envelope+signature (700 octets) </li></ul></ul><ul><ul><li>session description (approx. 900 octets) </li></ul></ul><ul><li>Data stream packet (approx. 120 octets+payload) </li></ul><ul><ul><li>IP+UDP headers (28 octets) </li></ul></ul><ul><ul><li>stream management (approx. 20 octets) </li></ul></ul><ul><ul><li>signature (64 octets) </li></ul></ul>Profiling protocol overhead
  22. 22. <ul><li>The infrastructure we have designed and prototyped is a step towards a network monitoring infrastructure for a Grid environment in the Internet scale </li></ul><ul><li>To achieve the target, we opted for an on demand approach, specially suited for a Grid environment </li></ul><ul><li>There is no experience with on demand monitoring, although the technology is ready </li></ul><ul><li>The implementation of the prototype was carried out as a Master thesis by Yari Marchetti, who later joined the research group, in three months </li></ul>Conclusions
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×