Network Working Group A. Fessi Internet-Draft University of Tuebingen Expires: August 18, 2005 C. Kappler C. Fan Siemens AG F. Dressler University of Erlangen A. Klenk University of Tuebingen February 14, 2005 Framework for Metering NSLP Status of this Memo 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 August 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 1] Internet-Draft M-NSLP Framework February 2005 This document describes an architectural framework for a new NSLP, which allows the dynamic configuration of Metering Entities on the data path to record monitoring and measurement data and report it to a data collector. Different scenarios are described where such a path-coupled configuration of the Metering Entities can be useful. Currently, the focus is on three scenarios: metering for accounting, QoS monitoring and monitoring for network security. Moreover, this document suggests the appropriate parameters to be configured for each scenario. Furthermore, it gathers requirements for a path-coupled configuration protocol of Metering Entities. Finally, the applicability of the NSIS architecture for this purpose is discussed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1 Scenario Description . . . . . . . . . . . . . . . . . 6 4.1.2 Required Parameters . . . . . . . . . . . . . . . . . 8 4.2 QoS Monitoring . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1 Scenario Description . . . . . . . . . . . . . . . . . 10 4.2.2 Configuration Parameters . . . . . . . . . . . . . . . 13 4.3 Monitoring for Network Security . . . . . . . . . . . . . 14 4.3.1 Scenario Description . . . . . . . . . . . . . . . . . 14 4.3.2 Required Parameters . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1 General requirements . . . . . . . . . . . . . . . . . . . 17 5.1.1 Extensibility . . . . . . . . . . . . . . . . . . . . 17 5.1.2 Scalability . . . . . . . . . . . . . . . . . . . . . 17 5.1.3 Security . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Flexible metering model . . . . . . . . . . . . . . . . . 18 5.3 Distinguishing flows . . . . . . . . . . . . . . . . . . . 18 5.4 Flexible data collection . . . . . . . . . . . . . . . . . 18 5.5 Location of Metering Entities . . . . . . . . . . . . . . 18 5.6 Location of the Collectors . . . . . . . . . . . . . . . . 19 5.7 Configuration protocol . . . . . . . . . . . . . . . . . . 19 5.7.1 Configuration of Metering Entities . . . . . . . . . . 19 5.7.2 Selection of Metering Entities . . . . . . . . . . . . 19 5.7.3 Metering Configuration State installation and removal . . . . . . . . . . . . . . . . . . . . . . . 19 5.7.4 Initiation and maintenance of metering tasks . . . . . 20 Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 2] Internet-Draft M-NSLP Framework February 2005 5.7.5 Reaction to Route Changes . . . . . . . . . . . . . . 20 5.7.6 Collection of information on available Metering Entities . . . . . . . . . . . . . . . . . . . . . . . 20 5.7.7 Scoping of configuration . . . . . . . . . . . . . . . 20 5.8 Metering across domains . . . . . . . . . . . . . . . . . 20 6. Applicability of the NSIS Architecture . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1 Normative References . . . . . . . . . . . . . . . . . . . 22 10.2 Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 26 Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 3] Internet-Draft M-NSLP Framework February 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 (IP Flow Information Export) Working Group defines a protocol to collect such data and report it ([I-D.ietf-ipfix-protocol]). However, it is also necessary to configure and coordinate the entities doing the metering. If we are interested in one or more Metering Entities to meter a specific flow, then all potential candidates for this task are on the path used by this particular flow. They can easily be addressed by sending a configuration message along the path of the flow. If more than one Metering Entity is required, all of them can potentially be configured with a single message along the path. The Metering Entities can do either statistics on these flows, packet sampling or some other special treatment for the packets, for example, examining the packet payload. The Metering Entities can be configured and can be coordinated to achieve a certain goal together, which can be, for example, accounting, QoS monitoring or monitoring for network security. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Furthermore, this document uses the terms "Metering Data", "Metering Record", "Monitoring Probe", "Metering Entity", "Collector", "MNE", "MNI", "MNR" as defined in [I-D.dressler-nsis-metering-nslp]. 3. Problem Statement There is a need in industry and the Internet research community to collect and export information on data flows. We call such information Metering Records. Metering Records are useful in mediation systems, accounting systems, and network management systems 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 metering the IPFIX WG was founded. While the purpose for collecting Metering Records in each case is different, the basic architecture of such metering systems is usually Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 4] Internet-Draft M-NSLP Framework February 2005 identical, cf. Figure 1. Measurement data is collected by a Monitoring Probe, and from there reported to a Metering Entity. The Metering Entity produces Metering Data from the measurement data or additional data such as session information. Monitoring Probe and Metering Entity are co-located. One Metering Entity may control several Monitoring Probes; in any event the Monitoring Probe is controlled by a 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 a Metering Record. There might be more than one Collector depending on the actual tasks. +-----------------+ | Collector | | +-------------+ | | | Met. Record | | | +-------------+ | +-----------------+ ^ ^ ^ ^ ^ *** * *** *** * *** *** * *** *** * *** +-------------+ +-----------+ +-------------+ | +-----+ | | +-----+ | | +-----+ | | | ME | | | | ME | | | | ME | | | +-----+ | | +-----+ | | +-----+ | ===>| ^ ^ |===>| ^ |===>| ^ ^ | | / \ | | | | | / \ | --->| / \ |--->| | |--->| / \ | |+----+ +----+| | +----+ | |+----+ +----+| || MP | | MP || | | MP | | || MP | | MP || |+----+ +----+| | +----+ | |+----+ +----+| +-------------+ +-----------+ +-------------+ +---+ |ME |= Metering === = Meter. Configuration --- = Data Flow +---+ Entity Signaling Messages +--+ |MP| = Monitoring *** = other +--+ Probe Signaling Messages Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 5] Internet-Draft M-NSLP Framework February 2005 Figure 1: Schematic Metering Architecture In this context two problems need to be solved: o Measurement data need to be reported from the Monitoring Probes to the Metering Entities and Metering Data need to be transported from the Metering Entities to the Collector. IPFIX is a protocol suitable for this task. o The Metering Entities need to be configured and coordinated. This document suggests path-coupled signaling for this purpose. In a flexible environment, it must be possible to dynamically configure and coordinate Metering Entities rather than hardwiring them. Configuration and coordination includes, for example, what entities do the metering for a particular flow or session, providing triggers to start or stop metering, 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]. The configuration can be performed, for example, using RADIUS ([RFC2138]) or DIAMETER ([RFC3588]). The PSAMP (Packet Sampling) WG is also currently developing a MIB module for configuring packet sampling ([I-D.ietf-psamp-mib]). Nevertheless, all these alternatives allow only the configuration of single Metering Entities, and assume that the location of the Metering Entities to be configured is known before. Configuration and coordination of distributed Metering Entities is not supported. Since the most appropriate Metering Entities for metering a specific flow are located along the same path as the flow itself, a path-coupled signaling protocol for distributing the configuration information seems useful. 4. Scenarios This section describes three scenarios for the usage of path-coupled configuration of Metering Entities: accounting, QoS monitoring, and monitoring for network security. 4.1 Accounting 4.1.1 Scenario Description 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, one or more Metering Entities along the data path independently need to collect Metering Data for the Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 6] Internet-Draft M-NSLP Framework February 2005 same session. For example, when streaming a video from an application server to a WLAN user, there are several possible Metering Entities: the application server, the WLAN access point and the ingress nodes of several transit networks. When a handover occurs yet other Metering Entities become involved, for example the new WLAN access point. Yet, the user would like to be presented a single bill in the end. This implies Metering Data collected 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 which 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 handle multiple Metering Entities by statically configuring them. Data correlation is performed by hardwiring one Metering Entity to generate a correlation ID, and by manually configuring a chain of Metering Entities to which this correlation ID is distributed. This is inflexible and leads to unnecessary overhead because all charging scenarios are handled the same way. The problem is illustrated in Figure 2 where a data receiver expects data from a data sender via two routers Router 1 and Router 2. The administrative domain (referred as Metering Domain) is responsible for configuring metering 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| | | +---+ | | |+---+| |+---+| | +---+ | | | |ME | | | ||ME ||<===>||ME ||<===>| |ME | | | | +---+ | | |+---+| |+---+| | +---+ | | +-----------+ | +-----+ +-----+ +-----------+ | | Metering Domain | +------------------------------------------+ +---+ |ME | = Metering === = Signaling --- = Data Flow +---+ Entity Messages Figure 2: Signaling to configure metering for accounting Different configurations are appropriate for different charging scenarios. In the case of a pure content charging scheme, only the Metering Entity at the Data Sender (Application Server) needs to Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 7] Internet-Draft M-NSLP Framework February 2005 perform metering. All other Metering Entities should be instructed to do nothing since their Metering Data will be discarded anyway. In 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. In this case, the Metering Entity at the Data Sender should be configured to account the content accessed, and the Metering Entity at Router 1 must be configured to count bytes. Furthermore, a correlation ID must be generated by one of the active Metering Entities and sent to the other one. When a handover occurs, this correlation ID must be sent to the new access router. 4.1.2 Required Parameters In a client/server environment the Application Server (for example, a video streaming server) acts as signaling initiator. It sends a CONFIGURE message towards the user terminal. The Metering Entities along the path evaluates this message. Given that the user terminal can not be seen as a trusted network function, the signaling will travel until the last router before the user terminal which might be, for instance, a WLAN access point. This router acts as a signaling responder. The parameters that need to be configured with the CONFIGURE message are the following: Correlation ID This parameter refers to an ID which is unique for each service. It will be used by the Collector to assign different accounting records to the same service. Flow ID This parameter identifies the data flow(s) that need(s) to be accounted. Here, the flow information from the NTLP can be used. However, several entries SHOULD be possible for this parameter to enable configuring the Metering Entities to perform accounting for several flows (for instance audio and video) using a single M-NSLP message. Note here that multiple entries for the Flow ID are also possible in both the QoS NSLP and the NAT/FW NSLP. (In the NAT/FW NSLP, it is the "Number of Ports" in the "Extended Flow Information Object") Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 8] Internet-Draft M-NSLP Framework February 2005 Metering Objects This parameter contains a list of the objects that need to be accounted for the considered data flow. Potential objects are: 1. Flow Properties: These are dynamic properties of the data stream to be metered: + number of observed packets of the flow + number of observed octets of the flow + timestamp of first observation of a packet of the flow. + timestamp of last observation of a packet of the flow. 2. Events: service invocation, loss of bearer, insertion of advertisements and other app events. Note that in the timestamps, the absolute time might be required since the tariffs might depend on the time of the day. Reporting Interval In order to reduce the number of export messages sent to the Collector, it is advantageous not to send accounting data immediately but to wait until the message is filled with a certain amount of data. This parameter indicates the maximum time to wait for more data until an exported data set is sent. Long living flows are reported regularly in interval no longer than specified by this parameter. When the flow is reported, all counters and time stamp values are reset. Flow Expiration Time If no packets are observed for the specified amount of time interval, the flow is considered as expired and it is reported. Collector ID This parameter specifies where the accounting records need to be sent to. Reporting Protocol This parameter specifies which protocol to use to report the accounting data, for example, IPFIX, Netflow5 or Netflow9. SelectionOfMeteringEntities This parameter specifies how the Metering Entities that are requested to perform the accounting of the considered data flow Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 9] Internet-Draft M-NSLP Framework February 2005 are elected. Possible parameters for this parameter are: * any: any Metering Entity on the path that is capable of performing accounting with the requested objects in the parameter "Accounting Objects" is requested do it. In the extreme case, this could be the signaling initiator itself. * any N: N Metering Entities should be arbitrarily chosen to perform accounting. * first * last * least loaded: in this case the Metering Entities need to exchange information about their current load. A single CONFIGURE message is not sufficient to commit the configuration. * N least loaded: here also, the Metering Entities need to exchange information about their current load. Note here that depending on the packet loss rate along the path, there might be a considerable difference between the accounting records from the first Metering Entity and the last Metering Entity. Note also that the cases "any N" and "N least loaded" can be used, for instance, for redundancy to verify the correctness of the accounting records delivered by different Metering Entities. 4.2 QoS Monitoring 4.2.1 Scenario Description For a network user, it may be interesting at any time to check the QoS for a certain service. The service of interest can be coarse grained, for example, the QoS parameters provided by the link to the edge router (access point) or fine grained, for example, the QoS provided by a UDP data stream received from a video server. In any case, the first step of analysis that the user can perform is measuring the rates of sent and received traffics (including a consideration of re-transmissions). If such cases, local measurement indicates a non-satisfactory situation. A next step of analysis would be QoS measurement along the data path of the service of interest. A measurement of packet bit rate, packet loss, jitter and other QoS parameters at several points of the data path could identify the cause of unsatisfactory QoS and locate where it is caused. A similar, probably more important scenario is an ISP that detects that the QoS it provides to a customer does not match the service level agreement for this service. Then a measurement at several locations along the data path of the service of interest would be Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 10] Internet-Draft M-NSLP Framework February 2005 desirable for identifying the cause and location of QoS degradation. Both cases described above (and a huge range of related cases) could be solved by massive deployment of metering technology, for example, by measuring all flows at all routers in the network. Then, in case of a problem (or of a regular check) the information for a certain flow of interest can be retrieved from the huge amount of collected metering data. This approach is oversized, scales badly, and the benefit gained is most likely not worth the investment and the operational costs. Configuring available Metering Entities on the data path appears to be a more appropriate solution. In such a scenario, the requesting party would configure some or all available Metering Entities along the path of a service of interest in order to meter the particular service and report the metered data. Such configuration can be performed in a traditional way by individually, one by one, configuring all Metering Entities. This requires knowledge about the path taken by the service of interest, knowledge about the available Metering Entities on this path and a communication with each of them using an agreed (preferably standardized) protocol. The approach suggested by this document simplifies this task. By using path-coupled configuration of traffic measurement, a requesting party that is located on the path of interest does just need to send a single configuration request along the path in order to communicate with all available Metering Entities on this particular path. Since different measurements are required for different QoS parameters, the request sent along the path varies. This is illustrated by two example scenarios, one for loss metering and one for delay metering. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 11] Internet-Draft M-NSLP Framework February 2005 +---------------------------------------------------------+ | | | Administrative Domain | | | | ingress internal internal egress | | node node 1 node 2 node | | +-------+ +-------+ +-------+ +-------+ | | | |<====>| |<====>| |<====>| | | | | | | | | | | | | ---->| ME |----->| ME |----->| ME |----->| ME |----> | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ | | | +---------------------------------------------------------+ +---+ |ME | = Metering === = Signaling --- = Data Flow +---+ Entity Messages Figure 3: Signaling to configure metering for QoS monitoring Figure 3 shows a data stream passing a domain. Let's assume that at the ingress node a problem with the data stream is detected and that it wants to initiate traffic measurement for the data stream along the path it takes through the domain. Then the ingress node sends a signaling message along the path in order to configure available Metering Entities. If packet loss in the domain is the target of this investigation, then all available Metering Entities on the path will be requested to participate in the measurement. All will be requested to measure the number of packets observed for the data stream of interest and to report the results to either the requesting ingress node or to another Collector of traffic metering data. Then the collected data can be analyzed in order to identify locations in the domain where packet loss occurs. In a similar way delay can be analyzed. Different to loss metering, delay measurement require per packet reporting from the Metering Entities. For each observed packet belonging to the data stream of interest, the Metering entity needs to report a hash value of the packet header and a timestamp. In order to reduce the number of reports, reporting can be restricted to a certain range of hash values. Then the Collector of metered data can again analyze the sources of delay within the domain. If less detailed metering is required, for example, if loss and delay only needs to be measured for the entire domain, then not all Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 12] Internet-Draft M-NSLP Framework February 2005 Metering Entities need to participate. For the example it is sufficient if just the ingress and the egress node perform metering. Metering at internal nodes is not required. Per-domain packet loss and per-domain delay can be derived from packet counters and time stamped packet hash values metered at ingress and egress nodes. 4.2.2 Configuration Parameters Very similar to the accounting scenario in Section 4.1.2, the signaling initiator sends a CONFIGURE message along the data path. The responder returns a RESPONSE message. The parameters that need to be configured with the CONFIGURE message are the following: Correlation ID Similar to the accounting scenario, this is an ID that identifies this measurement. It can be used by the Collector for identifying incoming reports that belong to the same measurement. Flow ID Same as for the accounting scenario Metering Objects The objects to be measured: 1. Flow Properties: same as for the accounting scenario. 2. Packet Properties: + hash value + number of octets + time stamp Reporting Interval Same as for the accounting scenario Flow Expiration Time Same as for the accounting scenario Collector ID Same as for the accounting scenario Reporting Protocol Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 13] Internet-Draft M-NSLP Framework February 2005 Same as for the accounting scenario SelectionOfMeteringEntities This parameter specifies the requirement for Metering Entities along the data path. Among the required values for this parameter are * first: only the first available Metering Entity on the path is requested to perform metering. In the extreme case, this request is served by the signaling initiator itself. * last: only the last available Metering Entity on the path is requested to perform metering. In the extreme case, this request is served by the signaling responder. * all: all available Metering Entities on the path are requested to perform metering. * first and last: only the first and the last available Metering Entities on the path are requested to perform metering. 4.3 Monitoring for Network Security 4.3.1 Scenario Description Many network security mechanisms such as intrusion detection are based on the capability to monitor the network behavior. Network monitoring involves: o statistics, i.e. collection of statistical measures, such as packet rate, bit rate, number of connections, etc. o packet sampling, i.e. collection of complete packets based on rules (filters) and sampling algorithms The gathered information about the network traffic can be used for an analysis of packet's payload for known attack/intrusion patterns as well as for anomaly detection mechanisms. It is desirable that monitoring devices can be re-configured dynamically, depending on the state of the network to know more about a specific data flow when an attack is being assumed. Note here, that the attack might be of a different nature, for example, SYN flood or ICMP flood. Figure 4 depicts such as scenario. A potential victim or a network intrusion detection system (NIDS) sends a notification to an attack detection system that an attack is assumed (this can be triggered at the victim or at the NIDS by internal means). The attack detection system instructs the ingress points of the network to perform metering for the traffic designated to the victim and initiate signaling towards the victim for metering configuration. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 14] Internet-Draft M-NSLP Framework February 2005 +-----------------------------------------------------------+ | | | Administrative Domain A | | | | +----------------------------+ | | | Attack Detection System | | | +----------------------------+ | | ^ ^ ^ ^ | | ** * * # | | ** * * # | | ** * * # | | ** * * # | | Ingress Node A probe 1 probe 2 | | +-----------+ +----+ +----+ +-----------+ | | | |=====>| |=====>| |=====>| | | | | | | | | | | | | ---->| ME |----->| ME |----->| ME |----->| victim |----> | | | | | | | | | | | +-----------+ +----+ +----+ +-----------+ | | | +-----------------------------------------------------------+ +---+ |ME |= Metering === = Meter. Configuration --- = Data Flow +---+ Entity Signaling Messages ## other protocol Figure 4: Signaling to configure metering for attack detection In the figure above, the Metering Entities along the data path from the ingress point A to the victim can be configured to meter/monitor the packets belonging to a particular data flow. Metering Data is transferred to the according attack detection system for further analysis. 4.3.2 Required Parameters Very similar to the accounting scenario in Section 4.1.2, the signaling initiator sends a CONFIGURE message along the data path. The responder returns a RESPONSE message. The parameters that need to be configured with the CONFIGURE message are the following: Correlation ID Similar to the accounting scenario, this is an ID that identifies this measurement. It can be used by the Collector for identifying incoming reports that belong to the same measurement. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 15] Internet-Draft M-NSLP Framework February 2005 Flow ID Same as for the accounting scenario Metering Objects The objects to be measured: 1. Flow Properties: same as for the accounting scenario. 2. Packet Properties: + header information + parts of the packet + complete packets Reporting Interval Same as for the accounting scenario Flow Expiration Time Same as for the accounting scenario Collector ID Same as for the accounting scenario Reporting Protocol Same as for the accounting scenario SelectionOfMeteringEntities This parameter specifies the requirement for Metering Entities along the data path. Among the required values for this parameter are * first: only the first available Metering Entity on the path is requested to perform metering. In the extreme case, this request is served by the signaling initiator itself. * last: only the last available Metering Entity on the path is requested to perform metering. In the extreme case, this request is served by the signaling responder. * all: all available Metering Entities on the path are requested to perform metering. * first and last: only the first and the last available Metering Entities on the path are requested to perform metering. * optimum: selection of an optimal fitting Metering Entity based on current load, location, amount of Metering Data Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 16] Internet-Draft M-NSLP Framework February 2005 5. Requirements This section describes the requirements for a path-coupled signaling for the configuration of Metering Entities. We assume existing protocols or other means for transferring 1. captured packet information from the Monitoring Probes to the Metering Entities and 2. Metering Data from the Metering Entities to Collectors. Note that the Monitoring Probes and the Metering Entities are co-located. 5.1 General requirements 5.1.1 Extensibility 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 information model. This relates to the parameter exchange between the Metering Entities. Moreover, the metering configuration protocol should bridge between different existing metering solutions, for example, those defined in 3GPP. The communication may be organized using proxy or agent based systems. 5.1.2 Scalability A Metering Entity needs to keep state and perform metering actions for each accepted metering task. Handling high numbers of metering tasks need to be provided by the Metering Entity implementation and is not subject of a signaling protocol. However, the protocol design should provide scalability for state keeping and refresh for a large number of concurrent metering tasks. 5.1.3 Security The process of configuring an Internet-wide metering system is a sensitive task. Therefore, arrangements should be taken to secure this process. Signaling messages might cross domain boundaries which raises authorization concerns. Administrators of other domains might not be willing to allow data traffic to be sent and redirected to a Collector outside the domain. This might severely impact the users trust perception about the attached domain. Furthermore, a domain might not want to allow entities from other Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 17] Internet-Draft M-NSLP Framework February 2005 domains to control network entities with respect to metering. The currently deployed charging in the Internet is based on the relationship between neighboring domains making end user charging for data traffic (or services) by non-neighboring domains impossible. The advantage of this model makes allows each domain to control its pricing and charging policy. This document does not aim to change the existing Internet charging model in any way. 5.2 Flexible metering model The metering configuration protocol should support a flexible metering model. Depending on the metering scenario, different information must be exchanged between the Metering Entities. 5.3 Distinguishing flows A primary capability of the metering function is the identification of data packets belonging to different applications or users. The configuration of the Metering Entities should take this parameter into account. During the data flow life-time, statistics describing the properties of this data flow are gathered and exported to a Collector. The metering configuration should be flexible to allow the description of multiple services and associated flows. Flows belonging to one application: the metering configuration should allow the aggregation of Metering Records for streams belonging to a particular application, for example, a multimedia transmission with associated data transfers (web pages). 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. 5.4 Flexible data collection After the gathering of Metering Data, it has to be transferred to the appropriate Collector(s). The protocol for configuring Metering Entities MUST be independent of the protocol used for transferring Metering Data. One possible protocol is IPFIX [I-D.ietf-ipfix-protocol]. The IPFIX information model ([I-D.ietf-ipfix-info]) is very flexible for extensions and, therefore, adequate for this application. 5.5 Location of Metering Entities The Metering Entities are located on the data path, i.e., on the path Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 18] Internet-Draft M-NSLP Framework February 2005 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, for example, only in a subset of the path, or only at start and end point etc. 5.6 Location of the Collectors The Metering Data need to be transferred to one or eventually several Collectors. The process of discovering which Collector is interested in which Metering Data is out of scope. It is assumed that the signaling initiator knows the location of the Collectors by different means. In case a Collector itself is located on the data path it SHOULD use the metering configuration protocol to inform all involved Metering Entities about its location. A Collector MAY be changed during the metering process. The handover process will be not handled. 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 Metering Entities The protocol MUST be able to configure Metering Entities, for example, to control which information needs to be collected and which entities are allocated which task. Protocol messages need to be interpreted only by Metering Entities. 5.7.2 Selection of Metering Entities The protocol MUST provide functionality to select Metering Entities that become part of a metering process by specifying, for example, their type or total number. 5.7.3 Metering Configuration State installation and removal The protocol MUST be able to install metering state and also to remove it. Furthermore, metering state SHOULD be soft state in order to cope with rerouting and device failure. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 19] Internet-Draft M-NSLP Framework February 2005 5.7.4 Initiation and maintenance of metering tasks The protocol MAY 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. 5.7.5 Reaction to Route Changes The protocol MUST be able to react to rerouting of the packets that are to be metered. Rerouting may imply including new Metering Entities and removing some. This requirement is important especially for the accounting scenario: if routes change unnoticed the user will use the service for free. 5.7.6 Collection of information on available Metering Entities The protocol SHOULD be able to collect information on Metering Entities and their capabilities without actually installing any state. This feature SHOULD at least be available for Metering Entities that are involved in performing a requested metering task. 5.7.7 Scoping of configuration 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, for example, to the responsible UMTS GGSN (Gateway GPRS Support Node: a router that serves as a gateway between mobile networks and packet data networks) because it is known that Metering Entities beyond the GGSN are of no interest for this particular metering configuration. 5.8 Metering across domains Metering configuration SHOULD be possible across administrative domains. There are challenging security aspects in this goal. 6. Applicability of the NSIS Architecture According to the NSIS framework [I-D.ietf-nsis-fw], the NSIS protocol suite can support various signaling applications that need to install or manipulate state in NSIS-aware network nodes (NEs) along the path of a data flow. The NSLP messages do not need to run all the way between the data flow endpoints. Rather, the NSIS initiating NE and Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 20] Internet-Draft M-NSLP Framework February 2005 the NSIS receiving NE can be located anywhere along the data path. The problem of path-coupled signaling to configure Metering Entities seems to be well suited to be solved with a novel NSIS signaling application, the Metering NSLP. The Metering NSLP can run on top of the NTLP similarly to the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the NAT/Firewall NSLP [I-D.ietf-nsis-nslp-natfw] The Metering NSLP needs to be able to install, modify and remove metering configuration related state. Furthermore, signaling for metering configuration needs the flexibility provided by NSIS to start and end on arbitrary Metering Entities. Any Metering Entity on the data path is able to initiate metering configuration signaling. The selection of signaling initiator and receiver depends on the configuration and on the specific application environment. A Metering NSLP, similar to QoS NSLP, would be independent of the actual configuration information it carries. Hence, it can be used for any metering application. Finally, the semantic of some of the QoS NSLP messages can be reused in the Metering NSLP (RESERVE (i.e. CONFIGURE), RESPONSE, QUERY and NOTIFY). Possible inter-working 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. 7. Security Considerations The process of configuring entities to start and stop metering and to transmit collected Metering Data to a third party introduces security challenges. For example, in the accounting scenario if a malicious user is able to stop metering of requested services then fraud is possible. It must be not possible to configure Metering Entities in such a way that other users are charged for the usage of a service which they have not used. Second, if the scope of the configuration signaling should go beyond the borders of a single domains, the ISPs need to be authorized to perform M-NSLP signaling across other domains and to collect metering and monitoring data. A high degree of trust is required. Customer privacy comes into question. Service Provides have also their privacy, since the Metering Records will reveal their network topology and will provide statistics about their traffic. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 21] Internet-Draft M-NSLP Framework February 2005 Moreover, 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. 8. Open Issues o The Terminology used in this document and in [I-D.dressler-nsis-metering-nslp] should be clarified for consistency with the IPFIX terminology. o Different scenarios might be combined together. For example, Service Providers might combine QoS Monitoring and accounting together and charge their customers less if the negotiated services were not satisfied. This issue might be considered in future work. 9. Contributors This document is the result of the effort of a Metering NSLP team that has been built. Except the individuals listed in the author list, the team includes also Juergen Quittek and Hannes Tschofenig. 10. References 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.dressler-nsis-metering-nslp] Dressler, F., "NSLP for Metering Configuration Signaling", Internet-Draft draft-dressler-nsis-metering-nslp-00, October 2004. [I-D.ietf-nsis-ntlp] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", Internet-Draft draft-ietf-nsis-ntlp-04, October 2004. [I-D.ietf-ipfix-protocol] Claise, B., "IPFIX Protocol Specifications", Internet-Draft draft-ietf-ipfix-protocol-07, December 2004. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 22] Internet-Draft M-NSLP Framework February 2005 10.2 Informative References [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3917] Quittek, J., Zseby, T., Claise, B. and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [I-D.ietf-ipfix-info] Calato, P., "Information Model for IP Flow Information Export", Internet-Draft draft-ietf-ipfix-info-05, October 2004. [I-D.ietf-nsis-fw] Hancock, R., "Next Steps in Signaling: Framework", Internet-Draft draft-ietf-nsis-fw-07, December 2004. [I-D.ietf-nsis-qos-nslp] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", Internet-Draft draft-ietf-nsis-qos-nslp-05, October 2004. [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October 2004. [I-D.ietf-psamp-mib] Dietz, T., "Definitions of Managed Objects for Packet Sampling", Internet-Draft draft-ietf-psamp-mib-03, July 2004. [3GPP.32.240] 3GPP, "Telecommunication management; Charging management; Charging architecture and principles", 3GPP TS 32.240 6.0.0, September 2004. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 23] Internet-Draft M-NSLP Framework February 2005 Authors' Addresses 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/ Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Phone: +49 30 386-32894 Email: cornelia.kappler@siemens.com Changpeng Fan Siemens AG Siemensdamm 62 Berlin 13627 Germany Phone: +49 30 386-36361 Email: changpeng.fan@siemens.com Falko Dressler University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27914 Email: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/ Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 24] Internet-Draft M-NSLP Framework February 2005 Andreas Klenk University of Tuebingen Wilhelm-Schickard-Institute for Computer Science Auf der Morgenstelle 10C Tuebingen 71076 Germany Phone: +49 7071 29-70535 Email: klenk@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 25] Internet-Draft M-NSLP Framework February 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. Fessi, et al. draft-fessi-nsis-m-nslp-framework-00.txt [Page 26]