1. Packet Capture Questions and considerations Henrik Wessing JRA2 Task 4
DTU / Nordunet
JRA2 T4 meeting, Poznan
30th of November, 2016

2. Overall architecture and starting point: Monitoring MD VPN
L2VPNs –Point-to-Point tunnelling
L3VPNs (IPv4/IPv6) – Private IP networks
VPLS –Virtual Private LAN Service
Network To The Lab (tunneling to the labs)

3. Initial questions?
What exactly do we need to monitor and who request this?
Should monitoring information be used for:
NREN/GEANT operation?
End user for immediate verification of link?
Documentation for long term validation of SLA?
Parameters
Delay, jittr, packet loss ratio
Resolution: nsec, usec or msec.
Average and burst throughput
Granularity
All packets (header and fingerprint) captured or just a subset
How much to capture for a statistical acceptable result.

4. Active or passive probing
Active Probing:
Allows for inserting timestamped traffic wherever needed
Will impact overall bandwidth of flow
Monitoring packets should have exactly same priority
Should use ”insignificant” bandwidth
Passive Probing:
Capture, identify and timestamp customer traffic several places in network.
Identification in multitechnology environment complex and will probably need hashing
Hybrid
Active probes in customer domain
Well defined packets to identify and capture

5. Granularity Monitoring per interface or higher order flows
Interface bandwidth
Hardware solutions probably required for 10G and 100G+ flows
Napatech solutions ?
Which information can be provided from current hardware to the capture implementations?
Per customer flow:
Software based solution

6. Passive mode packet identification
Capture all or subset of packets
Utilise MPLS/VLAN header if possible
Utilise TCP/UDP sequence number if available
Or use IP Payload fingerprint (also if e.g. IPSec or fragments IPSec)
Capture all and subset of e.g. hashes could be used to reduce traffic to aggregator.

7. Active mode packet identification
Special type packets/frames can be inserted for easy identification and capture. IP header type could be used.
Packets timestamped at the insertion probe
Jitter and delay calculated locally
Max/min/avg. delay and packet count forwarded to aggregator.
Discussion:
Can the simpler identification justify the impact on the channel
Is it relevant to compare overhead from collector to aggrgator traffic with overhead from inband monitoring?
By not capturing and processing customer data, do we have a better security story to tell?

8. Packet capture implementations
Hardware or software
Platform
Are we just supporting Linux?
Implementationof software
C variants
Java
Python
Other choices
What can we learn for WiFiMon (GN4-1 SA3)