1. Progress Report: Metering NSLP (M-NSLP) 66th IETF meeting, NSIS WG

2. IETF 662 Outline Overall Status Changes since last version M-NSLP Functionality Overview  Outlined with some examples Next Steps

3. IETF 663 Overall Status Two documents updated  “Framework for Metering NSLP”  “NSLP for Metering Configuration Signaling” Framework document is stable Protocol document is still in progress Metering NSLP has been presented in the IPFIX/PSAMP WG with a positive feedback Prototype implementation is progressing at the University of Tuebingen Using the GIST implementation from Univ. Goettingen

4. IETF 664 Summary of Changes in Framework Draft since Last Version Framework document is stable  It includes  Problem statement of “path-coupled” measurement and metering  Application scenarios  Requirements: General requirements Security requirements  NSIS Applicability Statement for “path-coupled” metering Application scenarios include  Accounting  QoS measurement Intrusion Detection scenario has been removed after an extensive discussion among the authors!

5. IETF 665 Summary of Changes in Protocol Draft since Last Version M-NSLP protocol document is still progressing M-NSLP objects and message processing are more detailed State machine is more refined (but is still quite simple! ) More examples of operation are provided First bit-level specification Metering Specification (MSPEC) encoding is re-used from other protocols, e.g. IPFIX or Diameter We try to keep the protocol as simple as possible!

6. IETF 666 Metering Configuration (MSPEC) Semantic & Encoding M-NSLP does not define its own language for the configuration of Metering Entities M-NSLP re-uses the semantic and encoding of other protocols, e.g.  IPFIX,  Netflow version 9  Diameter  Less error-prone  Supports different metering and exporting technologies

7. IETF 667 M-NSLP Functionality: ‘Selection of MNEs’ is ‘ANY’(1) Traffic of interest NSIS Signaling Another protocol signaling, e.g. IPFIX or Diameter Metering Records MNI MNF1MNF2 MNR 2: CONFIG(M2) 3: CONFIG (M2) 4: RESPONSE() 5: RESPONSE() Collector 1: Configuration request from a local application at the MNI with MSPEC objects M1 and M2 Participating with MSPEC M1 Not Participating Participating with MSPEC M2

8. IETF 668 M-NSLP Functionality: ‘Selection of MNEs’ is ‘ANY’(2) -The MSPEC objects (metering tasks) can be allocated to different MNEs along the path 1: MNI receives a “configuration request” from a local application with MSPEC objects M1 and M2 2: MNI is able to meter M1. It removes M1 from the MSPEC objects list and initiates the signaling towards MNR 3: MNF1 is not able to meter M2. It just forwards the signaling towards MNR 4: MNF2 is able to meter M2. It removes M2 from the MSPEC objects list 5: Since the MSPEC objects list has become empty, MNF2 stops the signaling and acts as a responder for this session from now on.

9. IETF 669 M-NSLP Functionality: ‘Selection of MNEs’ is ‘ALL’ Traffic of interest NSIS Signaling Metering Records MNI MNF1MNF2MNR CONFIG(M1) RESPONSE() Collector CONFIG (M1) RESPONSE() -All the MNEs on the signaling path participate in the metering process

10. IETF 6610 M-NSLP Functionality: ‘Selection of MNEs’ is ‘First and Last’ Traffic of interest NSIS Signaling Metering Records MNI MNF1MNF2MNR CONFIG(M1) RESPONSE() Collector CONFIG (M1) RESPONSE() -Only the ‘First’ and the ‘Last’ Nodes in the domain participate in the metering process

11. IETF 6611 Next Steps Continue the protocol specification Work on open issues  Issue Tracker is available online http://www.ri.uni-tuebingen.de/cgi-bin/roundup.cgi/mnslp/ Elaborate security solutions Continue prototype implementation

12. IETF 6612 Thanks for your attention. Questions?

13. IETF 6613 Backup Slides

14. IETF 6614 M-NSLP Objects and Messages M-NSLP Objects  Message Sequence Number (MSN)  Selection of Metering Entities (MNE_Selection)  Session Lifetime (Session_LT)  Information Code (INFO)  MSPEC Objects  which are dependant on the metering technology  IPFIX MSPEC Objects, Diameter MSPEC Objects, etc. M-NSLP Messages  CONFIGURE  REFRESH  RESPONSE  NOTIFY

15. IETF 6615 State Machine M-NSLP Session State Machine is quite simple

16. IETF 6616 Metering NSLP in a Metering Entity

17. IETF 6617 Motivation for the Metering NSLP Problem: Metering properties of a specific IP traffic flow along its path Different purposes for metering a data flow  Accounting  configuring Metering Entities along the path dynamically and distributing a Correlation ID  Measuring QoS parameters  e.g. delay, jitter, packet loss rate, etc. Domain 1Domain 2Domain 3 Domain 4

18. IETF 6618 Already Known Solutions (1) Massive metering: meter 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 1Domain 2Domain 3 Domain 4

19. IETF 6619 Already Known Solutions (2) Selective metering: 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

20. IETF 6620 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