1. IETF 64 PSAMP WG1 Path-coupled Meter Configuration Georg Carle, Falko Dressler, Changpeng Fan, Ali Fessi, Cornelia Kappler, Andreas Klenk, Juergen Quittek, Hannes Tschofenig 64th IETF meeting, PSAMP WG

2. IETF 64 PSAMP WG2 Motivation Problem: Measuring properties of a specific IP traffic flow along its path through the Internet  identifying sources of delay, jitter and loss n delay and jitter per hop n number of dropped packets per hop  at several routers  in several domains Domain 1Domain 2Domain 3 Domain 4

3. IETF 64 PSAMP WG3 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 n overloading core routers n huge amount of data to be transported, stored and searched Domain 1Domain 2Domain 3 Domain 4

4. IETF 64 PSAMP WG4 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 1Domain 2Domain 3 Domain 4

5. IETF 64 PSAMP WG5 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 Domain 1Domain 2Domain 3 Domain 4 (c) (a) (b)

6. IETF 64 PSAMP WG6 (pID,t k ) i NiNi NeNe NcNc (pID,t k ) e collector signaling traffic of interest (pID,t k ) c Web access Example: Intra-domain Measurement

7. IETF 64 PSAMP WG7 Advantages 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  even at high speed link, measurement without sampling possible n also precise loss and jitter measurement possible  lower probability of packet ID collisions n further increases by also reporting packet length Low amount of data to be stored in database Measuring byte loss and packet loss MP i MP e MP k collector (pID,t k,M j ) i (pID,t k,M j ) e Wasteful reporting traffic Traffic being correctly measured Traffic being observed but not measured

8. IETF 64 PSAMP WG8 Current Activities  2 Internet Drafts:  “Framework for Metering NSLP” (New I-D) n Presents shortly the whole context of Metering and Measurement n Presents different scenarios for path-coupled configuration of MEs n Collects requirements for a path-coupled configuration protocol of MEs Discusses the applicability of NSIS for this purpose  “NSLP for Metering Configuration Signaling” n Protocol Design n M-Spec  Prototype already implemented.  Team increased to 8 people from 4 organizations

9. IETF 64 PSAMP WG9 Overall Status  Two documents  “Framework for Metering NSLP”  “NSLP for Metering Configuration Signaling”  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

10. IETF 64 PSAMP WG10 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: n General requirements n 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 } ?

11. IETF 64 PSAMP WG11 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

12. IETF 64 PSAMP WG12 MSPEC Issues  MSPEC consists of  n Problem: How should the flow specification be related to the MRI? n Discussion somehow related to the packet classifier QSPEC discussion on the mailing list n How can the flow spec be expressed? –In the current version of the M-NSLP, we use the IPFIX information model  n e.g. number of bytes, timestamps n are expressed using the IPFIX and PSAMP information model. n An extension of the IPFIX information model may be required  n e.g. Export Protocol, Export Interval, Collector ID, Aggregation Rules, encryptionRequired, etc.

13. IETF 64 PSAMP WG13 Next Steps  Continue the specification  of the M-NSLP protocol operation  and the MSPEC  Refine state machine  Elaborate security solutions  Continue prototype implementation

14. IETF 64 PSAMP WG14 Shall this become a (NSIS) WG work item?