[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                        F. Dressler
Internet-Draft                                    University of Erlangen
Expires: April 17, 2005                                         G. Carle
                                                 University of Tuebingen
                                                                  C. Fan
                                                              C. Kappler
                                                           H. Tschofenig
                                                              Siemens AG
                                                        October 17, 2004

               NSLP for Metering Configuration Signaling

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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).


   Monitoring, metering and accounting of packets are increasingly
   important functionality that needs to be provided in the Internet.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 1]

Internet-Draft               Metering NSLP                  October 2004

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6

   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Charging . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2   QoS Monitoring . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   Intrusion Detection  . . . . . . . . . . . . . . . . . . . 10
     4.4   Configuration information common to all scenarios  . . . . 11

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1   General requirements . . . . . . . . . . . . . . . . . . . 12
       5.1.1   Extensibility  . . . . . . . . . . . . . . . . . . . . 12
       5.1.2   Scalability  . . . . . . . . . . . . . . . . . . . . . 12
       5.1.3   Interoperability . . . . . . . . . . . . . . . . . . . 12
       5.1.4   Security . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2   Flexible metering model  . . . . . . . . . . . . . . . . . 13
     5.3   Distinguishing flows . . . . . . . . . . . . . . . . . . . 13
     5.4   Flexible data collection . . . . . . . . . . . . . . . . . 13
     5.5   Location of Metering Entities  . . . . . . . . . . . . . . 14
     5.6   Location of the collector  . . . . . . . . . . . . . . . . 14
     5.7   Configuration protocol . . . . . . . . . . . . . . . . . . 14
       5.7.1   Configuration of Metering Entities . . . . . . . . . . 14
       5.7.2   Selection of Metering Entities . . . . . . . . . . . . 14
       5.7.3   Metering Configuration State installation and
               removal  . . . . . . . . . . . . . . . . . . . . . . . 14
       5.7.4   Initiation and maintenance of metering tasks . . . . . 14
       5.7.5   Collection of information on available Metering
               Entities . . . . . . . . . . . . . . . . . . . . . . . 15
       5.7.6   Scoping of configuration . . . . . . . . . . . . . . . 15
     5.8   Metering across domains  . . . . . . . . . . . . . . . . . 15

   6.  Applicability of NSIS  . . . . . . . . . . . . . . . . . . . . 15

   7.  Basic Protocol Design  . . . . . . . . . . . . . . . . . . . . 16
     7.1   Model of operation . . . . . . . . . . . . . . . . . . . . 16
     7.2   Protocol overview  . . . . . . . . . . . . . . . . . . . . 18

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 2]

Internet-Draft               Metering NSLP                  October 2004

       7.2.1   Message types  . . . . . . . . . . . . . . . . . . . . 18
       7.2.2   Design Decisions . . . . . . . . . . . . . . . . . . . 19
     7.3   Examples of operation  . . . . . . . . . . . . . . . . . . 21
     7.4   Implications for GIMPS API . . . . . . . . . . . . . . . . 21
     7.5   Mapping onto M-NSLP Requirements . . . . . . . . . . . . . 22

   8.  Security considerations  . . . . . . . . . . . . . . . . . . . 23

   9.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 24

   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24

   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 24
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 24

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26

       Intellectual Property and Copyright Statements . . . . . . . . 28

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 3]

Internet-Draft               Metering NSLP                  October 2004

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], [RFC2866] and
   [I-D.draft-lior-radius-prepaid-extensions-03]) and DIAMETER (see
   [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which
   provide information about consumed resources via Metering Records.
   The Meter MIB [RFC2720] 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

   This draft is organized as follows: We give a problem description in
   Section 3, and then illustrate it with a number of scenarios in
   Section 4.  Subsequently, we list a few requirements in Section 5.
   Finally, we discuss the suitability of NSIS for the configuration of
   Metering Entities in Section 6.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   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.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 4]

Internet-Draft               Metering NSLP                  October 2004

   Metering Record

      A Metering Record represents aggregated and/or correlated Metering

   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.


      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.


      An NSIS Entity (NE) which supports the Metering NSLP.


      The first node in the sequence of MNEs that issues a configuration
      message for a flow or aggregate.


      The last node in the sequence of MNEs that receives a
      configuration message for a flow or aggregate.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 5]

Internet-Draft               Metering NSLP                  October 2004


      A MNE that is neither MNI nor MNR.

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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 6]

Internet-Draft               Metering NSLP                  October 2004

                             | 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
   o  measurement data needs to be transported from the monitoring
      probes to the Metering Entities.  Metering Data needs to be
      transported from the Metering Entities to the collector.
      [I-D.ietf-ipfix-protocol] is a protocol suitable for this task.
   o  The Metering 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 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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 7]

Internet-Draft               Metering NSLP                  October 2004

   as "out of the scope" [RFC3917].  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 4 we discuss
   in more detail two possible applications for configuration of
   Metering Entities, namely QoS monitoring and charging.

4.  Scenarios

   This section describes three scenarios for the usage of the metering
   configuration protocol: charging, QoS monitoring, and monitoring for
   intrusion detection.

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, 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 2 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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 8]

Internet-Draft               Metering NSLP                  October 2004

   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.

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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 9]

Internet-Draft               Metering NSLP                  October 2004

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

4.3  Intrusion Detection

   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.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 10]

Internet-Draft               Metering NSLP                  October 2004

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

4.4  Configuration information common to all scenarios

   The configuration of Metering Entities described in Section 4.1,
   Section 4.2, and Section 4.3 would include, among other things, the
   distribution of the following information:
   o  which metering entries have to register usage data
   o  what type of data to collect (e.g.  count packets, measure delay
   o  data related to what flows to collect
   o  which usage data need to be transferred from Metering Entities to
      a collector (i.e., flow identifier)

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 11]

Internet-Draft               Metering NSLP                  October 2004

   o  the identity of the collector to which usage data is to be
   o  a correlation ID which allows the collector to correlate the flow
      data arriving from different Metering Entities
   o  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 Metering Entities.  We assume an existing
   protocol to transport the collection of Metering Data
   1.  between the monitoring probe and the Metering Entity and
   2.  between the Metering Entity and a collector.

   We also assume that the monitoring probes and the Metering Entities
   may be collocated.

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

5.1.2  Scalability

   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.

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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 12]

Internet-Draft               Metering NSLP                  October 2004

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 metering model

   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

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

   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.

5.4  Flexible data collection

   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].  The IPFIX
   information model [I-D.ietf-ipfix-info] is very flexible for
   extentions and, therefore, adequate for this application.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 13]

Internet-Draft               Metering NSLP                  October 2004

5.5  Location of Metering Entities

   The Metering Entities are located on the data path, i.e., on the path
   of the data that should be metered.  It is an open problem how the
   initiator and receiver of the metering configuration signaling are

   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.

5.6  Location of the collector

   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.

5.7  Configuration protocol

5.7.1  Configuration of Metering Entities

   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.

5.7.2  Selection of 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.

5.7.3  Metering 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 metering tasks

   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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 14]

Internet-Draft               Metering NSLP                  October 2004

   entities, and a trigger to send off Metering Data to the collector.

   The triggering source of the initiation is out of scope of this

   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.

5.7.5  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

5.7.6  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 e.g.  to the responsible UMTS GGSN because it is known that
   MNEs beyond the GGSN are of no interest for this particular metering

5.8  Metering across domains

   Metering configuration SHOULD 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], 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] for signaling QoS reservations and the NAT /

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 15]

Internet-Draft               Metering NSLP                  October 2004

   Firewall NSLP [I-D.ietf-nsis-nslp-natfw] 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].  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

   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.

7.  Basic Protocol Design

   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].  The main difference compared to QoS NSLP
   is that Metering NSLP allows individual Metering NEs (MNEs) to pull
   out of a sigaling session.

7.1  Model of operation

   Figure 5 shows an example logical model of the operation of Metering
   NSLP and the associated metering mechanism in a MNE.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 16]

Internet-Draft               Metering NSLP                  October 2004

                                     +---------------+               ^
                                     |     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 1).  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 1

   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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 17]

Internet-Draft               Metering NSLP                  October 2004

   comparing Figure 5 to the corresponding Figure 1 in
   [I-D.ietf-nsis-qos-nslp] 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.

7.2  Protocol overview

7.2.1  Message types

   The Metering NSLP uses four message types:

      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.


      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.


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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 18]

Internet-Draft               Metering NSLP                  October 2004

      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

   Policy objects

      Policy objects contain data used to authorise the configuration of
      the MNEs.  They are interpreted by Policy Control.

7.2.2  Design Decisions  Soft State

   NSIS State is always soft state and needs to be refreshed.  The
   Control Information carries an object that determines the life time
   of M-NSLP state.  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], 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.  Message Sequencing

   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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 19]

Internet-Draft               Metering NSLP                  October 2004

   by means of a Configuration Sequence Number (CSN), which corresponds
   to the Reservation Sequence Number (RSN) of QoS-NSLP.  Message Scoping

   In order to realize the requirement in Section 5.7.6, 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.  Rerouting

   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.  Selection of MNEs

   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.2.
   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.4.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 20]

Internet-Draft               Metering NSLP                  October 2004  Aggregation

   According to Section 5.3, 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.
   o  A Metering Entity collects data for each flow (e.g.  all flows of
      a user for different applications) separately and aggregates them
      before forwarding to the Collector.  This can be realized by
      including in the MSpec appropriate configuration information for
      the Metering Entity.
   o  The MNE configures the Monitoring Probe to account for all packets
      of the user in one data record.  This can be realized by
      appropriately fixing the flow identifier signaled in M-NSLP.

7.3  Examples of operation

   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.

7.4  Implications for GIMPS API

   In [I-D.ietf-nsis-ntlp], 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.2 and Section
   implies requirements on the API that may currently not be covered.

   1.  When a given MNE x discovers it is not part of a signaling
       session it needs to be able to tell GIMPS to not install message
       routing state.  This needs to imply that the next MNE downstream
       (which wants to partipate in the signaling session) does not
       invoke a Messaging Association with MNE_x but rather with the
       next MNE upstream that participates in the session.  In fact
       something similar is also necessary for supporting stateless /
       reduced state NSIS Entities.  Therefore the API already defines a
       message that asks GIMPS to not retain state.  Whether this is
       sufficient to cover M-NSLP requirements still needs to be worked
       out in more detail.
   2.  The configuration of a particular metering session may be
       changed, particularly more, or other, types of Metering Entities
       may have to be included.  These entities however do not

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 21]

Internet-Draft               Metering NSLP                  October 2004

       participate currently in the ongoing signaling session.
       Therefore means must be provided to include them at a later
       point.  One possibility is for M-NSLP to tell GIMPS a rerouting
       event occurred, and message routing state needs to be updated.
       This would prompt GIMPS to rediscover peers.  However care needs
       to be taken that GIMPS doesnéÌÙt use this information to warn
       other NSLPs about the assumed rerouting.  Also here the problem
       and possible solutions still need to be analyzed in more detail.

7.5  Mapping onto M-NSLP Requirements

   With the design described above, the requirements from Sec 5 are at
   this point satisfied as follows:
   o  Extensibility (Section 5.1.1) The actual configuration information
      is encapsulated in the MSpec.  Depending on how flexible the MSpec
      is designed this requirement can be satisfied.  Furthermore,
      M-NSLP needs to be flexible regarding the message sequencing that
      is possible.  The current design is still open in that respect.
   o  Interoperability (Section 5.1.3) Again, whether different
      accounting solutions can interwork depends on how the MSpec is
      designed.  In QoS NSLP, the QSpec template design
      [I-D.ietf-nsis-qspec] aims at similar extensibility and
   o  Flexible metering models (Section 5.2) As above, this is a problem
      of MSpec design, and flexibility of message sequencing.
   o  Distinguishing flows (Section 5.3) The aggregation feature
      detailed in this requirement can be realized as described in
   o  Flexible data collection (Section 5.4) Another issue that needs to
      be fixed in the MSpec.
   o  Location of Metering Entities (Section 5.5) Since MNEs, including
      MNI and MNR can be located anywhere on the data path, Metering
      Entities can be flexibly located.
   o  Location of the Collector (Section 5.6) The location of the
      Collector is coded in the MSpec.  By sending an updating CONFIGURE
      message, its location can be updated while the metering process is
   o  Configuration of Metering Entities (Section 5.7.1) The protocol
      can configure Metering Entities that are MNEs, or that are
      controlled by MNEs.
   o  Selection of Metering Entities (Section 5.7.2) As described in
      Section, a MNE should be able to decide to pull out of the
      metering process.  How this is realized regarding the interaction
      between M-NSLP and GIMPS is not yet clarified in detail.
      Furthermore, an MSpec template must provide a language to
      abstractly describe types of Metering Entities that are (not) to
      become part of the metering process.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 22]

Internet-Draft               Metering NSLP                  October 2004

   o  Metering Configuration State installation and removal (Section
      5.7.3) By means of the CONFIGURE message, the protocol can
      install, refresh and remove Metering Configuration State.
   o  Initiation and maintainance of metering tasks (Section 5.7.4)
      Triggers and correlation identifier are transported in the MSpec.
      The protocol implicitly reacts to rerouting because a refreshing
      CONFIGURE message installs state along the new route, as described
      in Section
   o  Collection of information on available Metering Entities (Section
      5.7.5) This can be achieved by means of the QUERY message
   o  Scoping of configuration (Section 5.7.6) By defining a language to
      abstractly describe types of Metering Entities it is possible to
      flexibly scope signaling messages.

   Requirements not mentioned in this list are not yet addressed.

8.  Security considerations

   The process of configuring entities to start and stop metering and to
   transmit collected resource records to a third party introduces
   security challenges.

   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

   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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 23]

Internet-Draft               Metering NSLP                  October 2004

   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.

9.  Open issues

   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
   1.  the first MNE (MNE_X) on the signaling path being of type X
       should volunteer to take on this task
   2.  MNE_X needs to modify the MSpec to signal to subsequent MNEs that
       a Metering Entity of type X has already been found.

   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.

10.  Acknowledgements

   The authors would like to thank Robert Hancock for valuable input.

11.  References

11.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

11.2  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2720]  Brownlee, N., "Traffic Flow Measurement: Meter MIB",
              October 1999.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 24]

Internet-Draft               Metering NSLP                  October 2004

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

              Claise, B., "IPFIX Protocol Specifications",
              draft-ietf-ipfix-protocol-05 (work in progress), August

              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.

              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.

              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.

              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

              Ash, J., Bader, A. and C. Kappler, "QoS-NSLP QSpec
              Template", draft-ietf-nsis-qspec-01 (work in progress),
              October 2004.

              Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
              Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-03
              (work in progress), July 2004.

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 25]

Internet-Draft               Metering NSLP                  October 2004

              Couturier, A., "Signaling for QoS Measurement",
              draft-couturier-nsis-measure-00 (work in progress), May

              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

              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.

              3GPP, "Charging Architecture and Principles", 3GPP
              Technical Specification TS32.240, December 2003.

Authors' Addresses

   Falko Dressler
   University of Erlangen
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058

   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

   Phone: +49 7071 29-70505
   EMail: carle@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 26]

Internet-Draft               Metering NSLP                  October 2004

   Changpeng Fan
   Siemens AG
   Siemensdamm 62
   Berlin  13627

   Phone: +49 30 386-36361
   EMail: changpeng.fan@siemens.com

   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13627

   Phone: +49 30 386-32894
   EMail: cornelia.kappler@siemens.com

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739

   EMail: Hannes.Tschofenig@siemens.com

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 27]

Internet-Draft               Metering NSLP                  October 2004

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


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

Dressler, et al.    draft-dressler-nsis-metering-nslp-00.txt    [Page 28]

Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/