IETF 63 NSIS WG 1

Progress Report:Metering NSLP (M-NSLP)

63th IETF meeting, NSIS WG

<draft-fessi-nsis-m-nslp-framework-01.txt ><draft-dressler-nsis-metering-nslp-02.txt>

IETF 63 NSIS WG 2

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 3

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 4

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

MNI MNECONFIGURE

MNECONFIGURE

MNRCONFIGURE

RESPONSERESPONSERESPONSE

IETF 63 NSIS WG 5

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 6

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

GISTprocessing

MeteringManager

MonitoringProbe

MSPEC

IETF 63 NSIS WG 7

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 8

Thanks for your attention.

Questions?

IETF 63 NSIS WG 9

Motivation

Problem: Metering properties of a specific IP traffic flow along its path

Different purposes for metering a data flow1. 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 Domain 2 Domain 3 Domain 4

IETF 63 NSIS WG 10

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 Domain 2 Domain 3 Domain 4

IETF 63 NSIS WG 11

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 Domain 2 Domain 3 Domain 4

IETF 63 NSIS WG 12

MNE

MNE

MNE

collector

NSIS signaling

traffic of interest

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

IETF 63 NSIS WG 13

Model of Operation