| TOC |
|
This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668.
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 April 17, 2005.
Copyright (C) The Internet Society (2004).
Monitoring, metering and accounting of packets are increasingly important functionality that needs to be provided in the Internet. This document proposes the definition of a new NSIS NSLP, named Metering NSLP, which allows the dynamic configuration of Metering Entities on the data path. A problem statement, scenarios for charging, QoS monitoring, and monitoring for network security issues such as intrusion detection, and requirements are presented. Finally, the usage of NSIS for this purpose is motivated.
1.
Introduction
2.
Terminology
3.
Problem Statement
4.
Scenarios
4.1
Charging
4.2
QoS Monitoring
4.3
Intrusion Detection
4.4
Configuration information common to all scenarios
5.
Requirements
5.1
General requirements
5.1.1
Extensibility
5.1.2
Scalability
5.1.3
Interoperability
5.1.4
Security
5.2
Flexible metering model
5.3
Distinguishing flows
5.4
Flexible data collection
5.5
Location of Metering Entities
5.6
Location of the collector
5.7
Configuration protocol
5.7.1
Configuration of Metering Entities
5.7.2
Selection of Metering Entities
5.7.3
Metering Configuration State installation and removal
5.7.4
Initiation and maintenance of metering tasks
5.7.5
Collection of information on available Metering Entities
5.7.6
Scoping of configuration
5.8
Metering across domains
6.
Applicability of NSIS
7.
Basic Protocol Design
7.1
Model of operation
7.2
Protocol overview
7.2.1
Message types
7.2.2
Design Decisions
7.3
Examples of operation
7.4
Implications for GIMPS API
7.5
Mapping onto M-NSLP Requirements
8.
Security considerations
9.
Open issues
10.
Acknowledgements
11.
References
11.1
Normative References
11.2
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
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. RADIUS (see [RFC2865]Rigney, C., Willens, S., Rubens, A. and W. Simpson, Remote Authentication Dial In User Service (RADIUS), June 2000., [RFC2866]Rigney, C., RADIUS Accounting, June 2000. and [I-D.draft-lior-radius-prepaid-extensions-03]Lior, A., Yegani, P., Chowdhury, K. and Y. Li, PrePaid Extensions to Remote Authentication Dial-In User Service (RADIUS), July 2004.) and DIAMETER (see [RFC3588]Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, Diameter Base Protocol, September 2003. and [I-D.ietf-aaa-diameter-cc]Hakala, H., Mattila, L., Koskinen, J., Stura, M. and J. Loughney, Diameter Credit-control Application, August 2004.) are also protocols which provide information about consumed resources via Metering Records. The Meter MIB [RFC2720]Brownlee, N., Traffic Flow Measurement: Meter MIB, October 1999. is a MIB for collecting flow information. However, it is also necessary to configure and coordinate the entities doing the metering. In more complex network topologies and architectures these entities are not only located at the edges of a network. Instead, these Metering Entities are distributed along the data path. While it is possible to configure these entities with protocols such as RADIUS or DIAMETER (or SNMP for the Meter MIB), it is also cumbersome.
This draft introduces a new NSLP, the Metering NSLP, for configuration and coordination of Metering Entities in a path-coupled fashion.
This draft is organized as follows: We give a problem description in Section 3Problem Statement, and then illustrate it with a number of scenarios in Section 4Scenarios. Subsequently, we list a few requirements in Section 5Requirements. Finally, we discuss the suitability of NSIS for the configuration of Metering Entities in Section 6Applicability of NSIS.
| TOC |
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]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
Furthermore, this document uses the following terms:
- Metering Data
Metering Data describe utilized resources concerning a particular flow or service for a later charging process. Examples for such data are packet counter, timers, and information describing the end user or system.
- Metering Record
A Metering Record represents aggregated and/or correlated Metering Data.
- Monitoring Probe
A monitoring probe is an entity that examines the data flow in order to gather Metering Data. This Metering Data is exported to an Metering Entity.
- Metering Entity
An Metering Entity produces Metering Data describing the resource utilization of a particular flow or service. Typically, this information is collected from accociated monitoring probes.
- Collector
A collector receives Metering Data from one or multiple Metering Entities. This Metering Data is aggregated, correlated, and stored in form of Metering Records.
- Metering Configuration State
State used/kept by the Metering Manager to configure the Metering Entity and Monitoring Probes.
- Metering Manager
A unit in the Metering Entity that communicates with M-NSLP processing. It holds Metering Configuration State which is used to Configure Monitoring Probes and the Metering Entity.
- 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.
- MNF
A MNE that is neither MNI nor MNR.
| TOC |
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 to facilitate services such as Internet research, measurement, accounting, billing, QoS monitoring, intrusion detection, and traffic profiling/engineering. In recognition of the need for such accounting the IPFIX WG was founded.
While the purpose for collecting Metering Records in each case is different, the basic architecture of such accounting systems is usually identical, cf. Figure 1Schematic Metering Architecture. Measurement data is collected by a monitoring probe, and from there transported to an metering entity. The Metering Entity produces Metering Data from the measurement data or additional data such as session information. Monitoring probe and Metering Entity may be collocated, and one Metering Entity may control several monitoring probes; in any event the monitoring probe is controlled by an Metering Entity. The Metering Entity transmits its Metering Data to the actual collector. The collector correlates Metering Data relating to the same event from different Metering Entities and produces an Metering Record. There may be more than one collector depending on the actual tasks.
+-----------------+
| Collector |
| +-------------+ |
| | Met. Record | |
| +-------------+ |
+-----------------+
^ ^ ^ ^
**** * * ****
**** * * ****
**** * * ****
**** * * ****
+-----------+ +-----------+ +-----------+ +-----------+
| +-----+| | +-----+| | +-----+| | +-----+|
===>| MNE| Met.||===>| MNE| Met.||===>| MNE| Met.||===>| MNE| Met.||===>
| | Data|| | | Data|| | | Data|| | | Data||
| +-----+| | +-----+| | +-----+| | +-----+|
+-----------+ | | +-----------+ +-----------+
^ ^ | | ^
* * | | *
+----+ +----+ | | +-----+
--->| MP | | MP |--->| MP |------>| MP |----------------------->
+----+ +----+ +-----------+ +-----+
+---+
|MNE|= Metering === = Meter. Configuration --- = Data Flow
+---+ Entity Signaling Messages
+--+
|MP| = Monitoring *** = other
+--+ Probe Signaling Messages
| Figure 1: Schematic Metering Architecture |
In this context two problems need to be solved, such as
In a flexible environment, it must be possible to dynamically configure and coordinate Metering Entities rather than hardwiring them. Configuration and coordination includes e.g. what entities do the metering for a particular flow or session, providing triggers to start or stop accounting, distribution of identifiers for the collector, flows or user, 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]Quittek, J., Zseby, T., Claise, B. and S. Zander, Requirements for IP Flow Information Export, October 2004.. RADIUS and DIAMETER allow for configuration of single Metering Entities. Nevertheless configuration and coordination of distributed Metering Entities is not supported.
Since Metering Entities usually are found along the path of the data they are accounting, a path-coupled signaling protocol for distributing such information seems useful. In Section 4Scenarios we discuss in more detail two possible applications for configuration of Metering Entities, namely QoS monitoring and charging.
| TOC |
This section describes three scenarios for the usage of the metering configuration protocol: charging, QoS monitoring, and monitoring for intrusion detection.
While flexible usage-based charging today is mainly a problem in mobile telecommunication networks such as 3GPP, it is expected to also play an important role in other networks in the future.
As a prerequisite to charging, Metering Entities along the data path independently need to collect Metering Data for the same session. For example, when streaming a video from an application server to a WLAN user, accounting may be performed independently by the application server, the WLAN access point and ingress nodes of several transit networks. When a handover occurs yet other, initially unforeseen, Metering Entities become involved. Yet, the user would like to be presented a single bill in the end. Even more difficult, the user may wish to know the total costs in advance. This implies Metering Data collected (or estimated) by the different Metering Entities needs to be correlated and aggregated in order to avoid the user pays duplicate fees. Metering Entities need to know to what collector they must send their Metering Data. A further problem of data correlation is the identification of related records by the collector.
Existing accounting concepts are based on static configuration of accounting entities [Ref 3GPP?]. Currently there exists no mechanism to provide dynamic discovery of Metering Entities with a unique correlation identifier related to one service.
Figure 2Signaling to configure metering for later charging shows an example where a data receiver expects data from a data sender via two routers Router 1 and Router 2. The administrative domain (referred as Accounting Domain) is responsible for configuring accounting functionality at Router 1, Router 2 and at the application server (i.e., data sender).
+------------------------------------------+
Data Receiver | Router 1 Router 2 Data Sender |
+-----------+ | +-----+ +-----+ +-----------+ |
|Application|<-----| |<----| |<----|Application| |
| +---+ | | |+---+| |+---+| | +---+ | |
| |MNE| | | ||MNE||<===>||MNE||<===>| |MNE| | |
| +---+ | | |+---+| |+---+| | +---+ | |
+-----------+ | +-----+ +-----+ +-----------+ |
| Metering Domain |
+------------------------------------------+
+---+
|MNE| = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
| Figure 2: Signaling to configure metering for later charging |
Different configuration needs arise for different use cases. In the case that a pure content charging scheme should be applied later, only the content accessed is relevant for later charging. For this case, only the AE at the Data Sender should be configured to register the content accessed. All other AEs should be instructed to do nothing since their Metering Data will be discarded anyway.
In other cases, the situation can be different. For the case where a mixed content and access charging should be applied, possibly due to the need to account the expensive wireless access between the receiver and Router 1, not only the content accessed but also the data volume are relevant for later charging. For this case, the AE at the Data Sender should be configured to register the content accessed. And, the AE at R1 should be configured to register data volume. All other AEs should do nothing.
When a network can provide QoS to its users it is important to be able to monitor whether the QoS provided matches the QoS initially negotiated in the according service level agreement. Such monitoring can be performed by monitoring probes and related Metering Entities on the data path. One possibility is installing and configuring these probes once-and-for-all. It would, however, be more convenient to be able to invoke the monitoring service on demand. Furthermore, one may want to configure the Metering Entities depending on the current monitoring needs.
+-----------------------------------------------------------+
| |
| Administrative Domain A |
| |
| Ingress Node A probe 1 probe 2 Egress Node B |
| +-----------+ +----+ +----+ +-----------+ |
| | |=====>| |=====>| |=====>| | |
| | | | | | | | | |
---->| MNE |----->| MNE|----->| MNE|----->| MNE |---->
| | | | | | | | | |
| +-----------+ +----+ +----+ +-----------+ |
| |
+-----------------------------------------------------------+
+---+
|MNE| = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
| Figure 3: Signaling to configure metering for QoS monitoring |
For example, network domain A negotiates a SLA with a neighboring domain, guaranteeing a particular QoS for all packets entering at ingress node A and leaving at egress node B. When the QoS guarantees are configured, e.g. with the QoS NSLP, one node on the data path, e.g. the ingress node, initiates the configuration of Metering Entities on the data path. Metering Data is used for monitoring whether the QoS negotiated in the SLA corresponds to the QoS delivered. For example, the transmission delay of flows can be measured at several places and the total delay across the domain can then be determined. The collected information is of interest for both domain A and the neighboring domain.
Many network security mechanisms such as intrusion detection are based on the capability to monitor network behavior. Such monitoring invloved either packet sampling, netflow accounting, or both. Typically, monitors are configured administratively. This leads to complex and failure-prone configurations. Additionally, there is no possibility to automatically reconfigure the monitoring based on upcoming requirements. In highly distributed intrusion detection solutions, which are currently work in progress, the requirement for automated configuration tasks becomes even stronger. Fur such purposes, the solution is a metering configuration signaling protocol such as M-NSLP.
+-----------------------------------------------------------+
| |
| Administrative Domain A |
| |
| +----------------------------+ |
| | Intrusion Detection System | |
| +----------------------------+ |
| ^ ^ ^ ^ |
| ** * * ** |
| ** * * ** |
| ** * * ** |
| ** * * ** |
| Ingress Node A probe 1 probe 2 Egress Node B |
| +-----------+ +----+ +----+ +-----------+ |
| | |=====>| |=====>| |=====>| | |
| | | | | | | | | |
---->| MNE |----->| MNE|----->| MNE|----->| MNE |---->
| | | | | | | | | |
| +-----------+ +----+ +----+ +-----------+ |
| |
+-----------------------------------------------------------+
+---+
|MNE|= Metering === = Meter. Configuration --- = Data Flow
+---+ Entity Signaling Messages
| Figure 4: Signaling to configure metering for intrusion detection |
In the given example, a specific communication should be investigated into. The ingress node A, forwards this request along the data path of the communication through the entire domain. All available Metering Entities (monitoring devices) are configured to focus on data packets belonging to the particular communication. Metered Data is transferred to the according intrusion detection system for further analysis.
The configuration of Metering Entities described in Section 4.1Charging, Section 4.2QoS Monitoring, and Section 4.3Intrusion Detection would include, among other things, the distribution of the following information:
| TOC |
This section describes the requirements for an efficient signaling of configuration parameters to Metering Entities. We assume an existing protocol to transport the collection of Metering Data
We also assume that the monitoring probes and the Metering Entities may be collocated.
The specification of the metering configuration protocol should be extensible to future technologies. This includes the extensibility of the configuration of the Metering Entities.
Extensibility is also required concerning the data model. This relates to the parameter exchange between the Metering Entities and the interface between the Metering Entities and the monitoring probes and the collector, respectively.
Multiple Metering Entities may be included in the overall accounting task. Also, they can be geographically widespread. The configuration process must be able to efficiently support hundreds of Metering Entities and to address them individually.
A number of accounting solutions may be defined in future in the IETF. Additionally, accounting solutions are specified by other organizations, e.g. the 3GPP. The metering configuration protocol should bridge between these solutions. The communication between the Internet accounting and monitoring and other Metering Entities may be organized using proxy or agent based systems.
Besides the discussion of the security considerations at the end of this document, it should be clarified that the process of configuring an Internet-wide accounting system is a very sensitive task. Therefore, arrangements should be taken to secure this process. It has to be noticed that this configuration step can pass domain borders as well as technology borders.
The metering configuration protocol should support a flexible accounting model. Depending on the accounting scenario, different information must be exchanged between the Metering Entities. For example, if the accounting is used for charging purposes, pricing information might be required at each Metering Entity in order to verify account balances etc. Therefore, the accounting model should be separated from the configuration process and the associated protocols.
A primary capability of the accounting 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 service life-time, statistics describing the resource consumptions of this service are gathered and exported to a collector. The accounting configuration should be flexible to allow the description of multiple services and associated flows (scalability).
Flows belonging to one application - the accounting configuration should allow the aggregation of accounting information for streams belonging to a particular application, e.g. a multimedia transmission with associated data transfers (web pages).
Flows belonging to one user - the accounting configuration should allow the aggregation of Metering Data for all streams belonging to an individual user regardless of the used applications.
After the gathering of Metering Data, it has to be transferred to a collector. The protocol for configuring Metering Entities MUST be independendt of the protocol used for transferring Metering Data. One possible protocol is IPFIX [I-D.ietf-ipfix-protocol]Claise, B., IPFIX Protocol Specifications, August 2004.. The IPFIX information model [I-D.ietf-ipfix-info]Meyer, J., Quittek, J. and S. Bryant, Information Model for IP Flow Information Export, July 2004. is very flexible for extentions and, therefore, adequate for this application.
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 problem how the initiator and receiver of the metering configuration signaling are determined.
Metering Entities can be located anywhere along the data path, e.g., only in a subset of the path, or only at start and end point etc.
The collector MAY be located on the data path. In this case, the collector SHOULD use the metering configuration protocol to inform all involved Metering Entities about its location.
The collector MAY be shifted during the accounting process. The handover process is not part of this document. The identification of the new collector SHOULD be done using the same mechanisms as for the first identification.
The protocol MUST be able to configure Metering Entities, e.g. 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.
The protocol should provide functionality to select Metering Entities that that become part of an accounting process by specifying e.g. their type or total number.
The protocol MUST be able to install accounting state and also to remove it. Furthermore, accounting state SHOULD be soft state in order to cope with rerouting and device failure.
The protocol MUST be able to transport a trigger to start and stop of collection of Metering Data, a correlation identifier that allows the collector to correlate Metering Data received from different metering entities, and a trigger to send off Metering Data to the collector.
The triggering source of the initiation is out of scope of this document.
The protocol MUST be able to react to rerouting of the packets that are to be accounted. This may imply including new Metering Entities and removing some.
The protocol SHOULD be able to collect information on Metering Entities and their capabilities without actually installing any state.
The protocol SHOULD 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 originating in the core of the network at the access router in order to both save resources on the air interface and to hide monitoring or charging configuration data from the user. Another example is scoping the signaling e.g. to the responsible UMTS GGSN because it is known that MNEs beyond the GGSN are of no interest for this particular metering configuration.
Metering configuration SHOULD be possible across administrative domains. There are challenging security aspects in this goal.
| TOC |
According to the NSIS framework [I-D.ietf-nsis-fw]Hancock, R., Karagiannis, G., Loughney, J. and S. Van den Bosch, Next Steps in Signaling: Framework, July 2004., 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. Thereby, not every network node has to be NSIS aware. The signaling protocol messages however 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 NSIS protocol suite has two layers. The lower transport layer, NTLP, is responsible for transporting NSIS messages and is used by all NSIS signaling application. The NSIS signaling applications are located in the upper layer and are called NSLPs. Examples of NSLPs that are currently being specified are QoS NSLP [I-D.ietf-nsis-qos-nslp]Van den Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004. for signaling QoS reservations and the NAT / Firewall NSLP [I-D.ietf-nsis-nslp-natfw]Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, NAT/Firewall NSIS Signaling Layer Protocol (NSLP), July 2004. for configuring Network Address Translaters and firewalls along the data path.
The problem of signaling to configure Metering Entities seems to be well suited to be solved with a novel NSIS signaling application, the Metering NSLP. A similar idea was first reported in [I-D.couturier-nsis-sqm]Couturier, A., Signaling for QoS Measurement, May 2003.. The Metering NSLP needs to be able to install, modify and remove metering configuration related state. As illustrated in previous sections, Metering Entities - which are to become Metering NSLP Entities - are naturally located on the data path where accounting has to be performed. Furthermore, signaling for metering configuration needs the flexibility provided by NSIS to commence and end on arbitrary Metering Entities. Any Metering Entity on the data path has to be able to initiate metering configuration signaling. The selection of signaling initiator and receiver depends on the configuration and on the specific application environment. An Metering NSLP, similar to QoS NSLP, would be agnostic of the actual configuration information it carries. Hence it can be used for any accounting application, such as QoS monitoring and charging. In fact, it currently seems that some of the QoS NSLP message structure (RESERVE (i.e. CONFIGURE), RESPONSE, QUERY and NOTIFY) could be reused.
Possible interworking between the Metering NSLP and the QoS NSLP needs to be investigated. In some cases it seems to make sense that a reservation of resources via the QoS NSLP would trigger the configuration and initiation of metering for usage of these resources. Furthermore, accounting can be terminated as soon as the QoS reservation is torn down.
| TOC |
The basic design of a Metering NSLP and the processing of Metering NSLP messages is quite similar to QoS NSLP. In fact much of the subsequent text is modeled after the corresponding text in [I-D.ietf-nsis-qos-nslp]Van den Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004.. The main difference compared to QoS NSLP is that Metering NSLP allows individual Metering NEs (MNEs) to pull out of a sigaling session.
Figure 5Metering-NSLP in a Metering Entity shows an example logical model of the operation of Metering NSLP and the associated metering mechanism in a MNE.
+---------------+ ^
| Local | *
| Management | *
+---------------+ *
^ *
V *
+----------+ +----------+ +---------+ *
| M-NSLP | | Metering | | Policy | *
|Processing|<<<<>>>>>|Management|<<>>| Control | *
+----------+ +----------+ +---------+ *
. ^ | V V *
| ^ . V V ................
| V . V >>>>>>. Metering .
| V . V . Entity .
+----------+ V . +---------+ .
| GIMPS | V . | Metering| .
|Processing| V *> . | Data | .
+----------+ V * . +---------+ .
| | V * ................
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . V *
+----------+ +-----------+ +------------+
<-.-| Input | | Outgoing |-.-| Monitoring |-.-.-.-.-.-.-.->
| Packet | | Interface | | Probe |
===>|Processing|====| |===| |===============>
+----------+ +-----------+ +------------+
<.-.-> = signalling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
*****> = Measurement resp. Metering Data
| Figure 5: Metering-NSLP in a Metering Entity |
In this example, the MNE is collocated on a single node with a Metering Entity and one Monitoring Probe (MP, cf. Figure 1Schematic Metering Architecture). The MP collects Measurement Data which is handed to the Metering Entity where it is processed to become Metering Data. From the Metering Entity, Metering Data is sent to a Collector as previously illustrated in Figure 1Schematic Metering Architecture
A M-NSLP message transports metering configuration information. This information is extracted by M-NSLP Processing and 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 Metering Entity and the Monitoring Probe. The Policy Control determines whether the sender of the M-NSLP message has administrative rights to configure the Metering Entity. When comparing Figure 5Metering-NSLP in a Metering Entity to the corresponding Figure 1Schematic Metering Architecture in [I-D.ietf-nsis-qos-nslp]Van den Bosch, S., Karagiannis, G. and A. McDonald, NSLP for Quality-of-Service signaling, July 2004. it is obvious that the basic NSLP message processing is identical.
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.
The Metering NSLP uses four message types:
- CONFIGURE
The CONFIGURE message is the only message that manipulates M-NSLP Configuration State. It is used to create, refresh, modify and remove such state. The CONFIGURE message is idempotent; the resultant effect is the same whether a message is received once or many times. In fact this message is equivalent to the QoS NSLP RESERVE message.
- QUERY
A QUERY message is used to request information about the current configuration without changing it. The QUERY message is impotent, because it does not cause any state to be installed or modified. It is equivalent to the QoS NSLP QUERY message.
- 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 QUERY 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 impotent, and equivalent to the QoS NSLP RESPONSE message.
- NOTIFY
NOTIFY messages are used to convey information to a MNE. They differ from RESPONSE messages in that they are 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. Obviously it is equivalent to the QoS NSLP NOTIFY message.
Each protocol message has a common header which indicates the message type and contains flags. 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 or whether a response is required.
- Metering specification (MSpecs)
MSpec objects describe the actual Configuration information. They are interpreted in the Metering Manager and opaque to M-NSLP Processing.
- Policy objects
Policy objects contain data used to authorise the configuration of the MNEs. They are interpreted by Policy Control.
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. It is for further study whether life time of M-NSLP state for a particular flow must be the same for all MNEs along the signaling path as in NATFW-NSLP [I-D.ietf-nsis-nslp-natfw]Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, NAT/Firewall NSIS Signaling Layer Protocol (NSLP), July 2004., or whether it is a decision local to pairs of MNEs as in QoS-NSLP. In fact the refreshment mechanism depends on the authorization model. Currently, it is expected that the the authorization model follows that in QoS NSLP (“New Jersey Turnpike”, i.e. a chain-of-trust is established by peering relationships between neighboring networks / entities). Therefore, the refreshing model probably will be similar to that of QoS NSLP.
The order in which CONFIGURE messages arrive influences the eventual reservation state that will be stored at a MNE. Therefore M-NSLP supports the detection of CONFIGURE message reordering or duplication by means of a Configuration Sequence Number (CSN), which corresponds to the Reservation Sequence Number (RSN) of QoS-NSLP.
In order to realize the requirement in Section 5.7.6Scoping of configuration, namely scoping of M-NSLP messages up to certain types of Metering Entities, it is necessary to have an abstract language that can name Metering Entity types. This information travels in the MSpec and is hence interpreted in the Metering Management. When the Metering Management recognizes it is responsible for a Metering Entity of the type specified, it informs M-NSLP processing to terminate the signaling.
M-NSLP automatically adapts to rerouting events because state along the old path times out, and a refreshing CONFIGURE message will install state along the new path. In QoS NSLP it is necessary to detect a rerouting event in order establish state on the new path, and to tear down reservations on the old path. To this end, QoS NSLP introduces an additional object, the SII. When the SII received by a QNE changes, a rerouting event has occurred.
For M-NSLP it is generally not important to quickly tear down configuration state along the old path, however for some applications, e.g. charging, it is vital to quickly configure MNEs on the new path. Therefore an object equivalent to the SII is needed.
An interesting feature of M-NSLP is that only a subset of MNEs on the data path may take part in the actual metering, see Section 5.7.2Selection of Metering Entities. Metering Entities taking part in the metering process are determined based e.g. on their type or number. This feature is the most striking difference to 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 by inspecting the MSpec object. Here we can reuse the ability from above to abstractly name types of Metering Entities. When the MNE finds out it is not involved in the metering it should remove itself from the signaling session for this flow. This however implies it is difficult to later update this signaling session to again include the MNE, simply because it is not going to read the updating CONFIGURE message. See the discussion on implications for the GIMPS API in Section 7.4Implications for GIMPS API.
According to Section 5.3Distinguishing flows, the metering configuration should allow aggregation of Metering Data belonging to e.g. the same user or application. Such aggregation can be done in two ways.
The basic signaling sequences are very similar to QoS NSLP: To start a configuration, the MNI constructs a CONFIGURE message with a MSpec object, and sends it to the MNR. The message is interpreted by MNEs on the data path. The MNR replies with a RESPONSE message.
Similarly, a QUERY message can be initiated by MNI or MNR, travels to the MNR resp. MNI where a RESPONSE is issued and sent back. It needs to be investigated whether there is a use case for enabling any MNE to issue a QUERY which in this case would need to be sent both upstream and downstream.
In [I-D.ietf-nsis-ntlp]Schulzrinne, H. and R. Hancock, GIMPS: General Internet Messaging Protocol for Signaling, July 2004., an API is defined between GIMPS and NSLPs. The requirement to flexibly select what Metering Entities become part of a given signaling session (see Section 5.7.2Selection of Metering Entities and Section 7.2.2.5Selection of MNEs) implies requirements on the API that may currently not be covered.
With the design described above, the requirements from Sec 5 are at this point satisfied as follows:
Requirements not mentioned in this list are not yet addressed.
| TOC |
The process of configuring entities to start and stop metering and to transmit collected resource records to a third party introduces security challenges.
First, the application domain needs to be considered. If a malicous user is capable of stop metering of requested services then fraud is possible. It must not be 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.
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.
Third, it must be avoided that a denial of service attack is mounted on either Collectors or Metering Entities. Metering Entities 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 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. The authorization configuration of a decentralized approach is more difficult to secure since a single malicious entity is able to start/stop/modify the process of Metering Record collection within a single domain or even beyond this domain.
| TOC |
Details need to be worked out how the configuration information in the MSpec is expressed, and how it is interpreted.
For example, the the MSpec could specify exactly one Metering Entity of a particular type X, e.g. one that is able to measure bandwidth received, should participate in the metering. This implies
However, appropriate action needs to be taken if the signaling arrives at the MNR and no Metering Entity of type X was found. Furthermore, when a rerouting event occurs, and MNE_X is no longer on the signaling path, this needs to be detected, and a replacement must be found. Support of such functionality is not necessary in QoS NSLP. It is possible that on this basis more design differences between QoS NSLP and M-NSLP will be detected in the future.
Additional open issues appear in the main body of the text.
| TOC |
The authors would like to thank Robert Hancock for valuable input.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| TOC |
| [RFC2629] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999 (TXT, HTML, XML). |
| [RFC2720] | Brownlee, N., "Traffic Flow Measurement: Meter MIB", 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 Specifications", draft-ietf-ipfix-protocol-05 (work in progress), August 2004. |
| [I-D.ietf-ipfix-info] | Meyer, J., Quittek, J. and S. Bryant, "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-04 (work in progress), July 2004. |
| [RFC3917] | Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004. |
| [I-D.ietf-nsis-qos-nslp] | Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-04 (work in progress), July 2004. |
| [I-D.ietf-nsis-fw] | Hancock, R., Karagiannis, G., Loughney, J. and S. Van den Bosch, "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-06 (work in progress), July 2004. |
| [I-D.ietf-nsis-nslp-natfw] | Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July 2004. |
| [I-D.ietf-nsis-qspec] | Ash, J., Bader, A. and C. Kappler, "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-01 (work in progress), October 2004. |
| [I-D.ietf-nsis-ntlp] | Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-03 (work in progress), July 2004. |
| [I-D.couturier-nsis-sqm] | Couturier, A., "Signaling for QoS Measurement", draft-couturier-nsis-measure-00 (work in progress), May 2003. |
| [I-D.ietf-aaa-diameter-cc] | Hakala, H., Mattila, L., Koskinen, J., Stura, M. and J. Loughney, "Diameter Credit-control Application", draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. |
| [I-D.draft-lior-radius-prepaid-extensions-03] | Lior, A., Yegani, P., Chowdhury, K. and Y. Li, "PrePaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", draft-lior-radius-prepaid-extensions-05 (work in progress), July 2004. |
| [TS32.240] | 3GPP, "Charging Architecture and Principles", 3GPP Technical Specification TS32.240, December 2003. |
| TOC |
| 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/ |
| 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/ |
| Changpeng Fan | |
| Siemens AG | |
| Siemensdamm 62 | |
| Berlin 13627 | |
| Germany | |
| Phone: | +49 30 386-36361 |
| EMail: | changpeng.fan@siemens.com |
| 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 |
| TOC |
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.
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 (C) The Internet Society (2004). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.