GN2-JRA1 - APAN Meeting
Download
Report
Transcript GN2-JRA1 - APAN Meeting
GN2-JRA1 Performance
Monitoring
Nicolas Simar, Network Engineer
12/01/2005 Brussels
DANTE
Agenda
•
•
•
•
GN2-JRA1 Objectives
Activity Update
Next Steps
General Framework Overview
Objectives
• Multi-domain Network Performance Measurement
Management Platform
–
–
Retrieve network information from several domains
Through a pre-defined interface
• Modify and Improve measurement tools.
–
tests performed to determine how fast some aspect of a
system performs under a particular workload
• Covers network information such as delay, packet loss, “traceroute”,
achievable TCP throughput, etc
• Build visualisation tools to suit some users needs.
Objectives (2)
User Interface
User Interface 1
User Interface 2
Domain
Controllers
Domain Controller domain A
Domain Controller domain B
Domain Controller domain C
Measurement
Points
Domain A
Available Bandwidth
Measurement Points
Domain B
One-way delay
Measurement Points
type 1
Domain C
One-way delay
Measurement Points
type 2
Deprecated view of the infrastructure
Agenda
•
•
•
•
GN2-JRA1 Objectives
Activity Update
Next Steps
General Framework Overview
GÉANT2-JRA1 Activities
• Requirements
– Three questionnaires were written targeting: the NRENs, the projects
and the end-users.
– Goal: get an overview of
• the existing monitoring infrastructure (metric, tools used)
• the visualisation of the data
• the need to access monitoring information from other networks.
– 45 answers were received in total (respectively 16, 14, 15)
• Strong interest to access monitoring information form multiple network.
– NRENs: less than 5-10% of the problems they are encountering
involves several domains ( => times 30 NRENs). They want to see
improved the capability of localising the problems.
– International projects want to have a view on what’s happening
between their sites (uses: troubleshooting, SLA and internal decision
making).
– End-user: less important than for NRENs or projects (uses:
troubleshooting, service verification)
GÉANT2-JRA1 Activities
• Readiness to open access to measurement data
– Some ready to show everything (or nearly so)
– Some want to apply restriction (about what and to
who)
– Some don’t want to
• Monitoring Information:
– RTT and OWD
– bandwidth utilisation and achievable TCP throughput
– RTT and OWD packet loss
– Delay variation
– Interfaces error and drops
– Routing/path information
• On-demand capability (to and from other domains)
GÉANT2-JRA1 Activities
• Be able to monitor the services deployed
– IPv4/IPv6
– Multicast/unicast
– IP QoS
– VPN/point-to-point connections
– Emulate behavior close from the one from the
application used
• Different tools used amongst the networks, need to
abstract the data provided from the type of measurement
tools used.
– Provide data through a well define interface.
– Inter-operability between tools.
GÉANT2-JRA1 Activities
• Keep in mind: installation and maintenance!
• Had a look at existing tools and went more in depth for the
most interesting ones.
• We have chosen so far the following tools:
– OWD: DFN IPPM
– Throughput: iperf based
– Flow monitoring: flowtool
– Visualisation: CNM
– Pending: Packet capture tool (SW: scampi - tbc, HW:
Endace or scampi - further work needed), other
visualisation
Agenda
•
•
•
•
GN2-JRA1 Objectives
Activity Update
Next Steps
General Framework Overview
GÉANT2-JRA1 Activities
• Current actions
– General Framework Design v1 (mid-February)
– Prototype (June-July 05)
– Work on measurement concatenation (now ->
September)
– Buy equipment and install it.
• Next steps
– AA (discussion with JRA5)
• Which model to follow?
• Authorisation based on groups (NOC, PERT, projectA,
user). How to have easy agreement between domains?
(don’t want to negotiate an agreement with all the US
universities or with all the European NRENs)
– Detailed design of the modules v1 (September 05)
– Trial phase (November 05-December05)
Agenda
•
•
•
•
GN2-JRA1 Objectives
Activity Update
Next Steps
General Framework Overview
Architecture Refinement
• Strong collaboration between Internet2 PAT and GN2JRA1 (meetings and conf-calls).
• Best way to have our framework inter-operable is to build
a common one.
• Review of existing systems
– Insights based upon Abilene prototype framework,
DANTE’s perfmonit and IPPM experiences
• New insights gained from inter-domain framework test
experience (lightpath measurements, Abilene/ESnet, etc)
• Additional use cases and experience of collaborators
– Internet2, GÉANT2 JRA1, GGF NMWG
Architecture Proposal
• Services Oriented Architecture
– In a simple scenario, each domain consists of
a set of services. All services are well defined
and independent
– Services within a domain represent the
domain with the help of Authentication and
Authorization – they respond to requests only
if the Authentication service of the domain
has authenticated the user and the policy of
the given service authorizes it
Basic Services
•
•
•
•
•
•
Lookup
Authentication
Measurement Point
Measurement Archive
Resource Protector (Authorization)
Aggregation
– Topology
Lookup Service
• Initial discovery
– Multicast / Anycast
– Well known servers
– Required servers (by administrative
configuration)
– Previously detected servers (organized in a
P2P network – lookup services find out about
other lookup services…
Lookup Service (II)
• Lookup is not simply by name
–Type (type of measurement, type of service)
–Community
–Network path (proximity information from Topology)
–Organization
–Type of authentication required
–Other…
• Response contains
–Contact information
–Available services
–Authentication required
–Other…
Authentication
• Registers with lookup
• Client requests “kind” of authentication token based
lookup results
• Authentication grants time-limited token used to request
service
• Protocol for determining “role/identity” for request. (Shib:
federated trust)
–Allow new measurement points to be created as
easily as possible
–Allow new data consumers access as easily as
possible
Measurement Point
• Service to wrap measurement tools
• Interacts with resource protectors to protect
shared resources
• Registers with lookup service and specifies the
authentication credentials required to interact
• Registers with lookup service to indicate types of
tests it can perform
• Accepts requests for tests
Measurement Archive
• Subscribes to some set of data – either from a
measurement point or from an aggregation
service
• May publish the derived data sets
Resource Protector
• Enables centralizing of resource allocation (not globally this is within spheres of administrative control)
• Multiple measurement points interact with a given
resource protector to limit the shared resources
• Resource protectors can be chained hierarchically to
control aggregations of shared resources across larger
frameworks.
Topology
• Network topology information is necessary for
measurement system optimization
• Creates overviews/”maps” to illustrate network
• Layered approach (domain level through to wavelengths
and physical level)
• Specific type of aggregation (translation)
–Collects raw data from measurement points and pushes
topology information into the lookup service (allows
topologically based queries to lookup service)
Aggregation (Translation)
• Data translation service (pipelines data between other
components in the framework)
• Subscribes and Publishes data
• Provides:
– Aggregation
– Correlation
– Caching
– Duplication
– Translation
• Event generation
• Data analysis
Process Flow (Client)
• Discovery.
– Find lookup servers.
– Use lookup servers to find tool beacons for a given problem. (On
correct path, with acceptable authentication requirements, with
acceptable tools/measurements.).
• Authentication.
– Authenticate to correct auth servers that are needed for desired
test executors.
• Test execution.
– Implement subscriber to accept results.
– Make test requests presenting credentials and reference to
subscriber interface for returned data.