Progress Report: Metering NSLP (M-NSLP) 66th IETF meeting, NSIS WG.
-
Upload
molly-judson -
Category
Documents
-
view
218 -
download
1
Transcript of Progress Report: Metering NSLP (M-NSLP) 66th IETF meeting, NSIS WG.
<draft-fessi-nsis-m-nslp-framework-03.txt ><draft-dressler-nsis-metering-nslp-04.txt>
Progress Report:Metering NSLP (M-NSLP)
66th IETF meeting, NSIS WG
IETF 66 2
Outline
• Overall Status• Changes since last version• M-NSLP Functionality Overview
Outlined with some examples
• Next Steps
IETF 66 3
Overall Status
• Two documents updated “Framework for Metering NSLP”
<draft-fessi-nsis-m-nslp-framework-03.txt >
“NSLP for Metering Configuration Signaling”<draft-dressler-nsis-metering-nslp-04.txt>
• 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 66 4
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 66 5
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 66 6
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 66 7
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
MNF1 MNF2 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
Not Participating
Participating with
MSPEC M2
IETF 66 8
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 list5: Since the MSPEC objects list has become empty, MNF2 stops the
signaling and acts as a responder for this session from now on.
IETF 66 9
M-NSLP Functionality: ‘Selection of MNEs’ is ‘ALL’
Traffic of interest
NSIS SignalingMetering Records
MNI
MNF1 MNF2 MNR
CONFIG(M1)
CONFIG (M1)
RESPONSE()
RESPONSE()
Collector
CONFIG (M1)
RESPONSE()
- All the MNEs on the signaling path participate in the metering process
IETF 66 10
M-NSLP Functionality: ‘Selection of MNEs’ is ‘First and Last’
Traffic of interest
NSIS SignalingMetering Records
MNI
MNF1 MNF2 MNR
CONFIG(M1)
CONFIG (M1)
RESPONSE()
RESPONSE()
Collector
CONFIG (M1)
RESPONSE()
- Only the ‘First’ and the ‘Last’ Nodes in the domain participate in the metering process
IETF 66 11
Next Steps
• Continue the protocol specification• Work on open issues
Issue Tracker is available onlinehttp://www.ri.uni-tuebingen.de/cgi-bin/roundup.cgi/mnslp/
• Elaborate security solutions• Continue prototype implementation
IETF 66 12
Thanks for your attention.Questions?
IETF 66 13
Backup Slides
IETF 66 14
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 66 15
State Machine
• M-NSLP Session State Machine is quite simple
IETF 66 16
Metering NSLP in a Metering Entity
IETF 66 17
Motivation for the Metering NSLP
• Problem: Metering properties of a specific IP traffic flow along its path
• Different purposes for metering a data flow1. Accounting
configuring Metering Entities along the path dynamically and distributing a Correlation ID
2. Measuring QoS parameters e.g. delay, jitter, packet loss rate, etc.
Domain 1 Domain 2 Domain 3 Domain 4
IETF 66 18
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 1 Domain 2 Domain 3 Domain 4
IETF 66 19
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 1 Domain 2 Domain 3 Domain 4
IETF 66 20
MNE
MNE
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