Transcript PPT Version

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
IETF 63 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
IETF 63 NSIS WG
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
IETF 63 NSIS WG
3
Basic Protocol Design

Example of Operation
MNI

MNR
MNE
MNE
RESPONSE
CONFIGURE
CONFIGURE
CONFIGURE
RESPONSE
RESPONSE
Message Types:


CONFIGURE
REFRESH
– reduced refresh: without MSPEC
– used also to inspect the state of the MNEs


RESPONSE
NOTIFY
IETF 63 NSIS WG
4
Some interesting Design Decisions (1)
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
IETF 63 NSIS WG
5
Some interesting Design Decisions (2)
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>
M-NSLP
processing
GIST
processing
IETF 63 NSIS WG
MSPEC
Metering
Manager
Monitoring
Probe
6
Next Steps





Finalize framework document
Continue the specification of the protocol
Refine state machine
Further analysis of security requirements
Continue prototype implementation
IETF 63 NSIS WG
7
Thanks for your attention.
Questions?
IETF 63 NSIS WG
8
Motivation

Problem: Metering properties of a specific IP traffic flow along its
path

Different purposes for metering a data flow
1. Accounting

configuring Metering Entities along the path dynamically and
distributing a Correlation ID
2. Measuring QoS parameters

e.g. delay, jitter, packet loss rate, etc.
3. Monitoring for network security
Domain 1
IETF 63 NSIS WG
Domain 2
Domain 3
Domain 4
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 1
IETF 63 NSIS WG
Domain 2
Domain 3
Domain 4
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 1
IETF 63 NSIS WG
Domain 2
Domain 3
Domain 4
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!
MNE
Metering NSLP
MNE
MNE
NSIS signaling
traffic of interest
collector
IETF 63 NSIS WG
12
Model of Operation
IETF 63 NSIS WG
13