Network Working Group A. Fessi
Internet-Draft University of Tuebingen
Expires: December 27, 2006 C. Kappler
C. Fan
Siemens AG
F. Dressler
University of Erlangen
A. Klenk
University of Tuebingen
June 25, 2006
Framework for Metering NSLP
<draft-fessi-nsis-m-nslp-framework-03.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Monitoring, metering and accounting of packets are increasingly
important functionalities that need to be provided in the Internet.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 1]
Internet-Draft M-NSLP Framework June 2006
This document motivates and describes a framework for the path-
coupled configuration of Metering Entities to record monitoring and
measurement data and report it to a data collector. Different
scenarios are described where such a path-coupled configuration is
useful. Currently, the focus is on two scenarios: accounting and QoS
measurement.
Moreover, this document gathers requirements for a path-coupled
configuration protocol of Metering Entities. Finally, the
applicability of the NSIS architecture for this purpose is discussed.
The protocol itself is specified in a separate document
[I-D.dressler-nsis-metering-nslp]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Scenario Description . . . . . . . . . . . . . . . . . 6
4.1.2. Required Configuration Parameters . . . . . . . . . . 8
4.2. QoS Monitoring . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Scenario Description . . . . . . . . . . . . . . . . . 10
4.2.2. Required Configuration Parameters . . . . . . . . . . 13
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. General requirements . . . . . . . . . . . . . . . . . . . 15
5.1.1. Extensibility . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Scalability . . . . . . . . . . . . . . . . . . . . . 15
5.1.3. Security . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Distinguishing flows . . . . . . . . . . . . . . . . . . . 15
5.3. Aggregation of Metering Records . . . . . . . . . . . . . 15
5.4. Transport of Metering Records . . . . . . . . . . . . . . 16
5.5. Location of Metering Entities . . . . . . . . . . . . . . 16
5.6. Location of the Collectors . . . . . . . . . . . . . . . . 16
5.7. Configuration protocol . . . . . . . . . . . . . . . . . . 16
5.7.1. Configuration of Metering Entities . . . . . . . . . . 16
5.7.2. Selection of Metering Entities . . . . . . . . . . . . 16
5.7.3. Metering Configuration State installation and
removal . . . . . . . . . . . . . . . . . . . . . . . 16
5.7.4. Initiation and maintenance of metering tasks . . . . . 17
5.7.5. Reaction to Route Changes . . . . . . . . . . . . . . 17
5.7.6. Coordination of Metering Entities . . . . . . . . . . 17
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 2]
Internet-Draft M-NSLP Framework June 2006
5.7.7. Scoping of configuration . . . . . . . . . . . . . . . 17
5.7.8. Collection of information on available Metering
Entities . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. Metering across domains . . . . . . . . . . . . . . . . . 18
6. Applicability of the NSIS Architecture . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Authorization Model . . . . . . . . . . . . . . . . . . . 18
7.2. Inter-working between different domains . . . . . . . . . 19
7.3. End User Privacy . . . . . . . . . . . . . . . . . . . . . 19
7.4. ISP Privacy . . . . . . . . . . . . . . . . . . . . . . . 19
7.5. Forged Collector . . . . . . . . . . . . . . . . . . . . . 19
7.6. Denial-of-Service Attacks on the Collector . . . . . . . . 20
7.7. Denial-of-Service Attacks on Metering Entities . . . . . . 20
7.8. Verification of the Flow Specification . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 3]
Internet-Draft M-NSLP Framework June 2006
1. Introduction
Monitoring, metering and accounting of packets is an important
functionality in many networks today. Several working groups are
working on mechanisms for collecting and reporting usage data, flow
or packet information. For example, the IPFIX (IP Flow Information
Export) Working Group defines a protocol to collect and report flow
information ([I-D.ietf-ipfix-protocol]). The PSAMP (Packet SAMPling)
Working Group focuses on reporting per packet information for further
processing ([I-D.ietf-psamp-framework]).
However, it is also necessary to configure and coordinate the
entities performing the metering. If one or more Metering Entities
should meter a specific flow, then all potential candidates for this
task are on the path followed by this particular flow. They can be
addressed by sending a configuration message along the path of the
flow. If more than one Metering Entity is required, all of them can
potentially be configured and coordinated with a single message along
the path.
The Metering Entities can either collect statistics on these flows,
perform packet sampling or apply some other special treatment for the
packets, for example, examining the packet payload, or just report
that this packet has passed this point. The Metering Entities can be
configured and can be coordinated to achieve a certain goal together,
which can be, for example, accounting or QoS monitoring.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Furthermore, this document uses the terms "Metering Record",
"Monitoring Probe", "Metering Entity", "Collector", as defined in
[I-D.dressler-nsis-metering-nslp].
3. Problem Statement
There is a need in industry and the Internet research community to
collect and export information on data flows. We call such
information Metering Records. Metering Records are useful in
mediation systems, accounting systems, and network management
systems. They facilitate services such as Internet research,
measurement, accounting, billing, QoS monitoring, intrusion
detection, and traffic profiling/engineering. In recognition of the
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 4]
Internet-Draft M-NSLP Framework June 2006
need for such metering the IPFIX WG was founded.
While the purpose for collecting Metering Records in each case is
different, the basic architecture of such metering systems is usually
identical, cf. Figure 1. Metering data is collected by a Monitoring
Probe. The Metering Entity produces Metering Records from the
metering data or additional data such as session information. The
Metering Entity transmits its Metering Records to a Collector. The
Collector correlates Metering Records relating to the same event from
different Metering Entities. There might be more than one Collector
depending on the actual tasks.
+-----------------+
| Collector |
| +-------------+ |
| | Met. Record | |
| +-------------+ |
+-----------------+
^ ^ ^ ^ ^
*** * ***
*** * ***
*** * ***
*** * ***
+-------------+ +-----------+ +-------------+
| Metering | | Metering | | Metering |
| Entity | | Entity | | Entity |
--->| |--->| |--->| |
|+----+ +----+| | +----+ | |+----+ +----+|
|| MP | | MP || | | MP | | || MP | | MP ||
|+----+ +----+| | +----+ | |+----+ +----+|
+-------------+ +-----------+ +-------------+
+----+ --- = Data Flow
| MP | = Monitoring
+----+ Probe *** = other Signaling
Messages
Figure 1: Schematic Metering Architecture
In this context two problems need to be solved:
o Metering Records need to be transported from the Metering Entities
to the Collector. IPFIX is, for example, a suitable protocol for
this task.
o The Metering Entities need to be configured and coordinated. This
document suggests path-coupled signaling for this purpose.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 5]
Internet-Draft M-NSLP Framework June 2006
In a flexible environment, it must be possible to dynamically
configure and coordinate Metering Entities rather than hardwiring
them. Configuration and coordination include, for example, which
entities peform the metering for a particular flow, providing
triggers to start or stop metering, distribution of identifiers for
the Collector to correlate Metering Records, and so forth. The IPFIX
WG has identified the needs for such configurations but has defined
the work currently as "out of the scope" [RFC3917]. The
configuration can be performed, for example, using RADIUS ([RFC2138])
or DIAMETER ([RFC3588]). The PSAMP (Packet Sampling) WG is also
currently developing a MIB module for configuring packet sampling
([I-D.ietf-psamp-mib]). Nevertheless, all these alternatives allow
only the configuration of single Metering Entities, and assume that
the location of the Metering Entities to be configured is known in
advance. Dynamic discovery, configuration and coordination of
distributed Metering Entities is not supported.
Since the most appropriate Metering Entities for metering a specific
flow are located along the path of the flow itself, a path-coupled
signaling protocol for distributing the configuration information
seems useful.
4. Scenarios
This section describes two different scenarios for the usage of path-
coupled configuration of Metering Entities: accounting and QoS
monitoring.
4.1. Accounting
4.1.1. Scenario Description
Flexible usage-based charging is mainly a problem in 3G mobile
telecommunication networks. With the advent of IP in these networks
and with 3GPP's All-IP perspective, there is also an increasing need
for IP technology to provide such functionality.
When starting an application session, for example, a video streaming,
usually there are several potential Metering Entities on the data
path, for example, the application server, the WLAN access point, the
ingress nodes of several transit networks or any router on the path
with metering functionality. These Metering Entities have different
capabilities. For example, routers along the path might be able to
account packets and packets sizes while the WLAN access point is able
to report the usage of the wireless link and whether the end host is
roaming. If content-based accounting is also required, the most
appropriate Metering Entity to perform this task will be the
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 6]
Internet-Draft M-NSLP Framework June 2006
Application Server.
An example of such a scenario is illustrated in Figure 2 where a data
receiver expects data from a data sender via two routers Router 1 and
Router 2. The application server (i.e., data sender) may or may not
(as in Figure 2) belong to the administrative domain.
+-------------------------+
Data Receiver | Router 1 Router 2 | Data Sender
+-----------+ | +-----+ +-----+ | +-----------+
| |<-----| |<----| |<----------|Application|
|Application| | |+---+| |+---+| | | +---+ |
| | | ||ME ||<===>||ME ||<=========>| |ME | |
+-----------+ | |+---+| |+---+| | | +---+ |
| +-----+ +-----+ | +-----------+
| Administrative Domain |
+-------------------------+
+---+
|ME | = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
Figure 2: Signaling to configure metering for accounting
As a prerequisite to charging, one or more Metering Entities collect
Metering Records independently for the same session. Existing
accounting concepts handle multiple Metering Entities by statically
configuring them [3GPP.32.260],[3GPP.32.251]. Some of those Metering
Entities always generate Metering Records, which will may be
discarded later. For example, in the case of a pure content charging
scheme, only the Metering Entity at the Data Sender (Application
Server) needs to perform metering. All other Metering Entities do
not need to perform any metering since their Metering Records will be
discarded anyway. Therefore, a flexible mechanism is required to
distribute this information to the Metering Entities along the path
and to find the appropriate Metering Entity on the path depending on
the charging scheme.
In the case where a mixed content and access charging should be
applied, not only the content accessed but also the data volume is
relevant for the metering process. In this case, the Metering Entity
at the Data Sender should be configured to account the content
accessed, and one of the other Metering Entities along the path, for
example, Router 1 or Router 2 must be configured to count bytes.
Furthermore, Metering Records need to be correlated at the Collector
in order to match them to the same session. In current accounting
concepts ([3GPP.32.260]), data correlation is performed by statically
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 7]
Internet-Draft M-NSLP Framework June 2006
configuring one of Metering Entities to generate a correlation ID,
and by manually configuring a chain of Metering Entities to which
this correlation ID is distributed. This is very inflexible and
leads to unnecessary overhead.
Using a path-coupled configuration protocol, this correlation ID can
be distributed at the configuration.
When a handover occurs ([3GPP.32.252]) other Metering Entities become
involved, for example the new WLAN access point. Metering Records
collected by the different Metering Entities needs to be correlated
and aggregated.
Furthermore, Metering Entities need to know to which Collector they
must send their Metering Records. This information can be also be
distributed dynamically during the signaling for configuration.
4.1.2. Required Configuration Parameters
In a client/server environment the Application Server (for example, a
video streaming server) acts as signaling initiator. It sends a
configuring request message towards the user terminal. The Metering
Entities along the path evaluate this message.
Given that the user terminal can not be seen as a trusted network
function, the signaling will travel until the last router before the
user terminal which might be, for instance, a WLAN access point.
This router acts as a signaling responder.
The parameters that need to be configured with the configuration
request message are the following:
Correlation ID
This parameter refers to an ID which is unique for each service.
It will be used by the Collector to assign different accounting
records to the same service.
Flow Specification
This parameter identifies the data flow(s) that need(s) to be
accounted. Here, the flow information from the NTLP can be used.
However, several entries SHOULD be possible for this parameter to
enable configuring the Metering Entities to perform accounting for
several flows (for instance audio and video) using a single
configuration message.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 8]
Internet-Draft M-NSLP Framework June 2006
Metered Objects
This parameter contains a list of the objects that need to be
accounted for the considered data flow.
* Flow Properties: These are dynamic properties of the data
stream to be metered:
+ number of observed packets of the flow
+ number of observed octets of the flow
+ timestamp of first observation of a packet of the flow.
+ timestamp of last observation of a packet of the flow.
Note that in the timestamps, the absolute time might be required
since the tariffs might depend on the time of the day.
Besides the metered objects above, the following objects may also
need to be recorded and reported to the Collector:
* Application events: service invocation, insertion of
advertisement and other application events.
* Mobility events: horizontal and vertical handovers.
* Bearer events: loss of bearer
* Access network type
* Report if the end host is roaming.
* Access network types: so the user can be charged differently
depending on the current access technology
* Different identities for the end host: e.g. Mobile Subsriber
ISDN Number(MSISDN)
* IP address of gateways, meters and other network elements
Reporting Interval
In order to reduce the number of export messages sent to the
Collector, it is advantageous not to send accounting data
immediately but to wait until the message is filled with a certain
amount of data. This parameter indicates the maximum time to wait
for more data until an exported data set is sent. Long living
flows are reported regularly in interval no longer than specified
by this parameter.
Flow Expiration Time
If no packets are observed for the specified amount of time
interval, the flow is considered as expired and it is reported.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 9]
Internet-Draft M-NSLP Framework June 2006
Collector ID
This parameter specifies where the accounting records need to be
sent to.
Reporting Protocol
This parameter specifies which protocol to use to report the
accounting data, for example, IPFIX, Diameter, Netflow5 or
Netflow9.
Selection of Metering Entities
This parameter determines how the Metering Entities that should
perform the accounting of the considered data flow are selected.
For the accounting scenario, possible options for this parameter
are:
* ANY: any Metering Entity on the path that is capable of
performing accounting with the requested objects in the
parameter "Metered Objects" should do it. In the extreme case,
this could be the signaling initiator itself.
* Enterprise-specific: Enterprises may wish to define their own
methods to decide which Metering Entities should perform the
metering. In this case, the parameter "Selection of Metering
Entities" needs to be combined with an enterprise-specific
identifier. (See also
http://www.iana.org/assignments/enterprise-numbers)
4.2. QoS Monitoring
4.2.1. Scenario Description
For a network user, it may be interesting at any time to check the
QoS for a certain service. The service of interest can be coarse
grained, for example, the QoS parameters provided by the link to the
edge router (access point) or fine grained, for example, the QoS
provided to a UDP data stream received from a video server. In any
case, the first step of analysis that the user can perform is
measuring the rates of sent and received traffic (including a
consideration of re-transmissions).
In such cases, local measurement is not sufficient. A next step of
analysis would be QoS measurement along the data path of the service
of interest. A measurement of packet bit rate, packet loss, jitter
and other QoS parameters at several points of the data path could
identify the cause of unsatisfactory QoS and locate where it is
caused.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 10]
Internet-Draft M-NSLP Framework June 2006
A similar, probably more important scenario is an ISP that detects
that the QoS it provides to a customer does not match the service
level agreement for this service. Then a measurement at several
locations along the data path of the service of interest would be
desirable for identifying the cause and location of QoS degradation.
Both cases described above (and a range of related cases) could be
solved by massive deployment of metering technology, for example, by
measuring all flows at all routers in the network. Then, in case of
a problem (or of a regular check) the information for a certain flow
of interest can be retrieved from the huge amount of collected
metering data. This approach is oversized, scales badly, and the
benefit gained is most likely not worth the investment and the
operational costs.
Configuring available Metering Entities on the data path appears to
be a more appropriate approach. In such a scenario, the requesting
party would configure some or all available Metering Entities along
the path of a service of interest in order to meter the particular
service and report the metered data.
Such configuration can be performed in a traditional way by
individually, one by one, configuring all Metering Entities. This
requires knowledge about the path taken by the service of interest,
knowledge about the available Metering Entities on this path and a
communication with each of them using an agreed (preferably
standardized) protocol.
The approach suggested by this document simplifies this task. By
using path-coupled configuration of traffic measurement, a requesting
party that is located on the path of interest does just need to send
a single configuration request along the path in order to communicate
with all available Metering Entities on this particular path.
Since different measurements are required for different QoS
parameters, the request sent along the path may vary. This is
illustrated by two example scenarios, one for packet loss metering
and one for delay metering.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 11]
Internet-Draft M-NSLP Framework June 2006
+-------------------------------------------------+
| |
| Administrative Domain |
| |
| ingress internal internal egress |
| node node 1 node 2 node |
+------+ | +-----+ +-----+ +-----+ +-----+ |
| host | | | |<====>| |<====>| |<====>| | |
| |---->| ME |----->| ME |----->| ME |----->| ME |---->
+------+ | +-----+ +-----+ +-----+ +-----+ |
| |
+-------------------------------------------------+
+---+
|ME | = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
Figure 3: Signaling to configure metering for QoS monitoring
Figure 3 shows a data stream passing a domain. Let's assume that at
the ingress node a problem with the data stream is detected and that
it wants to initiate traffic measurement for the data stream along
the path it takes through the domain. Then the ingress node sends a
signaling message along the path in order to configure available
Metering Entities.
If packet loss in the domain is the target of this investigation,
then all available Metering Entities on the path will be requested to
participate in the measurement. All will be requested to measure the
number of packets observed for the data stream of interest and to
report the results to either the requesting ingress node or to
another Collector of traffic metering data. Then the collected data
can be analyzed in order to identify locations in the domain where
packet loss occurs. Note here, that the Metering Entities need to
report their positions on the path to the Collector in order to
enable correct evaluation of the Metering Records.
In a similar way delay can be analyzed. Different to loss metering,
delay measurement requires per packet reporting from the Metering
Entities. For each observed packet belonging to the data stream of
interest, the Metering entity needs to report a hash value of the
packet header and a timestamp. In order to reduce the number of
reports, reporting can be restricted to a sampled set of packets.
Sampling algorithms are defined in [I-D.ietf-psamp-framework]. If
hash-based sampling is used, different Metering Entities along the
path will sample the same set of packets and report the time-stamped
hashvalues of these packet. Then the Collector can correlate the
Metering Records received from different Metering Entities and can
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 12]
Internet-Draft M-NSLP Framework June 2006
again analyze the sources of delay within the domain.
Note here that, as above, the Metering Entities need to report their
positions on the path to the Collector.
Note also that the sampling algorithm plays a key role in the
evaluation of the Metering Records. For example, if probabilistic
sampling is deployed, the Collector can not correlate Metering
Records from different Metering Entitiy, since they will most
probably contains information about unrelated packets.
If less detailed metering is required, for example, if loss and delay
only needs to be measured for the entire domain (and not hop by hop),
then not all Metering Entities need to participate. It is sufficient
if just the ingress and the egress node perform metering. Metering
at internal nodes is not required. Per-domain packet loss and per-
domain delay can be derived from packet counters and time stamped
packet hash values metered at ingress and egress nodes.
4.2.2. Required Configuration Parameters
Very similar to the accounting scenario in Section 4.1.2, the
signaling initiator sends a configuration request message along the
data path. The parameters that need to be configured are the
following:
Correlation ID
Similar to the accounting scenario, this is an ID that identifies
this measurement. It can be used by the Collector for identifying
incoming reports that belong to the same measurement.
Flow ID
Same as for the accounting scenario
Metered Objects
The objects to be measured:
1. Flow Properties: same as for the accounting scenario.
2. Packet Properties:
+ hash value
+ number of octets
+ time stamp
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 13]
Internet-Draft M-NSLP Framework June 2006
Packet Sampling Algorithm
If packet properties need to be reported, this parameter specified
which packet sampling to be used.
Reporting Interval
Same as for the accounting scenario
Flow Expiration Time
Same as for the accounting scenario
Collector ID
Same as for the accounting scenario
Reporting Protocol
Same as for the accounting scenario
Selection of Metering Entities
This parameter specifies the requirement for Metering Entities
along the data path. Among the required values for this parameter
are
* first: only the first available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling initiator itself.
* last: only the last available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling responder.
* all: all available Metering Entities on the path are requested
to perform metering.
* first and last: only the first and the last available Metering
Entities on the path are requested to perform metering.
5. Requirements
This section describes the requirements for a path-coupled signaling
for the configuration of Metering Entities. We assume existing
protocols or other means for transferring Metering Records from the
Metering Entities to Collectors.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 14]
Internet-Draft M-NSLP Framework June 2006
5.1. General requirements
5.1.1. Extensibility
The metering configuration protocol MUST support an extensible
metering model. Depending on the metering scenario, different
information must be exchanged between the Metering Entities.
The specification of the path-coupled metering configuration protocol
SHOULD be extensible to future technologies.
Moreover, the metering configuration protocol should bridge between
different existing metering solutions, for example, those defined in
3GPP. The communication may be organized using proxies.
5.1.2. Scalability
A Metering Entity needs to keep state and perform metering actions
for each accepted metering task. Handling high numbers of metering
tasks need to be provided by the Metering Entity implementation and
is not subject of a signaling protocol. However, the protocol design
should provide scalability for state keeping and refresh for a large
number of concurrent metering tasks.
5.1.3. Security
Security requirement of the path-coupled metering configuration
protocol are discussed in Section 7
5.2. Distinguishing flows
A primary capability of the metering function is the identification
of data packets belonging to different applications or users. The
configuration of the Metering Entities should take this parameter
into account. During the data flow life-time, statistics describing
the properties of this data flow are gathered and exported to a
Collector. The metering configuration should be flexible to allow
the description of multiple services and associated flows.
Flows belonging to one application: the metering configuration should
allow the aggregation of Metering Records for streams belonging to a
particular application, for example, a multimedia transmission with
associated data transfers (web pages).
5.3. Aggregation of Metering Records
The metering configuration SHOULD allow the aggregation of Metering
Records belonging to the same measurement or to the same applications
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 15]
Internet-Draft M-NSLP Framework June 2006
to reduce the data exported to the Collector.
5.4. Transport of Metering Records
The protocol for configuring Metering Entities MUST be independent of
the protocol used for transferring Metering Records. One possible
protocol is IPFIX [I-D.ietf-ipfix-protocol]. The IPFIX information
model ([I-D.ietf-ipfix-info]) is very flexible for extensions and,
therefore, adequate for this application.
5.5. Location of Metering Entities
The Metering Entities are located on the data path, i.e., on the path
of the data that should be metered. It is an open issue how the
initiator and receiver of the metering configuration signaling are
determined.
Metering Entities can be located anywhere along the data path, for
example, only in a subset of the path, or only at start and end point
etc.
5.6. Location of the Collectors
The Metering Records need to be transferred to one or eventually
several Collectors. The process of discovering which Collector is
interested in which Metering Records is out of scope. It is assumed
that the signaling initiator learns the location of the Collectors by
different means.
5.7. Configuration protocol
5.7.1. Configuration of Metering Entities
The protocol MUST be able to configure Metering Entities, for
example, to control which information needs to be collected and which
entities are allocated which task.
Protocol messages need to be interpreted only by Metering Entities.
5.7.2. Selection of Metering Entities
The protocol MUST provide functionality to select Metering Entities
that become part of a metering process by specifying, for example,
their type, position or total number.
5.7.3. Metering Configuration State installation and removal
The protocol MUST be able to install metering state and also to
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 16]
Internet-Draft M-NSLP Framework June 2006
remove it. Furthermore, metering state MUST be soft state in order
to cope with rerouting and device failure.
5.7.4. Initiation and maintenance of metering tasks
The protocol MUST be able to transport a trigger to start and stop
the collection of metering data, a correlation identifier that allows
the Collector to correlate Metering Records received from different
Metering Entities, and a trigger to send off Metering Records to the
Collector.
5.7.5. Reaction to Route Changes
The protocol MUST be able to react to rerouting of the packets that
are to be metered. Rerouting may imply including new Metering
Entities and removing others.
This requirement is important especially for the accounting scenario:
if routes change unnoticed the user will use the service for free.
5.7.6. Coordination of Metering Entities
The protocol MUST be able to configure and coordinate several
Metering Entities along the signaling path to gather and report
Metering Records belonging to the same session/measurement.
5.7.7. Scoping of configuration
The protocol MUST be able to scope messages. For example, the scope
could be the domain of an operator. Another important type of scope
is up to a particular type of Metering Entity. An example is a scope
that terminates a signaling message at the access router in order to
hide monitoring or charging configuration data from the user (and
also save resources on the air interface).
Another example is scoping the signaling, for example, at the
responsible UMTS GGSN because it is known that Metering Entities
beyond the GGSN are of no interest for this particular metering
configuration.
5.7.8. Collection of information on available Metering Entities
The protocol MAY support the collection of information on Metering
Entities and their capabilities without actually installing any
state.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 17]
Internet-Draft M-NSLP Framework June 2006
5.8. Metering across domains
Metering configuration SHOULD be possible across administrative
domains. There are challenging security aspects in this goal. (See
also Section 7)
6. Applicability of the NSIS Architecture
According to the NSIS framework [RFC4080], the NSIS protocol suite
can support various signaling applications that need to install or
manipulate state in NSIS-aware network nodes (NEs) along the path of
a data flow. The NSLP messages do not need to run all the way
between the data flow endpoints. Rather, the NSIS initiating NE and
the NSIS receiving NE can be located anywhere along the data path.
The problem of path-coupled signaling to configure Metering Entities
seems to be well suited to be solved with an NSIS signaling
application, the Metering NSLP. The Metering NSLP can run on top of
the NTLP similarly to the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the
NAT/Firewall NSLP [I-D.ietf-nsis-nslp-natfw]
The Metering NSLP needs to be able to install, modify and remove
metering configuration related state. Furthermore, signaling for
metering configuration needs the flexibility provided by NSIS to
start and end on arbitrary Metering Entities. Any Metering Entity on
the data path is able to initiate metering configuration signaling.
The selection of signaling initiator and receiver depends on the
configuration and on the specific application environment.
Finally, a Metering NSLP, similar to QoS NSLP, would be independent
of the actual configuration information it carries. Hence, it can be
used for any metering application.
7. Security Considerations
The process of configuring Metering Entities to start and stop
metering and to transmit collected Metering Records to a third party
introduces several security challenges. The following security
issues need to be considered for the design of the Metering NSLP.
7.1. Authorization Model
It MUST be assured that configuration messages for starting,
refreshing and stopping a metering configuration are correctly
authorized before the configuration is executed. Bogus configuration
messages can be used for different kind of attacks. For example, in
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 18]
Internet-Draft M-NSLP Framework June 2006
the accounting scenario if a malicious user is able to stop metering
of requested services then fraud is possible. Also, it MUST NOT
possible to configure Metering Entities in such a way that other
users are charged for the usage of a service which they have not
used.
7.2. Inter-working between different domains
Inter-working between multiple domains causes authorization problems.
If the scope of the configuration signaling should go beyond the
borders of a single domain, the ISPs need to be authorized to perform
metering configuration across other domains and to collect metering
and monitoring data. A high degree of trust is required to allow
other domains to configure Metering Entities and to collect the
metering data of particular users.
The above considerations raise the main question whether the Metering
NSLP can be used outside a single administrative domain. Ideally, it
should have a broader applicability but security, privacy and other
operational concerns may limit its applicability for multiple domain
traversal (and also end-to-end signaling).
7.3. End User Privacy
The collection of metering data about individual flows is a privacy
sensitive task. ISPs which intend to deploy the Metering NSLP may
need to clarify the legal terms for collecting and processing the
Metering Records.
7.4. ISP Privacy
This issue is relevant only for the case that the signaling for
metering configuration operates across several domains and Metering
Records might be delivered to a Collector belonging to a foreign
administrative domain. In this case, the Metering Records may reveal
sensitive topology information of the ISP network.
7.5. Forged Collector
It MUST be assured that the Collector that is specified in a
configuration message is eligible to receive the Metering Records.
Otherwise several kind of attacks are possible.
o As already mentioned in Section 7.3 and Section 7.4 if the
Metering Records are received by a bogus Collector, this will
reveal customer and/or ISP sensitive information
o In the accounting scenario the customer could cause the resource
usage data to be sent to a bogus Collector and therefore would be
able to use the services for free.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 19]
Internet-Draft M-NSLP Framework June 2006
7.6. Denial-of-Service Attacks on the Collector
In any application scenario for the Metering NSLP, it MUST be assured
that the Collector is supposed to receive the Metering Records.
Otherwise, a DoS attack (via amplification) would be possible if data
can be sent to an arbitrary IP address. The adversary needs to send
a single metering NSLP message in order to flood a victim with
potentially a huge amount of data over a certain, or perhaps
uncertain, period of time.
7.7. Denial-of-Service Attacks on Metering Entities
Metering Entities can be subject to DoS attacks if a large number of
Metering Data have to be collected or large per-flow states are
created.
7.8. Verification of the Flow Specification
The flow specification within a metering configuration message
(which, as mentioned above, may or may not be equal to the Message
Routing Information from the NTLP) needs to be verified for
integrity. In particular, it MUST be assured that an end host may be
able to trigger the collection of metering data by itself about a
flow that it created (this depends also on the application scenario)
but not for other flows that belong to other users. However, if
there is a signaling proxy that initiates the signaling on behalf of
other users, different authorization policies need to be deployed.
8. Contributors
This document is the result of the effort of a Metering NSLP team.
In addition to the individuals listed in the author list, the team
includes also Juergen Quittek and Hannes Tschofenig.
Furthermore, the authors would like to thank Ralph Kuehne for his
input on the description of the accounting scenario and Andreas
Pashalidis for his comments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.dressler-nsis-metering-nslp]
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 20]
Internet-Draft M-NSLP Framework June 2006
Dressler, F., "NSLP for Metering Configuration Signaling",
draft-dressler-nsis-metering-nslp-03 (work in progress),
October 2005.
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-09 (work in
progress), February 2006.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-22 (work in progress),
June 2006.
9.2. Informative References
[RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S.
Willens, "Remote Authentication Dial In User Service
(RADIUS)", RFC 2138, April 1997.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[I-D.ietf-ipfix-info]
Quittek, J., "Information Model for IP Flow Information
Export", draft-ietf-ipfix-info-12 (work in progress),
June 2006.
[I-D.ietf-nsis-qos-nslp]
Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-10 (work in progress),
March 2006.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in
progress), April 2006.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 21]
Internet-Draft M-NSLP Framework June 2006
[I-D.ietf-psamp-framework]
Duffield, N., "A Framework for Packet Selection and
Reporting", draft-ietf-psamp-framework-10 (work in
progress), January 2005.
[I-D.ietf-psamp-mib]
Dietz, T. and B. Claise, "Definitions of Managed Objects
for Packet Sampling", draft-ietf-psamp-mib-06 (work in
progress), June 2006.
[3GPP.32.240]
3GPP, "Telecommunication management; Charging management;
Charging architecture and principles", 3GPP TS 32.240
6.0.0.
[3GPP.32.260]
3GPP, "Telecommunication management; Charging management;
Charging architecture and principles; IP Multimedia
Subsystem (IMS) charging", 3GPP TS 3GPP.32.260.
[3GPP.32.251]
3GPP, "Telecommunication management; Charging management;
Packet Switched (PS) domain charging", 3GPP
TS 3GPP.32.251.
[3GPP.32.252]
3GPP, "Telecommunication management; Charging management;
Wireless Local Area Network (WLAN) charging", 3GPP
TS 3GPP.32.252.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 22]
Internet-Draft M-NSLP Framework June 2006
Authors' Addresses
Ali Fessi
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 72076
Germany
Phone: +49 7071 29-70534
Email: fessi@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Phone: +49 30 386-32894
Email: cornelia.kappler@siemens.com
Changpeng Fan
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Phone: +49 30 386-36361
Email: changpeng.fan@siemens.com
Falko Dressler
University of Erlangen
Department of Computer Science 7
Martensstr. 3
Erlangen 91058
Germany
Phone: +49 9131 85-27914
Email: dressler@informatik.uni-erlangen.de
URI: http://www7.informatik.uni-erlangen.de/
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 23]
Internet-Draft M-NSLP Framework June 2006
Andreas Klenk
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 72076
Germany
Phone: +49 7071 29-70535
Email: klenk@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 24]
Internet-Draft M-NSLP Framework June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-03.txt [Page 25]