IETF 662 Outline Overall Status Changes since last version M-NSLP Functionality Overview Outlined with some examples Next Steps
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
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!
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!
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
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
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.
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
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
IETF 6611 Next Steps Continue the protocol specification Work on open issues Issue Tracker is available online Elaborate security solutions Continue prototype implementation
IETF 6612 Thanks for your attention. Questions?
IETF 6613 Backup Slides
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
IETF 6615 State Machine M-NSLP Session State Machine is quite simple
IETF 6616 Metering NSLP in a Metering Entity
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
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
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
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