Status of this Memo

By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 January 9, 2005.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

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 which allows the dynamic configuration of accounting entities on the data path. A problem statement, scenarios for a QoS monitoring and a charging application, and requirements presented. Finally, the usage of NSIS for this purpose is motivated.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Statement
4.  Scenarios
    4.1  Charging
    4.2  QoS Monitoring
    4.3  Configuration information common to both 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 accounting model
    5.3  Distinguishing flows
    5.4  Flexible data collection
    5.5  Location of accounting entities
    5.6  Location of the collector
    5.7  Configuration protocol
        5.7.1  Configuration of accounting entities
        5.7.2  Selection of accounting entities
        5.7.3  Accounting Configuration State installation and removal
        5.7.4  Initiation and maintenance of accounting tasks
        5.7.5  Collection of information on available accounting entities
    5.8  Accounting across domains
6.  Applicability of NSIS
7.  Security considerations
§.  Normative References
§.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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. 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., Madour, L. and Y. Li, PrePaid Extensions to Remote Authentication Dial-In User Service (RADIUS), February 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]Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. Hakala, Diameter Credit-control Application, May 2004.) are also protocols which provide information about consumed resources via accounting 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 accounting. In more complex network topologies and architectures these entities are not only located at the edges of a network. Instead, these accounting 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 Accounting NSLP for configuration and coordination of accounting 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 accounting entities in Section 6Applicability of NSIS.

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]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..

Furthermore, this document uses the following terms:

Accounting Data

Accounting 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.

Accounting Record

An accounting record represents aggregated and/or correlated accounting data.

Monitoring Probe

A monitoring probe is an entity that examines the data flow in order to gather accounting data. This accounting data is exported to an accounting entity.

Accounting entity

An accounting entity produces accounting data describing the resource utilization of a particular flow or service. Typically, this information is collected from accociated monitoring probes.

Collector

A collector receives accounting data from one or multiple accounting entities. This accounting data is aggregated, correlated, and stored in form of accounting records.

3. Problem Statement

There is a need in industry and the Internet research community to collect and export information on data flows. We call such information accounting records. Accounting 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 accounting records in each case is different, the basic architecture of such accounting systems is usually identical, cf. Figure 1Schematic Accounting Architecture. Measurement data is collected by a monitoring probe, and from there transported to an accounting entity. The accounting entity produces accounting data from the measurement data or additional data such as session information. Monitoring probe and accounting entity may be collocated, and one accounting entity may control several monitoring probes; in any event the monitoring probe is controlled by an accounting entity. The accounting entity transmits its accounting data to the actual collector. The collector correlates accounting data relating to the same event from different accounting entities and produces an accounting record. There may be more than one collector depending on the actual tasks.

         
                          +-----------------+
                          | Collector       |
                          | +-------------+ |
                          | | Acc. Record | |                        
                          | +-------------+ | 
                          +-----------------+
                                ^ ^ ^ ^
                         ****    *   *    ****
                    ****       *       *       ****
               ****          *           *          ****
          ****             *               *             ****
    +-----------+    +-----------+    +-----------+    +-----------+
    |    +-----+|    |    +-----+|    |    +-----+|    |    +-----+|
===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===>| AE | Acc.||===>
    |    | Data||    |    | Data||    |    | Data||    |    | Data||
    |    +-----+|    |    +-----+|    |    +-----+|    |    +-----+|
    +-----------+    |           |    +-----------+    +-----------+
       ^    ^        |           |          ^
       *    *        |           |          *                
    +----+ +----+    |           |       +-----+
--->| MP | | MP |--->| MP        |------>| MP  |----------------------->
    +----+ +----+    +-----------+       +-----+
                                                             
    +--+
    |AE| = Accounting   === = Acc. Configuration   --- = Data Flow
    +--+   Entity             Signaling Messages                   

    +--+
    |MP| = Monitoring   *** = other
    +--+   Probe              Signaling Messages        

In this context two problems need to be solved, such as

• measurement data needs to be transported from the monitoring probes to the accounting entities. Accounting data needs to be transported from the accounting entities to the collector. [I-D.ietf-ipfix-protocol]Claise, B., Fullmer, M., Calato, P. and R. Penno, IPFIX Protocol Specifications, January 2004. is a protocol suitable for this task.
• The accounting entities need to be configured and coordinated. This document suggests the usage of NSIS for this purpose.

In a flexible environment, it must be possible to dynamically configure and coordinate accounting entities rather than hardwiring them. Configuration and coordination includes e.g. what entities do the accounting 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" [I-D.ietf-ipfix-reqs]Quittek, J., Zseby, T., Claise, B. and S. Zander, Requirements for IP Flow Information Export, June 2004.. RADIUS and DIAMETER allow for configuration of single accounting entities. Nevertheless configuration and coordination of distributed accounting entities is not supported. Since accounting 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 accounting entities, namely QoS monitoring and charging.

4. Scenarios

This section describes two scenarios for the usage of the Accounting NSLP: Charging and QoS monitoring

4.1 Charging

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, accounting entities along the data path independently need to collect accounting 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, accounting 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 accounting data collected (or estimated) by the different accounting entities needs to be correlated and aggregated in order to avoid the user pays duplicate fees. Accounting entities need to know to what collector they must send their accounting 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 accounting entities with a unique correlation identifier related to one service.

Figure 2Signaling to configure accounting 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|   |
|   +--+    |   |  |+--+|      |+--+|      |   +--+    |   |
|   |AE|    |   |  ||AE||<====>||AE||<====>|   |AE|    |   |
|   +--+    |   |  |+--+|      |+--+|      |   +--+    |   |
+-----------+   |  +----+      +----+      +-----------+   |
                |            Accounting Domain             |
                +------------------------------------------+ 
 
    +--+ 
    |AE| = Accounting   === = Signaling    --- = Data Flow 
    +--+   Entity             Messages             
           

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 accounting 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.

4.2 QoS Monitoring

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 accounting 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 accounting entities depending on the current monitoring needs.

    +-----------------------------------------------------------+
    |                                                           |
    |                 Administrative Domain A                   |
    |                                                           |
    |  Ingress Node A    probe 1     probe 2      Egress Node B |
    | +-----------+      +----+      +----+      +-----------+  |
    | |           |=====>|    |=====>|    |=====>|           |  |
    | |           |      |    |      |    |      |           |  |
 ---->|   AE      |----->| AE |----->| AE |----->|    AE     |---->
    | |           |      |    |      |    |      |           |  |
    | +-----------+      +----+      +----+      +-----------+  |
    |                                                           |
    +-----------------------------------------------------------+

    +--+ 
    |AE| = Accounting   === = Signaling    --- = Data Flow 
    +--+   Entity             Messages             
           

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 accounting entities on the data path. Accounting 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.

4.3 Configuration information common to both scenarios

The configuration of accounting entities described in Section 4.1Charging and Section 4.2QoS Monitoring would include, among other things, the distribution of the following information:

• which accounting entries have to register usage data
• what type of data to collect (e.g. count packets, measure delay etc.)
• data related to what flows to collect
• which usage data need to be transferred from accounting entities to a collector (i.e., flow identifier)
• the identity of the collector to which usage data is to be delivered
• a correlation ID which allows the collector to correlate the flow data arriving from different accounting entities
• description of the trigger when to start and stop accounting

5. Requirements

This section describes the requirements for an efficient signaling of configuration parameters to accounting entities. We assume an existing protocol to transport the collection of accounting data

(a) between the monitoring probe and the accounting entity and

(b) between the accounting entity and a collector.

The IPFIX protocol [I-D.ietf-ipfix-protocol]Claise, B., Fullmer, M., Calato, P. and R. Penno, IPFIX Protocol Specifications, January 2004. has all the required capabilities to fulfill the functionality required by (a). We also assume that the monitoring probes and the accounting entities may be collocated.

5.1 General requirements

5.1.1 Extensibility

The NSLP accounting specification should be extensible to future technologies. This includes the extensibility of the configuration of the accounting entities.

Extensibility is also required concerning the data model. This relates to the parameter exchange between the accounting entities and the interface between the accounting entities and the monitoring probes and the collector, respectively.

5.1.2 Scalability

Multiple accounting 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 accounting entities and to address them individually.

5.1.3 Interoperability

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 accounting NSLP should bridge between these solutions. The communication between the Internet accounting and monitoring and other accounting entities may be organized using proxy or agent based systems.

5.1.4 Security

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.

5.2 Flexible accounting model

The accounting NSLP should support a flexible accounting model. Depending on the accounting scenario, different information must be exchanged between the accounting entities. For example, if the accounting is used for charging purposes, pricing information might be required at each accounting entity in order to verify account balances etc. Therefore, the accounting model should be separated from the configuration process and the associated protocols.

5.3 Distinguishing flows

A primary capability of the accounting function is the identification of data packets belonging to different applications or users. The configuration of the accounting 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 accounting data for all streams belonging to an individual user regardless of the used applications.

5.4 Flexible data collection

After the gathering of accounting data, it has to be transferred to a collector. We propose to employ the IPFIX protocol [I-D.ietf-ipfix-protocol]Claise, B., Fullmer, M., Calato, P. and R. Penno, IPFIX Protocol Specifications, January 2004. for this task. The IPFIX information model [I-D.ietf-ipfix-info]Calato, P., Meyer, J. and J. Quittek, Information Model for IP Flow Information Export, February 2004. is very flexible for such application.

Depending on the accounting scenario, a single collector can be responsible for collecting and processing all accounting information. Nevertheless, there are scenarios where multiple collectors have to be employed.

5.5 Location of accounting entities

The accounting entities are located on the data path, i.e., on the path of the data that should be accounted. The configuration of accounting entities can be initiated anywhere on this path. It is an open problem how the initiator and receiver of the accounting configuration signaling are determined.

Accounting 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.

5.6 Location of the collector

The collector MAY be located on the data path. In this case, the collector SHOULD use the accounting NSLP to inform all involved accounting 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.

5.7 Configuration protocol

5.7.1 Configuration of accounting entities

The protocol MUST be able to configure accounting 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 accounting entities.

5.7.2 Selection of accounting entities

The protocol should provide functionality to select accounting entities that that become part of an accounting process by specifying e.g. their type or total number.

5.7.3 Accounting Configuration State installation and removal

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.

5.7.4 Initiation and maintenance of accounting tasks

The protocol MUST be able to transport a trigger to start and stop of collection of accounting data, a correlation identifier that allows the collector to correlate accounting data received from different accounting entities, and a trigger to send off accounting 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 accounting entities and removing some.

5.7.5 Collection of information on available accounting entities

The protocol SHOULD be able to collect information on accounting entities and their capabilities without actually installing any state.

5.8 Accounting across domains

Accounting configuration MUST be possible across administrative domains. There are challenging security aspects in this goal.

6. Applicability of NSIS

According to the NSIS framework [I-D.ietf-nsis-fw]Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J. and S. Van den Bosch, Next Steps in Signaling: Framework, October 2003., 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, May 2004. for signaling QoS reservations and the NAT / Firewall NSLP [I-D.ietf-nsis-nat-nslp]Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, NAT/Firewall NSIS Signaling Layer Protocol (NSLP), May 2004. for configuring Network Address Translaters and firewalls along the data path.

The problem of signaling to configure accounting entities seems to be well suited to be solved with a novel NSIS signaling application, the Accounting NSLP. A similar idea was first reported in [I-D.courturier-nsis-sqm]Courturier, A., Signaling for QoS Measurement, May 2003.. The Accounting NSLP needs to be able to install, modify and remove accounting configuration related state. As illustrated in previous sections, accounting entities - which are to become Accounting NSLP Entities - are naturally located on the data path where accounting has to be performed. Furthermore, signaling for accounting configuration needs the flexibility provided by NSIS to commence and end on arbitrary accounting entities. Any accounting entity on the data path has to be able to initiate accounting configuration signaling. The selection of signaling initiator and receiver depends on the configuration and on the specific application environment. An Accounting 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 Accounting 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 accounting for usage of these resources. Furthermore, accounting can be terminated as soon as the QoS reservation is torn down.

7. Security considerations

The process of configuring entities to start and stop accounting 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 accounting of requested services then fraud is possible. It must not be possible to configure accounting 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 accounting 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 Accounting Entities. Accounting 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 accounting records.

The introduced mechanisms allow a number of entities to configure accounting 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 accounting record collection within a single domain or even beyond this domain.

8. References

8.1 Normative References

8.2 Informative References

Authors' Addresses

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 (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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.