Network Working Group F. Dressler
Internet-Draft University of Erlangen
Expires: January 21, 2006 A. Fessi
G. Carle
University of Tuebingen
J. Quittek
NEC
C. Kappler
H. Tschofenig
Siemens AG
July 20, 2005
NSLP for Metering Configuration Signaling
<draft-dressler-nsis-metering-nslp-02.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 January 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Monitoring, metering and accounting of packets are increasingly
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 1]
Internet-Draft Metering NSLP July 2005
important functionality that needs to be provided in the Internet.
This document proposes the definition of a new NSIS Signaling Layer
Protocol (NSLP), named Metering NSLP, which allows the dynamic
configuration of Metering Entities on the data path. An accompanying
document [I-D.fessi-nsis-m-nslp-framework] makes a problem statement,
describes scenarios where such a path-coupled configuration of
Metering Entities would be useful, elaborates requirements and
discusses the applicability of NSIS to the problem. This document
suggests a Metering NSIS protocol design, defines Metering NSLP
messages, outlines protocol operation and discusses commonalities and
differences to other NSLPs.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 2]
Internet-Draft Metering NSLP July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic Protocol Design . . . . . . . . . . . . . . . . . . . . 7
3.1 Model of operation . . . . . . . . . . . . . . . . . . . . 7
3.2 Protocol overview . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Metering NSLP Message types . . . . . . . . . . . . . 9
3.3 Design Decisions . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Soft State . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Message Sequencing . . . . . . . . . . . . . . . . . . 11
3.3.3 Message Scoping . . . . . . . . . . . . . . . . . . . 11
3.3.4 Rerouting . . . . . . . . . . . . . . . . . . . . . . 11
3.3.5 Selection of MNEs . . . . . . . . . . . . . . . . . . 12
3.3.6 Refreshing Sessions . . . . . . . . . . . . . . . . . 12
3.3.7 Aggregation . . . . . . . . . . . . . . . . . . . . . 13
4. Metering NSLP Functional Specification . . . . . . . . . . . . 13
4.1 Metering NSLP Message Structure . . . . . . . . . . . . . 13
4.1.1 CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 REFRESH . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Metering NSLP Objects . . . . . . . . . . . . . . . . . . 14
4.2.1 Message Sequence Number (MSN) . . . . . . . . . . . . 14
4.2.2 MNE_Selection Object . . . . . . . . . . . . . . . . . 14
4.2.3 MNE_Counter Object . . . . . . . . . . . . . . . . . . 15
4.2.4 Status_List Object . . . . . . . . . . . . . . . . . . 15
4.2.5 Session Lifetime Object . . . . . . . . . . . . . . . 15
4.2.6 MSPEC Objects . . . . . . . . . . . . . . . . . . . . 16
4.3 General Processing Rules . . . . . . . . . . . . . . . . . 19
4.3.1 State Manipulation . . . . . . . . . . . . . . . . . . 19
4.3.2 Message Forwarding . . . . . . . . . . . . . . . . . . 19
4.3.3 Standard Message Processing Rules . . . . . . . . . . 20
4.3.4 Message Processing Rules . . . . . . . . . . . . . . . 20
4.4 Session State Machine . . . . . . . . . . . . . . . . . . 22
5. Examples of Operation . . . . . . . . . . . . . . . . . . . . 24
6. Mapping onto M-NSLP Requirements . . . . . . . . . . . . . . . 25
7. Security considerations . . . . . . . . . . . . . . . . . . . 26
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 3]
Internet-Draft Metering NSLP July 2005
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1 Normative References . . . . . . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 33
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 4]
Internet-Draft Metering NSLP July 2005
1. Introduction
Monitoring, metering and accounting of packets is an important
functionality in many networks today. Several working groups have
described mechanisms to collect and report usage data for resource
consumption in a network by a particular entity. For example, the
IPFIX WG defines a protocol to collect such data. The PSAMP WG
defines a standard to sample subsets of packets by statistical and
other methods. RADIUS (see [RFC2865] and [RFC2866]) and DIAMETER
(see [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols
which provide information about consumed resources. The Meter MIB
[RFC2720] is a MIB for collecting flow information.
However, it is also necessary to configure and coordinate the
entities performing the metering. RADIUS, DIAMETER and SNMP are
candidates for this configuration. Nevertheless, these protocols
require some knowledge about the location of the appropriate Metering
Entities to configure them.
In more complex network topologies and architectures the appropriate
entities to meter a given data flow can be discovered dynamically
using path-coupled signaling. If more than one Metering Entity is
required, all of them can potentially be configured and coordinated
with a single message along the path.
Scenarios and requirements for Metering NSLP are described in
[I-D.fessi-nsis-m-nslp-framework].
This draft introduces the Metering NSLP for configuration and
coordination of Metering Entities in a path-coupled fashion.
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 following terms:
Metering Record
A Metering Record describes flow characteristics for a particular
flow. Examples for such data are packet counter, time
information.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 5]
Internet-Draft Metering NSLP July 2005
Monitoring Probe
A Monitoring Probe is an entity that examines the data flow in
order to gather Metering Records. These Metering Records are
exported to a Collector.
Metering Entity
A Metering Entity is a node that is equiped with one or more
Monitoring Probes. A Metering Entity MAY host other functions as
in Figure 1 below, such as Metering Manager, M-NSLP Processing,
etc. Note however, that the Collector is typically not co-located
with the Metering Entity and an other protocol (e.g. IPFIX) is
needed to report the Metering Records to the Collector.
Collector
A Collector receives Metering Records from one or multiple
Metering Entities. These Metering Records can be aggregated
and/or correlated by the Collector.
Metering Configuration State
State used/kept by the Metering Manager to configure the
Monitoring Probe.
Metering Manager
A unit co-located with the Monitoring Probe that communicates with
M-NSLP processing. It holds Metering Configuration State which is
used to configure the Monitoring Probe.
MNE
An NSIS Entity (NE) which supports the Metering NSLP.
MNI
The first node in the sequence of MNEs that issues a configuration
message for a flow or aggregate.
MNR
The last node in the sequence of MNEs that receives a
configuration message for a flow or aggregate.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 6]
Internet-Draft Metering NSLP July 2005
MNF
A MNE that is neither MNI nor MNR.
3. Basic Protocol Design
The design for the Metering NSLP and the processing of M-NSLP
messages is similar to QoS NSLP. The main difference compared to the
QoS NSLP is that only a subset (in some cases even only one) of the
Metering Entities in the signaling path will take part of the actual
Metering. This fact has several consequences on the signaling itself
and therefore on the protocol design.
3.1 Model of operation
Figure 1 shows an example logical model of the operation of Metering
NSLP and the associated metering mechanism in a MNE.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 7]
Internet-Draft Metering NSLP July 2005
to the Collector
^
+---------------+ *
| Local | *
| Management | *
+---------------+ *
^ *
V *
+----------+ +----------+ +---------+ *
| M-NSLP | | Metering | | Policy | *
|Processing|<<<<>>>>>|Management|<<>>| Control | *
+----------+ +----------+ +---------+ *
. ^ | V *
| ^ . V *
| V . V *
| V . V *
+----------+ V Metering Records *
| GIMPS | V *****************
|Processing| V *
+----------+ V *
| | +-------------------+
. . | |
+----------+ +-----------+ | Monitoring |
<-.-| Input | | Outgoing |-.-| Probe |-.-.-.->
| Packet | | Interface | | |
===>|Processing|====| |===| |=======>
+----------+ +-----------+ +-------------------+
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
*****> = Measurement resp. Metering Records
Figure 1: Metering-NSLP in Metering Entity
The Monitoring Probe collects measurement data and processes them
into Metering Records. These Metering Records can be sent to the
Collector. The Monitoring Probe is co-located with the Input Packet
Processing and the Outgoing Interface.
A M-NSLP message called CONFIGURE transports:
a. appropriate information to determine which MNEs on the path need
to take part of the metering
b. metering configuration information
The M-NSLP processing decides based on a. if the current MNE is
addressed by this configuring message. If yes, the metering
configuration information is extracted from the M-NSLP message and
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 8]
Internet-Draft Metering NSLP July 2005
passed to the Metering Manager, where it is interpreted and used to
install Metering Configuration State. The Metering Manager uses this
state to configure the Monitoring Probe.
The Policy Control determines whether the sender of the M-NSLP
message is authorized to configure the Monitoring Probe.
From the perspective of a single node, the request for configuration
of Metering Entities may result from processing a local management
request, or from processing an incoming M-NSLP message. The local
management may in turn be triggered by a local application, e.g. a
video being requested from a video server, or by a physically
separate knowledgeable network node.
3.2 Protocol overview
3.2.1 Metering NSLP Message types
The Metering NSLP messages are classified into 3 categories:
o request messages
o response messages
o asynchronous notifications
3.2.1.1 Request Messages
CONFIGURE
CONFIGURE is a request message. It is used to create Metering
Configuration State in a Metering Entity. The CONFIGURE message
is idempotent; the resultant effect on the Metering Configuration
State and on the M-NSLP state is the same whether a message is
received once or many times.
REFRESH
The REFRESH message is a request message that is used for 2
reasons:
* First, to extend the lifetime of an existing M-NSLP session if
required.
* Second, REFRESH messages are used to inspect if the MNEs that
are involved in the metering process are still taking part of
it. This might not be the case, for example, if a re-routing
event has happened and one of the involved MNEs in not on the
path anymore.
* Third, for terminating a session.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 9]
Internet-Draft Metering NSLP July 2005
3.2.1.2 Response Messages
RESPONSE
The RESPONSE message is used to provide information about the
result of a previous M-NSLP message. This includes explicit
confirmation of the state manipulation signaled in the CONFIGURE
message, the response to a REFRESH message or an error code if a
MNE is unable to provide the requested information or if the
response is negative.
The RESPONSE message is idempotent; the resultant effect on the
Metering Configuration State and on the M-NSLP state is the same
whether a message is received once or many times.
3.2.1.3 Asynchronous Notifications
NOTIFY
The NOTIFY message is used to convey information to a MNE. It
differs from RESPONSE messages in that it is sent asynchronously
and need not refer to any particular state or previously received
message. The information conveyed by a NOTIFY message is
typically related to error conditions. An example would be
notification to an upstream peer about state being torn down.
Each Metering NSLP message has a common header which indicates the
message type and contains flags. The parameters carried in each of
the Metering NSLP messages are defined in Section 4.1. Message
Processing Rules are defined in Section 4.3.4.
Metering NSLP messages contain three types of objects:
Control Information
Control information objects carry general information for the
M-NSLP Processing, such as sequence numbers and whether the MNE
should actually take part of the Metering.
Metering specification (MSPEC)
MSPEC objects describe the actual Configuration information. They
are interpreted in the Metering Manager and SHOULD be opaque to
M-NSLP Processing.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 10]
Internet-Draft Metering NSLP July 2005
Policy objects
Policy objects contain data used to authenticate M-NSLP messages
and authorize the configuration of the MNEs. They are interpreted
by Policy Control.
Detailed information about the Metering NSLP objects can be found in
Section 4.2.
3.3 Design Decisions
3.3.1 Soft State
NSIS State is always soft state and needs to be refreshed. The
Control Information carries an object that determines the life time
of M-NSLP state. The MNI suggests a lifetime for the session that it
is being signaled for. Each MNE participating in the metering
process may or may not accept the suggested lifetime or may start the
metering with a reduced lifetime, depending on the local policies of
the MNEs. This behavior is very similar to to the calculation of
Session Lifetime in NATFW-NSLP [I-D.ietf-nsis-nslp-natfw].
3.3.2 Message Sequencing
The order in which CONFIGURE messages arrive influences the eventual
configuration state that will be stored at a MNE. Therefore M-NSLP
supports the detection of CONFIGURE message duplication and re-
ordering using a Message Sequence Number (MSN).
3.3.3 Message Scoping
In order to realize the requirement of scoping of M-NSLP messages up
to a certain types of Metering Entities, it is necessary to have an
abstract language that can characterize Metering Entity types.
When a M-NSLP processing recognizes that the Metering Entity is of
the type specified, it terminates the signaling. The MNE acts as a
Signaling Responder.
3.3.4 Rerouting
M-NSLP automatically adapts to rerouting events because state along
the old path times out, and a new CONFIGURE message with the same
SESSION_ID will install state along the new path.
For M-NSLP it is generally not important to quickly tear down
configuration state along the old path, however for some
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 11]
Internet-Draft Metering NSLP July 2005
applications, e.g. accounting, it is vital to quickly configure MNEs
on the new path.
3.3.5 Selection of MNEs
An interesting feature of the Metering NSLP is that only a subset of
MNEs on the data path might take part in the actual metering.
Metering Entities taking part in the metering process are determined
based, for example, on their type, number or position on the path.
This feature is the most striking difference to the QoS NSLP with a
number of implications.
When the first CONFIGURE message is sent, each MNE on the data path
needs to determine whether it should take part in the metering
process or not. For this reason, we need the object MNE_Selection in
the CONFIGURE message.
When the MNE finds out it is not involved in the metering, it does
not need to install, neither Metering Configuration State, nor M-NSLP
state. (For clarification, see here Section 4.3.1 where the
different state information that an MNE needs to store is
illustrated).
3.3.6 Refreshing Sessions
Refreshing M-NSLP sessions is required for several reasons.
o First, to extend the lifetime of an existing M-NSLP session if
required.
o Second, by refreshing M-NSLP sessions, it can be inspected if the
MNEs that are involved in the metering process are still metering.
This might not be the case, for example, if a re-routing event has
happened and one of the involved MNEs in not on the path anymore.
To realize the latter requirement, we introduce the Metering NSLP
message REFRESH, which differs from the CONFIGURE message.
After a REFRESH message travels all the way from the MNI to the MNR,
the MNR responds with a RESPONSE message where MNEs can write their
current status. Each MNE that is involved in the metering process
marks an appropriate field reserved for it in the RESPONSE message to
say "METERING". For this reason we use the Status_List object in the
Metering NSLP that is used by the RESPONSE message.
MNEs that are not taking part of the metering process have not
installed any M-NSLP state for this session and are agnostic about
it. These MNEs will just forward the REFRESH/RESPONSE message
towards the MNR/MNI.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 12]
Internet-Draft Metering NSLP July 2005
When the RESPONSE message arrives at the MNI, the MNI verifies if the
previously selected MNEs are still involved. If not, the MNI can re-
initiates the signaling with a CONFIGURE message with the same
SESSION_ID and the same Correlation-ID (if there is one
Correlation-ID in the MSPEC objects).
3.3.7 Aggregation
The metering configuration should allow aggregation of Metering
Records belonging to the same user or application. The information
required for the aggregation must be specified in the MSPEC. Such
aggregation can be done in two ways.
o A Monitoring Probe separately collects and reports data for each
micro flow (e.g., given for all different combinations of port
numbers) contained in the macro flow that is signaled by the NTLP.
o A Monitoring Probe separately collects micro flows but reports all
flows in a single record.
4. Metering NSLP Functional Specification
4.1 Metering NSLP Message Structure
As in other NSLPs, Metering NSLP messages consists of a common
header, followed by a body consisting of a variable number of
variable-length, typed "objects". The common header and other
objects are encapsulated together in a GIMPS NSLP-Data object.
The following subsections define the objects carried in each of the
Metering NSLP messages.
4.1.1 CONFIGURE
The CONFIGURE message carries the following objects:
o SESSION_ID: A large identifier provided by GIMPS or set locally.
o Message Sequence Number (MSN)
o MNE_Selection: this object is required to determine which MNEs
will actually take part of the metering.
o MNE_Counter: this parameter is used to count how many MNEs on the
path are participating in the metering process. Each MNE that is
participating in the metering process increments this parameter by
one.
o MSPEC: the MSPEC objects determine the actual configuration. The
MSPEC SHOULD be opaque to the Metering NSLP.
o Session Lifetime: this object gives the requested lifetime for a
M-NSLP session.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 13]
Internet-Draft Metering NSLP July 2005
4.1.2 REFRESH
The REFRESH message carries the following objects:
o SESSION_ID: this parameter refers to the same SESSION_ID given in
the initial CONFIGURE message in the Metering NSLP session.
o Message Sequence Number (MSN)
o MNE_Counter: this parameter is used to count how many MNEs on the
path are participating in the metering process. Each MNE that is
participating in the metering process increments this parameter by
one.
o Session Lifetime: this object gives the requested lifetime to
extend the M-NSLP session.
4.1.3 RESPONSE
The RESPONSE message carries the following objects:
o Message Sequence Number (MSN): the MNR MUST send the same MSN as
in the corresponding M-NSLP request message in order to match a
RESPONSE to the appropriate request message.
o MNE_Selection: in some scenarios the actual MNEs that will take
part of the metering are not determined until the RESPONSE message
arrives. For this reason, the parameter MNE_Selection might be
required.
o Status_List: This object contains one field of the size of one
byte for each MNE participating in the metering process. Each
participating MNE can store its status in the appropriate field
reserved for it. The size of Status_List can be interpreted from
the value of MNE_Counter. The status can be, for example,
"METERING", "NO DATA" or "OVERLOADED".
o ERROR_CODE: this object is required if the configuration can not
be achieved successfully.
4.1.4 NOTIFY
A NOTIFY message MUST contain an ERROR_SPEC object indicating the
reason for the notification.
4.2 Metering NSLP Objects
4.2.1 Message Sequence Number (MSN)
As mentioned above, the Message Sequence Number is used to detect
duplicate Metering NSLP messages.
4.2.2 MNE_Selection Object
As mentioned above, this parameter is required to determine which
MNEs will actually take part of the metering. The value of the
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 14]
Internet-Draft Metering NSLP July 2005
MNE_Selection parameter can be one of the following:
o FIRST: the first MNE in the signaling path, i.e. the NI.
o LAST: the last MNE signaling in the signaling path, i.e. the NR
o 'FIRST and LAST': both the NI and the NR take part of the
signaling.
o ANY: one MNE should be arbitrarily chosen to perform the metering.
o ALL: Each MNE capable of executing this metering request MUST
perform it. "ALL" must be interpreted here as "as many as
possible". here
o Function_X: for this case, an abstract language to characterize
the type of MNE is required. Using this abstract language, the
M-NSLP can evaluate if the MNE is of type "Fucntion_X" without
knowing what actually "Function_X" is. Note also, that the
abstract language can be, for example, proprietary. For more
background information on why such an abstract language is
required, please refer to Section "Accounting Scenario, Required
Parameters" in [I-D.fessi-nsis-m-nslp-framework].
4.2.3 MNE_Counter Object
This parameter is used to count how many MNEs on the path are
participating in the metering process. Each MNE that is
participating in the metering process increments this parameter by
one. When a request message (CONFIGURE or REFRESH) arrives at the
MNR, the object MNE_Counter will contain the number of the MNEs
participating in the metering process along the signaling path.
4.2.4 Status_List Object
This object is used for the RESPONSE message where each of the
involved MNEs in the metering process has one field where it can
store its current status. The Status_List consists of one field of
the size of one byte for each MNE participating in the metering
process. The status can be, for example, "METERING", "NO DATA" or
"OVERLOADED".
The size of the Status_List object is determined by the MNR based on
the object MNE_Counter.
4.2.5 Session Lifetime Object
This object gives the requested lifetime for a M-NSLP session in
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 15]
Internet-Draft Metering NSLP July 2005
seconds. When a M-NSLP session expires, the Metering Manager MUST
configure the Monitoring Probe to stop the Metering. The
corresponding Metering Configuration State is delete.
A value of zero for this object leads to immediate termination of the
corresponding session.
4.2.6 MSPEC Objects
The MSPEC objects describe the actual Configuration information.
They are interpreted in the Metering Manager and SHOULD be opaque to
M-NSLP Processing. The MSPEC objects MUST be extensible. The order
of objects is not defined, meaning that objects may occur in any
sequence. Currently, we define the MSPEC as follow:
<MSPEC> = <Filters> <Metered Objects> <Correlation-Id>
<Collector-Id> <FlowExpirationTime> <ExportPeriod>
<Sampling-Alg-Id> <Sampling-Params> <Hash Function>
4.2.6.1 The <Filters> Object
<Filters> restricts the set of considered flows for the metering.
The MSPEC MUST support a value for <Filters> that is different from
the flow information kept at GIMPS. In particular, the <Filters>
value does not need to be an IP 5-tuple. However, it could be, for
example, a 5-tuple where one or more fields are wild-carded.
For example, it MUST be possible to count all TCP SYN packets or all
ICMP packets going to a given destination IP address.
4.2.6.2 The <Metered Objects> Object
This parameter is represented as a set of flags that determines which
information needs to be metered.
<Metered Objects> = <Number-of-Packets Flag> <Number-of-Octets Flag>
<Timestamp-Begin Flag> <Timestamp-End Flag>
o <Number-of-Packets Flag>: This field is set to 1 when the number
of packets in the metered flow must be accounted.
o <Number-of-Octets Flag>: This flag is set to 1 when the number of
octets in the metered flow must be accounted.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 16]
Internet-Draft Metering NSLP July 2005
o <Timestamp-Begin Flag>: This field is set to 1 when a timestamp at
the arrival of the first packet in this flow must be recorded.
o <Timestamp-End Flag>: This field is set to 1 when a timestamp at
the arrival of the last packet in this flow must be recorded.
4.2.6.3 The <Correlation-Id> Object
As described in [I-D.fessi-nsis-m-nslp-framework], the Correlation-ID
is an ID that identifies the measurement. Reported Metering Records
from different MNEs can be correlated by the Collector using this ID.
The Correlation-ID MUST be unique for a specific measurement. It
MIGHT be generated by the NI or the NI MIGHT receive the
Correlation-ID from an external entity which communicates with the NI
using different means outside the scope of this document.
The parameter <Correlation-Id> is not mandatory. If a Correlation-Id
is provided in the MSPEC objects, it will be provided to the
Collector in the Metering Records. Otherwise, the Metering Records
will not contains a Correlation-ID.
4.2.6.4 The <Collector-Id> Object
This parameter specifies where the Metering Records need to be sent
to.
The parameter <Collector-Id> is not mandatory since the Collector
might be preconfigured in the MNE. If no Collector is preconfigured
in the MNE, the MNE SHOULD respond with an error message 'No
Collector specified' (Error messages have not been investigated for
the Metering NSLP yet).
4.2.6.5 The <Flow Expiration Time> Object
If no packets are observed for the specified amount of time interval,
the flow is considered as expired and it is reported.
The <Flow Expiration Time> parameter is not mandatory, since it MIGHT
be preconfigured in the MNE.
4.2.6.6 The <Reporting Interval> Object
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.
When the flow is reported, all counters and time stamp values are
reset.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 17]
Internet-Draft Metering NSLP July 2005
The <Reporting Interval> parameter is not mandatory since it might be
preconfigured in the MNE.
4.2.6.7 The <Sampling-Alg> Object
The <Sampling-Alg> object can take one of the following values:
o Select all
o Systematic count-based
o Systematic time-based
o Rand n out of N
o Uniform Probabilistic Sampling
o Non-Uniform Probabilistic Sampling
o Flow State Sampling
o Match Filtering
o Hash Filtering
o Router State Filtering
The sampling algorithms themselves will not be illustrated in this
document and can be inherited from the corresponding documents from
the PSAMP Working Group. ([I-D.ietf-psamp-sample-tech] [I-D.ietf-
psamp-info] and [I-D.ietf-psamp-mib])
4.2.6.8 The <Samling-Params> Object
Depending on the sampling algorithm, eventually some parameters are
required for the algorithm. Those can be specified here.
4.2.6.9 The Hash Function
This parameter gives a function H which is applied to the packets
before they are exported in the Metering Records. H might be a hash
function, a function that extracts some parts of the packets header
and/or the payload or the Identity function (i.e. the complete packet
is reported).
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 18]
Internet-Draft Metering NSLP July 2005
4.3 General Processing Rules
4.3.1 State Manipulation
The state that needs to be stored at a MNE for a M-NSLP session can
be of different types:
o NTLP state
o M-NSLP state
o Metering Configuration State
As mentioned in Section 2, Metering Configuration State is the state
used/kept by the Metering Manager to configure the Monitoring Probe.
This consists of the parameters specified in the MSPEC section
(Section 4.2.6).
One of the attractive properties of the Metering NSLP is that MNEs
that are not taking part of the metering do not need to install any
M-NSLP state. Nor do they need to install Metering Configuration
State. However, MNEs that are not taking part of the metering
process still need to store NTLP state in order to avoid GIMPS re-
discovering them each time when it refreshes its routing state. For
more details on how GIMPS refreshes its routing state, please see
[I-D.ietf-nsis-ntlp].
4.3.2 Message Forwarding
M-NSLP request messages (CONFIGURE or REFRESH) are initiated by the
MNI and forwarded downstream (i.e. in the same direction as the data
flow) using GIMPS.
When a MNE receives a request message, the message is forwarded
downstream to the next MNE, except in 2 cases:
o the CONFIGURE message has reached the MNR.
o the involved MNEs in the configuration have been reached.
The latter case can be for example:
o if the SCOPING flag is set and the CONFIGURE message has reached
the end of the scope of the signaling.
o if MNE_Selection is 'ANY' and an appropriate MNE has been already
found.
o if MNE_Selection is FIRST. (in this case, only the MNI is involved
in the signaling)
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 19]
Internet-Draft Metering NSLP July 2005
In these cases, there is no need to forward the M-NSLP message
further.
M-NSLP response messages are forwarded upstream along the data path
towards the MNI.
M-NSLP asynchronous notifications can be sent upstream or downstream
depending on the reason for the notification.
4.3.3 Standard Message Processing Rules
If a mandatory object is missing from a message then the receiving
MNE MUST NOT propagate the message any further. It MUST construct an
RESPONSE message indicating the error condition and send it back to
towards the MNI.
If a message contains an object of an unrecognized type, then the
behavior depends on the object type value.
4.3.4 Message Processing Rules
4.3.4.1 The CONFIGURE Message
When a MNE receives a CONFIGURE message, it performs the following
steps:
o The MNE checks the message format. In case of malformed messages,
the MNE sends a RESPONSE message with the appropriate ERROR_SPEC.
o Before performing any state changing actions, the MNE MUST
determine whether the sender of the request is authorized to
perform this configuration action.
o After the CONFIGURE message is authorized, the MNE needs to figure
out if it will take part of the metering or not based on the
MNE_Selection object:
* If (MNE_Selection = FIRST) or (MNE_Selection = LAST) or
(MNE_Selection = 'FIRST and LAST'), the MNE figures out if one
these contraints equates to true. If yes, the MSPEC is
extracted from the CONFIGURE message and passed to the Metering
Manager as shown in Figure 1.
* If (MNE_Selection = ALL) the MSPEC is extracted from the
CONFIGURE message and passed to the Metering Manager.
* If MNE_Selection = 'ANY', the MNE verifies first if MNE_Counter
is equal to one. This means, it verifies, if there has been
already one MNE on the path that is willing to take this task.
If MNE_Counter is zero, the MNE verifies based on its current
status (number of existing measurements, current load, etc) if
it is able to perform the metering request. If yes, the MSPEC
is extracted from the CONFIGURE message and passed to the
Metering Manager.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 20]
Internet-Draft Metering NSLP July 2005
o If the evaluation of MNE_Selection results in to not taking part
of the metering, then the MNE does not store any Metering
Configuration State. Now, the MNE decides whether to forward the
CONFIGURE message. This decision is taken based on Section 4.3.2
o If the evaluation of MNE_Selection results in to taking part of
the metering and the MSPEC is passed to the Metering Manager, the
Metering Manager verifies if the Monitoring Probe is able to
perform the metering based on the information in the MSPEC
parameters, for example, if the requested export protocol is
supported, and if the sampling algorithm is supported, etc.
o If the Metering Manager categorizes the metering request as
feasible, it stores the Metering Configuration State and informs
the M-NSLP processing. Note however that the configuration is not
activated, i.e. the Monitoring does not start the metering, until
the MNE receives the matching RESPONSE. Now, the MNE increments
the parameter MNE_Counter by one to signal that it is taking part
of the metering. Afterwards, the MNE needs to decide whether to
forward the CONFIGURE message or not. Again here, this decision
can be taken based on Section 4.3.2.
o If the evaluation of MNE_Selection results in to taking part of
the metering, but the Metering Manager categorizes the metering
request as NOT feasible, then:
* If (MNE_Selection = FIRST) or (MNE_Selection = LAST) or
(MNE_Selection = 'FIRST and LAST') and the MNE is indeed the
first or the last MNE on the signaling path, then the MNE
constructs a RESPONSE message with the appropriate ERROR_SPEC
and sends it back towards the MNI. Otherwise, the MNE forwards
the message to the next MNE.
* If (MNE_Selection = ANY) and the message has reached the MNR,
i.e. no appropriate MNE has been found on the path, then the
MNE (which is in this case the MNR) constructs a RESPONSE
message with the appropriate ERROR_SPEC and sends it back
towards the MNI. Otherwise, the MNE forwards the message to
the next MNE.
* If (MNE_Selection = ALL), since "ALL" must be understood here
as "as many as possible", the MNE does not need to generate a
RESPONSE message with an ERROR_SPEC. It just needs to forward
the message to the next MNE.
4.3.4.2 The REFRESH Message
Processing REFRESH messages is simple:
o If the SESSION_ID is known, the MNE verifies based on its local
policies if the requested lifetime is allowed. If not, the MNE
adapts the time interval to its local policies. Now, the MNE
increments the parameter MNE_Counter by one to signal that it is
still taking part of the metering. Afterwards, the MNE decides
whether to forward the REFRESH message to the next MNE on the
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 21]
Internet-Draft Metering NSLP July 2005
path. This decision can be taken based on Section 4.3.2. Note
here, that the lifetime of the M-NSLP session is not extended
until the corresponding RESPONSE message arrives. Also note that
a lifetime of zero lead to immediate termination of the session
when the corresponding RESPONSE message arrives.
o If the SESSION_ID is unknown, i.e. the MNE has not stored any
M-NSLP state for this session, the message is just forwarded to
the next MNE on the path.
4.3.4.3 The RESPONSE Message
If a RESPONSE message is a negative response with an ERRPR_SPEC
object, the MNE just forwards the message towards the MNI. When the
MNI receives this message it has to take the appropriate action based
on the content of the ERROR_SPEC object.
If the RESPONSE message is a positive RESONSE, the processing of the
message depends on the type of the corresponding M-NSLP request
message (CONFIGURE or REFRESH). However, in both cases, the RESPONSE
message contains the object Status_List where the MNEs that are
involved in the metering process can report their status. This
status can be, for example, "METERING", "NO DATA" or "OVERLOADED".
Processing RESPONSE messages is described in several parts of this
documents. However, it still needs to be described more clearly in
this section in future versions.
4.3.4.4 The NOTIFY Message
tbd.
4.4 Session State Machine
The state machine of a M-NSLP session has three main states:
'session closed':
At this state, the MNE does not keep any state of the session.
'pending':
At this state a CONFIGURE message has been received, the MNE has
been successfully configured (i.e. authentication and
authorization succeeded, the evaluation of MNE_Selection and the
evaluation of the MSPEC objects by the Metering Manager were
positive, etc.) however the configuration has not been activated
yet, i.e. metering function has been started.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 22]
Internet-Draft Metering NSLP July 2005
'metering':
At this state the MNE is metering according to a metering
configuration received by a CONFIGURE message.
All of these states have sub-states, but the basic M-NSLP operation
per session is described on the level of these three states.
A session is identified by SESSION_ID. All sessions start in state
'session closed'. Transitions between states are caused by events:
CONF:
This transition is triggered by a CONFIGURE message that
identifies the session and that is received and processed
successfully by the MNE.
REFR:
This transition is triggered by a REFRESH message that identifies
an existing session in state 'pending' or 'metering'.
RESP-M:
This transition is triggered by a RESPONSE message that is sent by
the MNE in order to indicate that a metering configuration sent by
a CONFIGURE message of the same session has become active at the
MNE. This transaction always leads to state 'metering'.
RESP-N:
This transition is triggered by a RESPONSE message that is sent by
the MNE in order to indicate that a metering configuration sent by
a CONFIGURE message of the same session has not become active at
the MNE. This transaction always leads to state 'session closed'.
T-OUT:
This transition is triggered by a time out of a session in state
'pending' or 'metering'. This transaction always leads to state
'session closed'.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 23]
Internet-Draft Metering NSLP July 2005
REFR +----+
| v
+----------+
| session |
| closed |<-------------+
+----------+ |
| ^ |
CONF | | RESP-N | RESP-N
v | T-OUT | T-OUT
+----------+ +----------+
| pending | RESP-M | metering |
| |-------->| |
+----------+ +----------+
CONF | ^ CONF | ^
REFR | | REFR | |
+----+ RESP-M +----+
5. Examples of Operation
The basic signaling sequences are similar to QoS NSLP: To start a
configuration, the MNI constructs a CONFIGURE message with the
required MSPEC objects, and sends it to the MNR. The message is
interpreted by MNEs on the data path. The MNR replies with a
RESPONSE message.
+---+ CONFIGURE +---+ CONFIGURE +---+ CONFIGURE +---+
| |------------>| |------------>| |------------>| |
|MNI| |MNF| |MNF| |MNR|
| |<------------| |<------------| |<------------| |
+---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+
Similarly, a REFRESH message can be initiated by MNI, travels to the
MNR where a RESPONSE is issued and sent back.
+---+ REFRESH +---+ REFRESH +---+ REFRESH +---+
| |------------>| |------------>| |------------>| |
|MNI| |MNF| |MNF| |MNR|
| |<------------| |<------------| |<------------| |
+---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+
More detailed examples of operation will be depicted in future
versions of this document.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 24]
Internet-Draft Metering NSLP July 2005
6. Mapping onto M-NSLP Requirements
With the design described above, the requirements from [I-D.fessi-
nsis-m-nslp-framework] are at this point satisfied as follows:
Extensibility:
The actual configuration information is encapsulated in the MSPEC.
The MSPEC is designed such as it is interpreted by the Metering
Manager and can be opaque to the M-NSLP processing. Furthermore,
the MSPEC can be easily extended. Therefore, from the point of
view of the configuration information, this requirement is
fulfilled. Note however, that the Metering NSLP in its current
design might show some lack of extensibility. For example,
considering the selection of the MNEs, it might be useful for
future application of the Metering NSLP to have the option "ANY
N", where N is greater than one.
Interoperability:
Again, whether different metering solutions can interwork depends
on how the MSPEC is designed. In QoS NSLP, the QSpec template
design [I-D.ietf-nsis-qspec] aims at similar extensibility and
interoperability. It needs to be studied whether or not the
solutions chosen by the QSpec can also be applied to the MSPEC.
Flexible metering models:
As above, this is an issue of MSPEC design.
Distinguishing flows
The aggregation feature detailed in this requirement can be
realized as described in Section 3.3.7.
Flexible data collection:
Another issue that can be fixed in the MSPEC.
Location of Metering Entities:
MNEs, including MNI and MNR can be located anywhere on the data
path.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 25]
Internet-Draft Metering NSLP July 2005
Access parameters of the Collector Information:
Access parameters of the Collector Information on how to deliver
flow records to the Collector is coded in the MSPEC.
Configuration of Metering Entities:
The protocol can configure Metering Entities that are MNEs, or
that are controlled by MNEs.
Selection of Metering Entities:
As described in Section 3.3.5, a MNE should be able to decide to
pull out of the metering process. This is realized by the
MNE_Selection object.
Metering Configuration State installation and removal:
By means of the CONFIGURE message, the protocol can install and
remove Metering Configuration State.
Initiation and maintenance of metering tasks:
Triggers and correlation identifier are transported in the MSPEC.
Reaction to Route Changes:
The protocol detects route changes by a REFRESH or a refreshing
CONFIGURE message and installs state along the new route, as
described in Section 3.3.4.
Scoping of configuration:
The M-NSLP needs to provide sufficient means for flexible scoping
signaling messages.
Requirements not mentioned in this list are not yet addressed.
7. Security considerations
The process of configuring entities to start and stop metering and to
transmit collected resource records to a third party introduces
security challenges.
o First, the application domain (e.g., usage of the metering NSLP
for configuration entities related to accounting and charging)
needs to be considered. For example, if a user is capable of stop
metering of a requested services then fraud is possible.
Furthermore, it must not be possible to configure metering
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 26]
Internet-Draft Metering NSLP July 2005
entities in such a way that other users are charged for the usage
of a service, which they have not used.
o Second, interworking between multiple domains causes authorization
problems. For example, network domain A might want to collect
resource records in network domain B to offer the user with a more
consistent bill covering both the price of the network resource
consumption and the application usage. A high degree of trust is
required to allow other domains to configure metering entities and
to collect the resource usage of particular users. In any case it
needs to be prevented that arbitrary resource records associated
with users are collected by other domains. It has to be noted
that the process of charging involves other states than only the
collection of usage records.
o Third, it must be avoided that a denial of service attack is
mounted on either Collectors or Monitoring Probes. Monitoring
Probes can be subject to DoS attacks if a large number of resource
have to be collected or 'unlimited' per-flow states are created.
Collectors can be subject to DoS attacks if they are flooded with
metering records.
The above considerations raise the main question whether the
meetering NSLP can be used outside a single administrative domain.
Ideally, it should have a broader applicability but security, privacy
and other operational concerns might limit its applicability for
multiple domain traversal (and also end-to-end signaling).
In the broader sense the following aspects might require an answer:
o The introduced mechanisms allow a number of entities to configure
metering entities. This might introduce some weaknesses compared
to a centralized approach where a single entity (or a few selected
entities) are authorized to perform this action. Authorizing the
decentralized configuration of nodes is more difficult to secure.
Any node can initiate signaling message. Hence, a single
malicious entity within the network is able to start/stop/modify
the process of collecting metering records within a single domain
or even beyond this domain.
o Why would one domain allow (or disallow) the configuration/
reconfiguration of nodes triggered by another domain?
o Would a network operator allow an end user to collect information
about flows within the network?
o Would it be reasonable to allow a user to collect information
about a flow that he created but not for other flows?
o Is it reasonable to assume that nodes along the path are
configured to send collected data to an arbitrary IP address?
o Would it be reasonable to place some restrictions on the entity
that are supposed to receive this information (i.e., the
Collector)?
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 27]
Internet-Draft Metering NSLP July 2005
o Is a check needed to ensure that the Collector actually wants to
receive this information or even asked to collect it?. Some
denial of service attacks (via amplification) are 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 period of
time.
o Would a network operator want to reveal sensitive information?
Some of the information might have a relevance for the operator's
business?
o The collection of metering data about individual flows is a
potentially privacy sensitive task. Who owns, in legal terms, the
collected data (e.g., the user who initiated the flow, the owner
of the Monitoring Probe? Does ownership imply other rights (e.g.,
the right to dissemination)? Is it necessary to consider privacy
policies? Is it necessary to constrain the distribution of the
collected data in some way (e.g. based on user privacy policies)?
o Do certain terms and conditions, to which the metering site(s),
and the user have to agree, apply?
o Is it necessary to protect the confidentiality of the metered
data? If so, against disclosure to whom?
Answers to a few of these questions will help to develop an
authorization/trust model.
8. Open Issues
The protocol in its current design allows to select, except the
case "FIRST and LAST", either only one MNE or all the MNEs on the
path for the metering process. Based on the current scenarios
elaborated in [I-D.fessi-nsis-m-nslp-framework], this is
sufficient. However, the option to have, for example, "ANY N",
where N is greater than one, might be useful in future
applications of the Metering NSLP.
In some cases, the Collector needs to distinguish between the
Metering Records received from the different MNEs in order to
correlate them. For example, if MNE_Selection is "FIRST and
LAST", the Collector needs to know, which data come from the first
and resp. the last MNE on the signaling path. Also, in the case
where MNE_Selection is "ALL", the Collector needs to know the
position of the MNEs that are sending the Metering Records on the
path in order to correlate them correctly, (for example to
calculate the hop-by-hop delay). This information needs to be
transferred to the Collector in the Metering Records using an
other protocol. However, the M-NSLP might also need to provide
mechanisms to coordinate this. Each MNE need to know its position
on the path, i.e. how many MNEs exists between it and the MNI.
Moreover, if not all the IP hops on the path do support the
Metering NSLP, it will be useful for the Collector to know how far
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 28]
Internet-Draft Metering NSLP July 2005
each pair of adjacent MNEs are from each other.
Based on the current analysis of the security issues of the
Metering NSLP discussed in Section 7, an authentication and
authorization scheme for the Metering NSLP needs to be elaborated.
The policy objects carried in Metering NSLP messages need to be
specified.
Additional open issues appear in the main body of the text.
9. Acknowledgements
The authors would like to thank Robert Hancock, Martin Stiemerling
and Andreas Klenk for their valuable input.
10. References
10.1 Normative References
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06
(work in progress), May 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
10.2 Informative References
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2720, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-17 (work in progress),
July 2005.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 29]
Internet-Draft Metering NSLP July 2005
[I-D.ietf-ipfix-info]
Quittek, J., "Information Model for IP Flow Information
Export", draft-ietf-ipfix-info-09 (work in progress),
July 2005.
[I-D.ietf-psamp-sample-tech]
Zseby, T., "Sampling and Filtering Techniques for IP
Packet Selection", draft-ietf-psamp-sample-tech-07 (work
in progress), July 2005.
[I-D.ietf-psamp-mib]
Dietz, T., "Definitions of Managed Objects for Packet
Sampling", draft-ietf-psamp-mib-04 (work in progress),
February 2005.
[I-D.ietf-psamp-info]
Dietz, T., "Information Model for Packet Sampling
Exports", draft-ietf-psamp-info-02 (work in progress),
July 2004.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-06
(work in progress), February 2005.
[I-D.ietf-nsis-fw]
Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-07 (work in progress), December 2004.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in
progress), May 2005.
[I-D.ietf-nsis-qspec]
Ash, J., "QoS-NSLP QSPEC Template",
draft-ietf-nsis-qspec-05 (work in progress), July 2005.
[I-D.fessi-nsis-m-nslp-framework]
Fessi, A., "Framework for Metering NSLP",
draft-fessi-nsis-m-nslp-framework-00 (work in progress),
February 2005.
[I-D.ietf-aaa-diameter-cc]
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 30]
Internet-Draft Metering NSLP July 2005
Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H.
Hakala, "Diameter Credit-control Application",
draft-ietf-aaa-diameter-cc-06 (work in progress),
August 2004.
[3GPP.32.240]
3GPP, "Telecommunication management; Charging management;
Charging architecture and principles", 3GPP TS 32.240
6.0.0, September 2004.
Authors' Addresses
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/
Ali Fessi
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 71076
Germany
Phone: +49 7071 29-70534
Email: fessi@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Georg Carle
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 71076
Germany
Phone: +49 7071 29-70505
Email: carle@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 31]
Internet-Draft Metering NSLP July 2005
Juergen Quittek
NEC
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511-15
Email: quittek@netlab.nec.de
URI: http://www.netlab.nec.de/
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Phone: +49 30 386-32894
Email: cornelia.kappler@siemens.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 32]
Internet-Draft Metering NSLP July 2005
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 (2005). 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.
Dressler, et al. draft-dressler-nsis-metering-nslp-02.txt [Page 33]