Download PPT Version

Path-coupled Meter Configuration
<draft-fessi-nsis-m-nslp-framework-00.txt >
<draft-dressler-nsis-metering-nslp-01.txt>
Georg Carle, Falko Dressler, Changpeng Fan, Ali Fessi,
Cornelia Kappler, Andreas Klenk, Juergen Quittek, Hannes Tschofenig
64th IETF meeting, PSAMP WG
IETF 64 PSAMP WG
1
Motivation
Problem: Measuring properties of a specific IP traffic flow along its
path through the Internet

identifying sources of delay, jitter and loss
 delay and jitter per hop
 number of dropped packets per hop
 at several routers
 in several domains
Domain 1
IETF 64 PSAMP WG
Domain 2
Domain 3
Domain 4
2
Already Known Solutions (1)
Active measurements: traceroute and ping

does not measure the flow of interest but another artificial flow
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 64 PSAMP WG
Domain 2
Domain 3
Domain 4
3
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 64 PSAMP WG
Domain 2
Domain 3
Domain 4
4
Path-coupled signaling
Sending signaling message along the data path



same basic idea as RSVP uses for QoS signaling
each router on the path receives a request for measuring a specified data flow
non-supportive routers just ignore the message
Data collection to



(a) per-domain databases
(b) case-by-case-specified database
(c) along data path back to requesting party
(a)
Domain 1
(a)
Domain 2
Domain 3
(a)
Domain 4
(c)
(b)
IETF 64 PSAMP WG
5
Example: Intra-domain Measurement
Ne
Nc
Ni
(pID,tk)c
(pID,tk)i
(pID,tk)e
Web access
signaling
traffic of interest
IETF 64 PSAMP WG
collector
6
Advantages
MPe
Topology and routing information not required

automatically only routers on the data path are
configured
 reduced measurements overhead
Relatively low signaling overhead
Filter specification allows exact measurement of
specific traffic flow
MPk
MPi

even at high speed link, measurement without
sampling possible
 also precise loss and jitter measurement
possible
 lower probability of packet ID collisions
 further increases by also reporting packet
length
Low amount of data to be stored in database
Measuring byte loss and packet loss
(pID,tk,Mj)e
(pID,tk,Mj)i
collector
Wasteful reporting traffic
Traffic being correctly measured
Traffic being observed but not measured
IETF 64 PSAMP WG
7
Current Activities

2 Internet Drafts:

“Framework for Metering NSLP” (New I-D)
 <draft-fessi-nsis-m-nslp-framework-02.txt >
 Presents shortly the whole context of Metering and Measurement
 Presents different scenarios for path-coupled configuration of MEs
 Collects requirements for a path-coupled configuration protocol of MEs
 Discusses the applicability of NSIS for this purpose

“NSLP for Metering Configuration Signaling”
 <draft-dressler-nsis-metering-nslp-03.txt>
 Protocol Design
 M-Spec

Prototype already implemented.

Team increased to 8 people from 4 organizations
IETF 64 PSAMP WG
8
Overall Status

Two documents


“Framework for Metering NSLP”
<draft-fessi-nsis-m-nslp-framework-02.txt >
“NSLP for Metering Configuration Signaling”
<draft-dressler-nsis-metering-nslp-03.txt>

Framework document has its first full version
 Protocol document is still in progress
 Metering NSLP will be presented in the PSAMP WG
session
 First prototype implementation of the Metering NSLP is
running at the University of Tuebingen
 Using the GIST implementation from University of
Goettingen
IETF 64 PSAMP WG
9
Summary of Changes in the Drafts
since Last Versions (1)

First full version of the framework document
Problem statement of “path-coupled” measurement and metering
 Application scenarios
 Requirements:
 General requirements
 Security requirements



Reviews and Comments are very welcome!
Particularly, we are looking for comments on the usage scenarios:

Accounting
 QoS Monitoring
 Monitoring for Network Security

Which of them do you consider to be
{ important | useful | irrelevant | nonsense } ?
IETF 64 PSAMP WG
10
Summary of Changes in the Drafts
since Last Versions (2)

M-NSLP protocol document is still progressing




Protocol operation and message processing rules are currently
discussed
Metering Specification (MSPEC) is currently being refined
High level state machine
Interaction with GIST
IETF 64 PSAMP WG
11
MSPEC Issues

MSPEC consists of

<Flow Specification>
 Problem: How should the flow specification be related to the MRI?
 Discussion somehow related to the packet classifier QSPEC discussion on
the mailing list
 How can the flow spec be expressed?
– In the current version of the M-NSLP, we use the IPFIX information model

<Measured Properties>
 e.g. number of bytes, timestamps
 <Measured Properties> are expressed using the IPFIX and PSAMP
information model.
 An extension of the IPFIX information model may be required
 <Measurement Configuration Parameters>
 e.g. Export Protocol, Export Interval, Collector ID, Aggregation Rules,
encryptionRequired, etc.
IETF 64 PSAMP WG
12
Next Steps

Continue the specification

of the M-NSLP protocol operation
 and the MSPEC



Refine state machine
Elaborate security solutions
Continue prototype implementation
IETF 64 PSAMP WG
13
Shall this become a
(NSIS) WG work item?
IETF 64 PSAMP WG
14