130 likes | 253 Views
Progress Report: Metering NSLP (M-NSLP). <draft-fessi-nsis-m-nslp-framework-01.txt > < draft-dressler-nsis-metering-nslp-02.txt>. 63th IETF meeting, NSIS WG. Overall Status. 2 documents “Framework for Metering NSLP” <draft-fessi-nsis-m-nslp-framework-01.txt >
E N D
Progress Report:Metering NSLP (M-NSLP) <draft-fessi-nsis-m-nslp-framework-01.txt ><draft-dressler-nsis-metering-nslp-02.txt> 63th IETF meeting, NSIS WG 1
Overall Status • 2 documents • “Framework for Metering NSLP” • <draft-fessi-nsis-m-nslp-framework-01.txt > • “NSLP for Metering Configuration Signaling” <draft-dressler-nsis-metering-nslp-02.txt> • a M-NSLP team of about 8 people from 4 organizations • Contacted IPFIX and PSAMP WG • Started prototype development • Using the GIST (GIMPS) implementation from Göttingen 2
Summary of Changes in the Drafts since Last Versions • Framework document • Updated scenarios • M-NSLP protocol document • First version of protocol design • Revised Message Types • Included message processing rules • Designed high level state machine • Defined M-NSLP objects • Introduced Metering Specification (MSPEC) • Interaction with GIST (GIMPS) • Investigated security issues, which will help to design an authentication and authorization scheme for the M-NSLP 3
Basic Protocol Design • Example of Operation • Message Types: • CONFIGURE • REFRESH • reduced refresh: without MSPEC • used also to inspect the state of the MNEs • RESPONSE • NOTIFY MNR CONFIGURE MNI MNE MNE CONFIGURE CONFIGURE RESPONSE RESPONSE RESPONSE 4
Some interesting Design Decisions (1) • Selection of MNEs • Only a subset of the MNEs on the path will take part of the actual metering process, e.g. • ANY • FIRST and LAST • ALL • MNEs that are not taking part of the metering should store minimal or zero state information • However, NTLP state is required in order to avoid GIST (GIMPS) re-discovering the MNEs with D-Mode 5
Some interesting Design Decisions (2) • Separate between: • M-NSLP control parameters • the configuration information itself: MSPEC • Flexible information model • <MSPEC> = <Filters> <Metered Objects> <Correlation-Id> <Collector-Id> <FlowExpirationTime> <ExportPeriod> <Sampling-Alg-Id> <Sampling-Params> <Hash function> • <Metered Objects> = <Number-of-Packets Flag> <Number-of-Octets Flag> <Timestamp-Begin Flag> <Timestamp-End Flag> MSPEC M-NSLP processing Metering Manager Monitoring Probe GIST processing 6
Next Steps • Finalize framework document • Continue the specification of the protocol • Refine state machine • Further analysis of security requirements • Continue prototype implementation 7
Thanks for your attention. • Questions? 8
Motivation • Problem: Metering properties of a specific IP traffic flow along its path • Different purposes for metering a data flow • Accounting • configuring Metering Entities along the path dynamically and distributing a Correlation ID • Measuring QoS parameters • e.g. delay, jitter, packet loss rate, etc. • Monitoring for network security Domain 4 Domain 1 Domain 2 Domain 3 9
Already Known Solutions (1) • Massive passive measurement: measure all flows in the network at all routers in all domains • very high overhead • overloading core routers • huge amount of data to be transported, stored and searched Domain 4 Domain 1 Domain 2 Domain 3 10
Already Known Solutions (2) • Selective passive measurement: configure measurement for the flow individually by a management tool • much leaner, much less data • central coordination of individual measurements • full topology and routing information required for coordination • still a high management and coordination overhead Domain 4 Domain 1 Domain 2 Domain 3 11
Our Solution: the Metering NSLP • Appropriate Metering Entities to meter a given data flow are located on the data path! • Use path-coupled signaling to discover them dynamically and configure them! • Metering NSLP MNE MNE MNE NSIS signaling traffic of interest collector 12