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

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

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

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

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)

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

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

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

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

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 } ?

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

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.

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

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