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

Versions: 00 01 02 03 04 05

Network Working Group                                           A. Fessi
Internet-Draft                                                  G. Carle
Expires: September 6, 2007                       University of Tuebingen
                                                             F. Dressler
                                                  University of Erlangen
                                                              J. Quittek
                                                                     NEC
                                                              C. Kappler
                                                           H. Tschofenig
                                                              Siemens AG
                                                           March 5, 2007


               NSLP for Metering Configuration Signaling
               <draft-dressler-nsis-metering-nslp-05.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 6, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Monitoring, metering and accounting of packets are increasingly



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 1]


Internet-Draft                Metering NSLP                   March 2007


   important functionality that needs to be provided in the Internet.
   This document proposes the definition of a new NSIS Signaling Layer
   Protocol (NSLP), named Metering NSLP (M-NSLP), which allows the
   dynamic configuration of Metering Entities on the data path.  An
   accompanying document [I-D.fessi-nsis-m-nslp-framework] provides a
   problem statement, describes scenarios where such a path-coupled
   configuration of Metering Entities is useful, elaborates requirements
   for a path-coupled protocol for the configuration of Metering
   Entities and discusses the applicability of NSIS for this purpose.
   This document defines a Metering NSLP protocol design and messages,
   and describes the protocol operation.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Model of operation . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Metering NSLP Messages . . . . . . . . . . . . . . . . . .  9
       3.2.1.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.2.  REFRESH  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.3.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.4.  RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.5.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 10

   4.  Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Soft State . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Message Sequencing . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Message Scoping  . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Selection of MNEs  . . . . . . . . . . . . . . . . . . . . 11
     4.5.  Coordination of Metering Tasks . . . . . . . . . . . . . . 11
     4.6.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.7.  Reaction to Route Changes  . . . . . . . . . . . . . . . . 11
     4.8.  Metering Configuration Information . . . . . . . . . . . . 12
     4.9.  Required State Information . . . . . . . . . . . . . . . . 12

   5.  Metering NSLP Messages and Objects . . . . . . . . . . . . . . 13
     5.1.  Metering NSLP Objects  . . . . . . . . . . . . . . . . . . 13
       5.1.1.  The 'Session Identifier' Object (SID)  . . . . . . . . 13
       5.1.2.  The 'Message Sequence Number' Object (MSN) . . . . . . 13
       5.1.3.  The 'Selection of Metering Entities' Object
               (MNE_Selection)  . . . . . . . . . . . . . . . . . . . 13
       5.1.4.  The 'Session Lifetime' Object (Session_LT) . . . . . . 14
       5.1.5.  The 'MNSLP Hop Count' Object (MNSLP_Hop_Count) . . . . 14
       5.1.6.  The 'Information Code' Object (INFO) . . . . . . . . . 14



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 2]


Internet-Draft                Metering NSLP                   March 2007


       5.1.7.  MSPEC Objects  . . . . . . . . . . . . . . . . . . . . 15
     5.2.  Metering NSLP Messages . . . . . . . . . . . . . . . . . . 15
       5.2.1.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.2.  REFRESH  . . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.3.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.4.  RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.5.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  MSPEC Objects  . . . . . . . . . . . . . . . . . . . . . . 16
       5.3.1.  IPFIX MSPEC Object . . . . . . . . . . . . . . . . . . 17

   6.  Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  Session State Machine  . . . . . . . . . . . . . . . . . . 18
     6.2.  Standard Message Processing Rules  . . . . . . . . . . . . 21
       6.2.1.  Message Parsing  . . . . . . . . . . . . . . . . . . . 21
       6.2.2.  Authentication and Authorization . . . . . . . . . . . 21
       6.2.3.  Message Sequencing . . . . . . . . . . . . . . . . . . 21
       6.2.4.  MNSLP Hop Counting . . . . . . . . . . . . . . . . . . 22
     6.3.  Message Processing Rules . . . . . . . . . . . . . . . . . 23
       6.3.1.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . . 23
       6.3.2.  REFRESH  . . . . . . . . . . . . . . . . . . . . . . . 24
       6.3.3.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 24
       6.3.4.  RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 25
       6.3.5.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 25
     6.4.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 26
     6.5.  Interaction with GIST  . . . . . . . . . . . . . . . . . . 26

   7.  Examples of Operation  . . . . . . . . . . . . . . . . . . . . 27
     7.1.  Example with MNE_Selection is ANY  . . . . . . . . . . . . 27
     7.2.  Example with MNE_Selection is ALL  . . . . . . . . . . . . 28
     7.3.  Example with MNE_Selection is FIRST_and_LAST . . . . . . . 29
     7.4.  Example with a Route Changes . . . . . . . . . . . . . . . 30

   8.  Bit-Level Formats and Error Messages . . . . . . . . . . . . . 30
     8.1.  Metering NSLP Messages . . . . . . . . . . . . . . . . . . 30
     8.2.  Metering NSLP Objects  . . . . . . . . . . . . . . . . . . 31
       8.2.1.  MSN  . . . . . . . . . . . . . . . . . . . . . . . . . 32
       8.2.2.  Session_LT . . . . . . . . . . . . . . . . . . . . . . 32
       8.2.3.  MNE_Selection  . . . . . . . . . . . . . . . . . . . . 32
       8.2.4.  INFO . . . . . . . . . . . . . . . . . . . . . . . . . 33
       8.2.5.  MSPEC Objects  . . . . . . . . . . . . . . . . . . . . 33

   9.  Mapping onto M-NSLP Requirements . . . . . . . . . . . . . . . 34

   10. Security considerations  . . . . . . . . . . . . . . . . . . . 36

   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 36

   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 3]


Internet-Draft                Metering NSLP                   March 2007


   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 36
     13.2. Informative References . . . . . . . . . . . . . . . . . . 37

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
   Intellectual Property and Copyright Statements . . . . . . . . . . 41













































Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 4]


Internet-Draft                Metering NSLP                   March 2007


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 for this purpose.  The PSAMP WG defines a
   standard to sample subsets of packets by statistical and other
   methods.  RADIUS (see [RFC2865] and [RFC2866]) and DIAMETER (see
   [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which
   provide information about consumed resources.  The Meter MIB
   [RFC2720] is a MIB for collecting flow information.

   However, it is also necessary to configure and coordinate the
   entities performing the metering.  RADIUS, DIAMETER and SNMP are
   candidates for this configuration.  Nevertheless, these protocols
   require some knowledge about the location of the appropriate Metering
   Entities to configure them.

   In more complex network topologies and architectures, the appropriate
   entities to meter the properties of a given data flow can be
   discovered dynamically using path-coupled signaling.  If more than
   one Metering Entity is required, all of them can potentially be
   configured and coordinated with a single message along the path.

   Scenarios and requirements for Metering NSLP are described in
   [I-D.fessi-nsis-m-nslp-framework].

   This draft defines the Metering NSLP for configuration and
   coordination of Metering Entities in a path-coupled fashion.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Furthermore, the terminology defined by GIST [I-D.ietf-nsis-ntlp]
   applies to this draft.

   Moreover, this document uses the following terms:

   Metering Record

      A Metering Record describes flow characteristics for a particular
      flow.  Examples of such data are packet counter and time
      information.



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 5]


Internet-Draft                Metering NSLP                   March 2007


   Monitoring Probe

      A Monitoring Probe is an entity that examines data flows in order
      to gather Metering Records.

   Metering Entity

      A Metering Entity is a node that is equipped with one or more
      Monitoring Probes.  A Metering Entity MAY process the Metering
      Records, e.g. by aggregating them or by sampling them, before they
      are exported elsewhere, typically to a Collector.  A Metering
      Entity MAY host other functions, for example, for processing of
      NSIS signaling.

   Collector

      A Collector receives Metering Records from one or multiple
      Metering Entities.  These Metering Records can be aggregated
      and/or correlated by the Collector.  The Collector is typically
      not co-located with a Metering Entity.  Another protocol (e.g.
      IPFIX) is needed to transport the Metering Records from the
      Metering Entity to the Collector.

   Metering Configuration State

      A State used/kept by the Metering Manager to configure the
      Monitoring Probe.

   Metering Manager

      A unit co-located with the Monitoring Probe that communicates with
      M-NSLP processing.  It holds Metering Configuration State which is
      used to configure the Monitoring Probe.

   Metering NSIS Entity (MNE)

      A Metering Entity which supports the Metering NSLP.

   Metering NSIS Initiator (MNI)

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

   Metering NSIS Responder (MNR)

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




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 6]


Internet-Draft                Metering NSLP                   March 2007


   Metering NSIS Forwarder (MNF)

      A MNE that is neither MNI nor MNR.



3.  Protocol Overview

   The design for the Metering NSLP and the processing of M-NSLP
   messages is in some aspects similar to QoS NSLP
   [I-D.ietf-nsis-qos-nslp] and in other aspects to the NATFW NSLP
   [I-D.ietf-nsis-nslp-natfw].  One of the main differences compared to
   the QoS NSLP and the NATFW NSLP is that only a subset (in some cases
   even only one) of the Metering Entities in the signaling path will
   take part in the actual Metering.  This fact has several consequences
   on the signaling itself and therefore on the protocol design.

3.1.  Model of operation

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






























Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 7]


Internet-Draft                Metering NSLP                   March 2007


                      +---------------+
                      |     Local     |
                      | Management    |
                      +---------------+
                              ^
                              V
          +---------+    +----------+    +----------+
          | Policy  |    |  M-NSLP  |    | Metering |
          | Control |<<>>|Processing|<<>>|  Manager |
          +---------+    +----------+    +----------+
                           .  ^   |        V
                           |  ^   .        V
                           |  V   .        V
                           |  V   .        V
                          +----------+     V
                          |   GIST   |     V
                .-.-.-.-.-|Processing|-.-.-v.-.-.-.-.-.-.-
                .         +----------+     V             |
                |                          v             .
                .                          v             |
   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                |                          v             |
                .                          v             .
                |        +---------------------+         |
          +----------+   |                     |    +-----------+
      <-.-|  Input   |   |   Monitoring        |    | Outgoing  |-.->
          |  Packet  |   |                     |    | Interface |
      ===>|Processing|===|     Probe           |====|           |==>
          +----------+   |                     |    +-----------+
                         +---------------------+

              <.-.-> = signaling flow
              =====> = data flow (sender --> receiver)
              <<<>>> = control and configuration operations

                Figure 1: Metering-NSLP in Metering Entity

   The Monitoring Probe collects metering data and processes them into
   Metering Records, which can be sent to the Collector.  The Monitoring
   Probe is co-located with the Input Packet Processing and the Outgoing
   Interface.

   A M-NSLP message called CONFIGURE transports:
   o  Control information objects for the M-NSLP Processing, such as
      message sequence numbers and whether the MNE should actually take
      part in the metering process





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 8]


Internet-Draft                Metering NSLP                   March 2007


   o  Metering configuration information objects, also called MSPEC
      objects, that describe the actual configuration information.  The
      MSPEC objects are interpreted by the Metering Manager and SHOULD
      be opaque to the M-NSLP Processing.
   o  Policy information to authenticate and authorize the configuration
      request

   The M-NSLP Processing decides if the current MNE is addressed by this
   configuring message.  If yes, the MSPEC objects are extracted from
   the M-NSLP message and passed to the Metering Manager, where they are
   interpreted and used to install Metering Configuration State.  The
   Metering Manager uses this state to configure the Monitoring Probe.

   The Policy Control determines whether the sender of the M-NSLP
   message is authorized to configure the Monitoring Probe.

   From the perspective of a single node, the request for configuration
   of Metering Entities may result from processing a local management
   request, or from processing an incoming M-NSLP message.  The local
   management may in turn be triggered by a local application, e.g. when
   a video is requested from a video server, or by a physically separate
   network node.

3.2.  Metering NSLP Messages

   The Metering NSLP messages are classified into 3 categories:
   o  request messages
   o  response messages
   o  asynchronous notifications

3.2.1.  CONFIGURE

   CONFIGURE is a M-NSLP request message.  It is used to create Metering
   Configuration State in a Metering Entity.

3.2.2.  REFRESH

   REFRESH is a M-NSLP request message.  It is used:
   o  to extend the lifetime of an existing M-NSLP session.
   o  for terminating a session (with session lifetime zero).
   o  to detect route changes at the NSLP layer.

3.2.3.  OPTIONS

   OPTIONS is a M-NSLP request message.  It is used to inquire the
   metetering capabilities of MNEs along the signaling path.





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt        [Page 9]


Internet-Draft                Metering NSLP                   March 2007


3.2.4.  RESPONSE

   The RESPONSE message is used to provide information about the result
   of a previous M-NSLP request.  This includes explicit confirmation of
   the state manipulation signaled in the CONFIGURE/REFRESH message or
   an error code.

3.2.5.  NOTIFY

   The NOTIFY message is an asynchronous notifications message used to
   convey information to a MNE.  It differs from RESPONSE messages in
   that it is sent asynchronously and does not need to refer to any
   particular state or previously received message.  The information
   conveyed by a NOTIFY message is typically related to error
   conditions.  An example would be a notification to the MNI about
   state being torn down.


4.  Design Decisions

4.1.  Soft State

   NSIS state is always soft state and needs to be refreshed.  The
   control information in CONFIGURE/REFRESH messages carry an object
   that determines the lifetime of a M-NSLP session.  The MNI suggests a
   lifetime for the session that it is being signaled for.  Each MNE
   participating in the metering process MAY or MAY not accept the
   suggested lifetime or MAY start the metering with a reduced lifetime,
   depending on the local policies of the MNEs.  This behavior is
   similar to the calculation of session lifetime in the NATFW-NSLP
   [I-D.ietf-nsis-nslp-natfw].

4.2.  Message Sequencing

   The order in which M-NSLP requests arrive influences the eventual
   configuration state that will be stored at a MNE.  Therefore the
   M-NSLP supports the detection of message duplication and re-ordering
   using a Message Sequence Number (MSN) object.  More Details on
   Message Sequencing are provided in Section 6.2.3

4.3.  Message Scoping

   Metering Entities at the edge of a signaling scope (for example, at
   the edge of the administrative domain of an ISP) MUST be marked
   accordingly.  The Metering NSLP does not provide means by itself to
   discover dynamically the border of the signaling scope.

   When a MNE recognize that it is at the edge of the signaling scope,



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 10]


Internet-Draft                Metering NSLP                   March 2007


   it MUST terminate the signaling and act as NSIS Responder (NR).

4.4.  Selection of MNEs

   An interesting feature of the Metering NSLP is that only a subset of
   MNEs on the data path might take part in the actual metering.
   Metering Entities taking part in the metering process are determined
   based, for example, on their type or position on the path.

   When a CONFIGURE message is sent, each MNE on the data path needs to
   determine whether it will take part in the metering process.  For
   this reason, the 'Selection of Metering Entities' object is included
   in CONFIGURE messages.

4.5.  Coordination of Metering Tasks

   The M-NSLP allocates different metering tasks to different Metering
   Entities on the signaling path depending on their position and
   metering capabilities.  A 'Correlation ID' is included in the MSPEC
   and distributed to the Metering Entities during the configuration
   process.  This 'Correlation ID' can be forwarded to the Collector,
   which can correlate Metering Records coming from different Metering
   Entities and belonging to the same session/measurement.

4.6.  Aggregation

   The metering configuration SHOULD allow aggregation of Metering
   Records belonging to the same user or application.  The information
   required for the aggregation must be specified in the MSPEC.  Such
   aggregation can be done in two ways.
   o  A Monitoring Probe separately collects and reports data for each
      micro flow (e.g., given for all different combinations of port
      numbers) contained in the macro flow that is signaled by the NTLP.
   o  A Monitoring Probe separately collects micro flows but reports all
      flows in a single record.

4.7.  Reaction to Route Changes

   M-NSLP automatically adapts to re-routing events.  State along the
   old path times out automatically.  When a new REFRESH message is
   initiated by the MNI and hits a MNE that is a new on the signaling
   path, the MNE sends a negative RESPONSE with error code "Unknown
   Session" backwards to the MNI.  The MNI MAY re-initiate the signaling
   along the new path.

   Since metering tasks are allocated dynamically to MNEs on the path,
   when a MNE receives a CONFIGURE message for an existing session, old
   state for this session MUST be torn down and a new session is created



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 11]


Internet-Draft                Metering NSLP                   March 2007


   in order to avoid inconsistencies with an old configuration.

4.8.  Metering Configuration Information

   The actual configuration information for the Metering Entities is
   carried within the MSPEC objects.  MSPEC objects are interpreted by
   the Metering Manager and SHOULD be opaque to M-NSLP Processing.  Each
   MSPEC object contains a meter configuration.  A single CONFIGURE
   message MAY contain multiple MSPEC objects describing different
   metering tasks, which MAY be allocated to different MNEs.

   The Metering NSLP does not provide its own format for encoding the
   MSPEC objects.  Instead, formats of existing protocols, such as IPFIX
   [I-D.ietf-ipfix-protocol], Diameter [RFC3588], or NetFlow [RFC3954],
   are re-used.  The encoding of an MSPEC object depends on the metering
   and reporting technology.  For example, the MSPEC object used for the
   configuration of an IPFIX device is encoded in IPFIX format.
   Technology-specific encoding avoids the problems of mapping the
   different semantics of information models for these technologies to
   each other.

4.9.  Required State Information

   For each M-NSLP session, the required state information at each MNE
   consists of:

   NTLP state

      NTLP state is required for each M-NSLP session at each MNE on the
      signaling path, even if the MNE is not taking part in the metering
      process, in order to avoid GIST re-discovering the MNE each time
      when it refreshes its routing state [I-D.ietf-nsis-ntlp].

   M-NSLP state

      M-NSLP state is required for each M-NSLP session at each MNE on
      the signaling path.  Even if the MNE is not taking part in the
      metering process a minimal session state is required, which
      consists of the Session Identifier (SID) and the Session Lifetime
      (Session_LT).
      Assume MNEs located on the signaling path, which are not taking
      part in the metering process, would not save M-NSLP state for this
      M-NSLP session.  Then when a MNE receives a REFRESH message with
      an unknown Session ID, it would not be able to make the
      difference:
      *  whether the MNE is new on the signaling path due to a route
         change




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 12]


Internet-Draft                Metering NSLP                   March 2007


      *  or whether the MNE has been already on the signaling path but
         is not taking part in the metering process.
      Therefore, the MNE needs to keep M-NSLP state for this session in
      order to be aware of it.  Implementations of the M-NSLP MAY
      include optimizations to reduce the amount of memory required if
      the session is known but the MNE is not taking part in the
      metering process.

   Metering Configuration State (Optional)

      Metering Configuration State is required for each M-NSLP only if
      the MNE is taking part in the metering process.  It includes the
      MSPEC objects which describe the metering tasks that are allocated
      to the MNE.



5.  Metering NSLP Messages and Objects

5.1.  Metering NSLP Objects

5.1.1.  The 'Session Identifier' Object (SID)

   SID is globally statistically unique identifier for a MNSLP session.
   SID is not carried explicitly by MNSLP messages.  It is rather
   carried by GIST.

   SID MUST be generated for each new MNSLP session by the MNI and
   provided to GIST via the GIST API.  All MNFs and the MNR receive the
   SID via the GIST API and MUST NOT modify it.

   Note that this is conform to the specification of GIST
   [I-D.ietf-nsis-ntlp]: Section 3.5.  (Signaling Sessions): "Signaling
   applications provide the session identifier (SID) whenever they wish
   to send a message, and GIST reports the SID when a message is
   received."

5.1.2.  The 'Message Sequence Number' Object (MSN)

   MSN is used to detect duplicate and lost Metering NSLP messages.  It
   is also used to to mach an incoming RESPONSE message to the
   appropriate request.

5.1.3.  The 'Selection of Metering Entities' Object (MNE_Selection)

   This object is required to determine which MNEs will actually take
   part in the metering.  The value of MNE_Selection can be one of the
   following:



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 13]


Internet-Draft                Metering NSLP                   March 2007


   o  FIRST: the first MNE in the signaling path, i.e. the NI.

   o  LAST: the last MNE signaling in the signaling path, i.e. the NR

   o  'FIRST_and_LAST': both the NI and the NR take part in the
      signaling.

   o  ANY: any available MNE can perform the metering.

   o  ALL: Each MNE capable of executing this metering request MUST
      perform it.  "ALL" must be interpreted here as "as many as
      possible".

   o  Enterprise-specific: Enterprises may wish to define their own
      methods to decide which Metering Entities should perform the
      metering.  In this case, the parameter 'Selection of Metering
      Entities' needs to be combined with an enterprise-specific
      identifier.  (See also
      http://www.iana.org/assignments/enterprise-numbers) If enterprises
      use their own defined methods for the MNE selection, some other
      M-NSLP objects not defined in this document may be required to
      take the decision which MNE will take part in the metering
      process.

5.1.4.  The 'Session Lifetime' Object (Session_LT)

   This object carries the requested lifetime for a M-NSLP session in a
   CONFIGURE / REFRESH message or the granted session lifetime in a
   RESPONSE message, in milliseconds.  When a M-NSLP session expires,
   the Metering Manager MUST configure the Monitoring Probe to stop the
   Metering.

   A value of zero for the 'Session Lifetime' object leads to immediate
   termination of the corresponding session.

5.1.5.  The 'MNSLP Hop Count' Object (MNSLP_Hop_Count)

   This object carries the number of previous MNEs on the signaling path
   for this session.  This object is a integer which starts by zero at
   the MNI and MUST be incremented by one at each MNSLP hop on the
   signaling path.

5.1.6.  The 'Information Code' Object (INFO)

   This object carries the response code, which may be an indication for
   either a successful or failed request depending on the value of the
   'response code' field (See Section 8.2.4 for more details).




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 14]


Internet-Draft                Metering NSLP                   March 2007


5.1.7.  MSPEC Objects

   The MSPEC objects describe the actual Configuration information.
   They are interpreted in the Metering Manager and SHOULD be opaque to
   M-NSLP Processing.  MSPEC objects are described separately in
   Section 5.3.

5.2.  Metering NSLP Messages

   This section defines which objects are carried in each Metering NSLP
   message.  The description is provided in Augmented Backus-Naur Form
   (ABNF) specified in [RFC4234].  Message format at the bit-level is
   provided in Section 8

   The ABNF implies an order for the objects in a message.  However, in
   many (but not all) cases, object order makes no logical difference.
   An implementation should create messages with the objects in the
   order shown here, but accept the objects in any order, except for
   MSPEC object(s) which always appear last in the message, and whose
   mutual order matters.

   All M-NSLP messages start with a common header 'HEADER' which is
   defined in Section 8

   Note that the Session ID (SID) is not explicitly mentioned in this
   notation, since it is provided in GIST.

5.2.1.  CONFIGURE

   The format of a CONFIGURE message is as follows:

   CONFIGURE = HEADER MSN Session_LT MNE_Selection [MNSLP_Hop_Count]
   <1>*MSPEC

   (According to [RFC4234] '<1>*MSPEC' means 'one or more MSPEC
   objects')

5.2.2.  REFRESH

   The format of a REFRESH message is as follows:

   REFRESH = HEADER MSN Session_LT

5.2.3.  OPTIONS

   The format of a OPTIONS message is as follows:

   OPTIONS = HEADER MSN



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 15]


Internet-Draft                Metering NSLP                   March 2007


5.2.4.  RESPONSE

   The format of a RESPONSE message is as follows:

   RESPONSE = HEADER MSN INFO Session_LT <0>*MSPEC

   (According to [RFC4234] '<0>*MSPEC' means 'zero or more MSPEC
   objects')

   The MSN MUST be the same as in the corresponding M-NSLP request in
   order to match a RESPONSE message to the appropriate request

   Session_LT carries the granted session lifetime, which might be lower
   than the session lifetime requested by the MNI.

   NO MSPEC object MUST be included if INFO indicates a successful
   confirmation of the request.  The MSPEC objects are required only to
   report a failure in case the MSPEC objects list in the CONFIGURE
   message, or a sub-set of it, can not be processed.

5.2.5.  NOTIFY

   The format of a NOTIFY message is as follow:

   NOTIFY = HEADER INFO

   The INFO indicates the reason for the notification.

5.3.  MSPEC Objects

   As mentioned above, the MSPEC objects describe the actual
   configuration information.  They are interpreted in the Metering
   Manager and SHOULD be opaque to M-NSLP Processing.  Each MSPEC object
   contains a meter configuration.  The MRI provides additional
   information to the MSPEC object on the flows/packets to be metered.
   The combination of the MRI and an MSPEC object contains a complete
   description of a requested metering task.  A single CONFIGURE message
   may contain multiple MSPEC objects describing different metering
   tasks.

   There is no common format or semantics for encoding metering tasks
   within an MSPEC object.  The encoding of an MSPEC object depends on
   the requested metering and reporting technology, such as IPFIX,
   Diameter, or NetFlow.

   There are different types of MSPEC objects depending on the metering
   and reporting technology.  For example, there are IPFIX MSPEC
   objects, Diamter MSPEC objects, etc.  The object type, which is



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 16]


Internet-Draft                Metering NSLP                   March 2007


   provided in the object header as described in Section 8.2, implicits
   the requested metering and reporting technology.

   Independently of the encoding, each MSPEC object MUST, in combination
   with the MRI, contain sufficient information for configuring an MNE
   to peform a metering task.  Specifications of MSPEC objects MUST
   ensure that they provide sufficient means for configuring the MNE as
   described in sections 4.1.2 and 4.2.2 of
   [I-D.fessi-nsis-m-nslp-framework].

   Below the MSPEC object for IPFIX metering tasks is specified.  MSPEC
   objects for other meters may be defined in further standards
   documents.  Proprietary MSPEC objects MAY be also used.

5.3.1.  IPFIX MSPEC Object

   The IPFIX MSPEC object uses structure, semantics and encoding of
   IPFIX Messages as defined in [I-D.ietf-ipfix-protocol] and
   [I-D.ietf-ipfix-info].  An IPFIX MSPEC object consists of a single
   IPFIX Message that contains three Sets, a Template Set, an Option
   Template Set, and a Data Set. Each set contains a single record only.

   Fields of the header of the contained IPFIX Message are filled with
   values according to section 3.1 of [I-D.ietf-ipfix-protocol] except
   for fields "Export Time" and "Observation Domain ID" which must be
   both set to 0x00000000.

   The Template Record in the Template Set defines the requested
   reporting.  Except for the Template ID in the Template Record Header,
   the MNE MUST use exactly this Template Record for reporting metering
   results.  The MNE also MUST use the Template ID received in the
   Template record for its metering reports.  But if there is a
   collision caused by two different MSPEC objects (potentially from
   different NSIS sessions) that would violate the uniqueness of
   Template IDs as specified in section 3.4.1 of
   [I-D.ietf-ipfix-protocol], then the MNE MUST solve this conflict by
   modifying Template IDs.  In order to keep the probability of such a
   collision low, the Template ID SHOULD be a randomly generated number.

   The Option Template Record in the Option Template Set describes the
   format of the single Data Record in the Data Set. To the Template ID
   the same rules apply as for the Template Record.  The Scope Field
   Count is always 0.

   The Data Record in the Data Set contains the requested metering
   configuration.  It is structured according to the Option Template
   Record in the Option Template Set. It MUST contain the following
   Information Elements that are specified in [I-D.ietf-ipfix-info].



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 17]


Internet-Draft                Metering NSLP                   March 2007


   flowKeyIndicator

      This Information Element identifies which of the reported Flow
      properties are Flow Keys.

   collectorIPv4Address or collectorIPv6Address, respectively

      The IPv4 or IPv6 address, respectively, to which metering results
      are requested to be reported.

   collectorProtocolVersion

      The version of the IPFIX protocol to be used.

   collectorTransportProtocol and collectorTransportPort

      The transport protocol and transport port number to be used for
      reporting metering results

   The Data record MAY contain further Information Elements for
   specifying the metering task, for example, the flowIdleTimeout.

   If flow properties to be measured are specified in the Data record,
   they serve as filter.  Only Flows that match the values of all these
   Information Element MUST be reported by the MNE.  If multiple values
   are contained for the same property, i.e. it multiple Information
   Elements with the same Information Element identifier are contained,
   then it is sufficient if one of these values is matched by a Flow.


6.  Processing Rules

6.1.  Session State Machine

   The hereby presented state machine of a M-NSLP session outlines the
   operation of the M-NSLP.  It has three main states:

   'closed':

      At this state, the MNE does not keep any state for the session.

   'pending':

      At this state a CONFIGURE message has been received.  The
      'pending' state consists of 2 sub-states






Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 18]


Internet-Draft                Metering NSLP                   March 2007


      pending.forward

         The MNE is not taking part in the metering process.  Instead,
         it is just expecting a confirmation to know that the session is
         active and some other MNEs will be metering.

      pending.participating

         The MNE is actively taking part in the metering process.  The
         MNE has been configured.  However, the configuration has not
         been activated yet, i.e. metering function has not been
         started.

   'metering':

      At this state the configuration request has been successfully
      confirmed with an appropriate RESPONSE message.  The 'metering'
      state consists also of 2 sub-states.

      metering.forward

         The MNE is not actively taking part in the metering process.
         Instead, it is informed that the session is active and there
         are some other MNEs along the signaling path for this session
         that took over the metering process.

      metering.participating

         The MNE is actively taking part in the metering process The MNE
         is metering according to a metering configuration received by a
         CONFIGURE message.


   A session is uniquely identified by the SID.  All sessions start in
   state 'closed'.  Transitions between states are caused by events:

   CONF:

      This transition is triggered by a CONFIGURE message that is
      received and processed successfully by the MNE and that identifies
      a new session.

   CONF-O:

      This transition is triggered by a CONFIGURE message that is
      received and processed successfully by the MNE and that identifies
      an existing session in state 'pending' or 'metering'.  This
      transition leads always to the state 'closed' in order to avoid



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 19]


Internet-Draft                Metering NSLP                   March 2007


      inconsistencies with old configurations.  Furthermore, this
      transition MUST be immediately followed by a 'CONF' transition,
      i.e. after the old session is torn down, a new session is created.

   REFR:

      This transition is triggered by a REFRESH message that identifies
      an existing session in state 'pending' or 'metering'.

   RESP-P:

      This transition is triggered by a positive RESPONSE message that
      indicates that a metering configuration request or a refreshing
      request can be activated.  This transaction always leads to state
      'metering'.

   RESP-N:

      This transition is triggered by a negative RESPONSE message.  This
      transaction always leads to state 'closed'.

   T-OUT-1:

      This transition is triggered by a timeout of a session in state
      'pending'.  The time interval for this timeout is typically large
      enough in order to tolerate network failures, network congestion
      and slow MNEs along the signaling path.  This transition always
      leads to state 'closed'.

   T-OUT-2:

      This transition is triggered by a timeout of a session in state
      'metering'.  The time interval for this timeout is defined by the
      MNSLP session lifetime.  This transition always leads to state
      'closed'.
















Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 20]


Internet-Draft                Metering NSLP                   March 2007


            REFR +----+
                 |    v
              +----------+
              | session  |
              | closed   |<---------------+
              +----------+                |
                 |    ^                   |
                 |    | CONF-O            | CONF-O
            CONF |    | RESP-N            | RESP-N
                 v    | T-OUT-1           | T-OUT-2
              +----------+           +----------+
              | pending  |  RESP-P   | metering |
              |          |---------->|          |
              +----------+           +----------+
                 |    ^                 |    ^
            REFR |    |            REFR |    |
                 +----+          RESP-P +----+



                  Figure 2: M-NSLP Session State Machine

6.2.  Standard Message Processing Rules

6.2.1.  Message Parsing

   When a M-NSLP message is received, the MNE first checks the message
   format.  In case of a malformed message or a mandatory object is
   missing, the MNE MUST NOT propagate the message any further.  If the
   message has been a request the MNE MUST construct an RESPONSE message
   indicating the error condition and send it back to towards the MNI.
   If it has been a response, the message is discarded silently.

   If a message contains an object of an unrecognized type, then the
   behavior depends on the object type value.

6.2.2.  Authentication and Authorization

   When a M-NSLP message is received, the MNE MUST determine whether the
   sender of the request is authenticated and authorized before any
   state changing actions are performed.

6.2.3.  Message Sequencing

   Message sequencing in the Metering NSLP is identical to message
   sequencing in the NATFW NSLP.

   In more details:



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 21]


Internet-Draft                Metering NSLP                   March 2007


   M-NSLP messages need to carry an identifier so that all MNEs along
   the path can distinguish messages sent at different points in time.
   Messages can be lost along the path or duplicated.  So all MNEs
   should be able to identify either old messages that have been
   received before (duplicated), or the case that messages have been
   lost before (loss).  This requires every Metering message to carry a
   message sequence number (MSN), see also Section 5.1.2.

   The MSN MUST be set by the NI and MUST NOT be set or modified by any
   other MNE.  The initial value for the MSN MUST be generated randomly
   and MUST be unique only within the session for which it is used.  The
   NI MUST increment the MSN by one for every message sent.  Once the
   MSN has reached the maximum value, the next value it takes is zero.
   All MNEs MUST use the algorithm defined in [RFC1982] to detect MSN
   wrap-arounds.

   NSIS forwarders and the responder store the MSN from the initial
   CONFIGURE packet which creates the session as the start value for the
   session.  NFs and NRs MUST include the received MSN value in the
   corresponding RESPONSE message that they generate.

   When receiving a request message, a MNE uses the MSN given in the
   message to determine whether the state being requested is different
   to the state already installed.  If the received MSN value is equal
   to or lower than the stored MSN value, this can indicate a duplicated
   or replayed message.  In this case, the message MUST NOT have any
   impact the state of the MNE or the MNSLP session.  However, the
   message MUST be forwarded towards the next MNSLP hop, since one or
   more of the MNEs on the rest of the signaling path may have not
   received this message yet.

   If the received MSN value is greater than the already stored MSN
   value, the MNE MUST update its stored state accordingly, if permitted
   by all security checks, and stores the updated MSN value accordingly.

6.2.4.  MNSLP Hop Counting

   Depending on the application scenario for the MNSLP, MNEs may need to
   know their position on the signaling path.  In this case, a MNE needs
   to make the difference between:
   o  the number of IP hops between the MNI and itself
   o  the number of GIST hops between the MNI and itself
   o  the number of MNSLP hops between the MNI and itself

   The GIST-hop-count and IP-TTL can be provided by the GIST API as
   described in [I-D.ietf-nsis-ntlp] (Section B.1 and Section B.2).

   The MNI MAY introduce an 'MNSLP Hop Count' object in the CONFIGURE



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 22]


Internet-Draft                Metering NSLP                   March 2007


   message.  In cases it does, it MUST set the 'MNSLP Hop Count' to
   zero.

   If a 'MNSLP Hop Count' object is included in a CONFIGURE message,
   MNFs and MNRs MUST increment the 'MNSLP Hop Count' by one before the
   message is forwarded to the next MNSLP hop.

6.3.  Message Processing Rules

6.3.1.  CONFIGURE

   When a MNE receives a CONFIGURE message, and after successful message
   parsing and authentication/authorization are performed, the MNE
   performs a lookup in its M-NSLP session table.  If the session
   already exists, the state for this session MUST be torn down and a
   new session MUST be created in order to avoid inconsistencies with
   earlier configurations due to the dynamic allocation of the MSPEC
   objects to the MNEs.

   Now, regardless of whether the session is new or has been renewed,
   the MNE needs to figure out if it will take part in the metering
   process based on the MNE_Selection object, the MSPEC objects list and
   the capabilities of the MNE.

6.3.1.1.  MNE_Selection is ALL

   o  If the MNE is capable of metering the objects in the MSPEC objects
      list, then the MNE is taking part in the metering process.  The
      MNE MUST change the current session state to
      'pending.participating'.

   o  If the MNE is NOT capable of metering the objects in the MSPEC
      objects list, then the MNE is NOT taking part in the metering
      process.  The MNE MUST change the current session state to
      'pending.forward'

6.3.1.2.  MNE_Selection is FIRST_and_LAST

   If MNE_Selection is FIRST_and_LAST and the MNE is the first or the
   last on the signaling path:

   o  If the MNE is capable of metering the objects in the MSPEC objects
      list, then the MNE is taking part in the metering process.  The
      MNE MUST change the current session state to
      'pending.participating'.






Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 23]


Internet-Draft                Metering NSLP                   March 2007


   o  If MSPEC objects can not be metered, i.e. the MNE is the first or
      the last on the signaling path but is not capable to measure the
      objects given in the MSPEC objects list, the MNE generates a
      negative RESPONSE message with the appropriate INFO object.  The
      MNE changes the current session state to 'closed'.
   o  EDITORIAL NOTE: The case FIRST_and_LAST is different from the
      cases ALL and ANY here.

   If MNE_Selection is FIRST_and_LAST and the MNE is NOT the first NOR
   the last on the signaling path, the MNE MUST change the current
   session state to 'pending.forward'.

6.3.1.3.  MNE_Selection is ANY

   In case MNE_Selection is 'ANY', the MNE inspects the MSPEC objects
   list and removes those objects that it is capable to meter and adds
   them to its local MSPEC objects list for this session.  This local
   MSPEC objects list represents the list of metering tasks allocated to
   this MNE for this session.
   o  After inspecting the MSPEC objects list in the CONFIGURE message,
      if the local MSPEC objects list is empty, i.e. the MNE is not able
      to meter any of the given objects in the MSPEC objects list, the
      MNE MUST change the current session state to 'pending.forward'.
   o  If the local MSPEC objects list is NOT empty, i.e. the MNE has
      been allocated some metering tasks from the MSPEC objects list,
      the MNE MUST change the current session state to
      'pending.participating'.  The local MSPEC objects is stored in the
      Metering Configuration State in order to use when the
      configuration will be activated.

6.3.2.  REFRESH

   When a MNE receives a REFRESH message, and after successful message
   parsing and authentication/authorization are performed, the MNE
   performs a lookup in its M-NSLP session table.
   o  If the Session ID is not known, the MNE constructs a negative
      RESPONSE message with the appropriate error code and sends it
      upstream towards the MNI.
   o  If the Session ID is found, the MNE remembers the requested
      lifetime in the REFRESH message and waits for a confirmation with
      a RESPONSE message.  The current session state remains the same.

6.3.3.  OPTIONS

   tbd.






Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 24]


Internet-Draft                Metering NSLP                   March 2007


6.3.4.  RESPONSE

   When a MNE receives a RESPONSE message and after successful message
   parsing and authentication/authorization are performed, the remaining
   processing of the RESPONSE message depends on whether it is a
   negative RESPONSE or a positive RESPONSE.  If it is a negative
   RESPONSE with the appropriate INFO object:
   o  The MNE MUST change the current state for this session to
      'closed'.
   o  The MNE MAY keep state information for this session for
      optimization purposes, since the the MNI may re-initiate the
      signaling with different parameters soon.
   o  The MNE MUST forward the message upstream towards the MNI as
      described in Section 6.4.

   When the MNI receives this message it MAY take the appropriate action
   based on the content of the INFO object.

   If the RESPONSE message is a positive RESONSE, the processing of the
   message depends on the type of the corresponding M-NSLP request:

   RESPONSE to a CONFIGURE message

      The pending configuration can be activated.  If the session is
      currently in state 'pending.participating' the MNE MUST change the
      session state to 'metering.participating', and the Monitoring
      Probe MUST be configured to start the metering.
      If the session is in state 'pending.forward' the MNE MUST change
      the session state to 'metering.forward'.  No configuration action
      with the Monitoring Probe is taken.

   RESPONSE to a REFRESH message

      All existing timeouts for this session are reset.  The session
      lifetime is extended with the lifetime given in the RESPONSE
      message.  Note that this can be different from the session
      lifetime given in the previous REFRESH message.

   In both cases, the MNE updates the session lifetime.  If the session
   lifetime is zero, this implies that the session state is changed
   immediately to 'closed'.

6.3.5.  NOTIFY

   tbd.






Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 25]


Internet-Draft                Metering NSLP                   March 2007


6.4.  Message Forwarding

   CONFIGURE / REFRESH

      After a M-NSLP request is successfully processed as described in
      Section 6.3 (no error has been generated), then the session can be
      either in state 'pending' or 'metering'.  Now, MNE needs to decide
      whether to forward the M-NSLP request towards the MNR or to
      construct a positive RESPONSE message.  M-NSLP requests MUST be
      forwarded downstream except if:
      *  the M-NSLP request has reached the MNR
      *  the 'scoping' flag is set and the signaling scope has been
         reached.
      *  all the involved MNEs in the metering process for this session
         have been reached.

      The latter case can occur with a CONFIGURE request if
      MNE_Selection is 'ANY' and the MSPEC objects list has become
      empty, i.e. an appropriate MNE has been already found for each
      object in the MSPEC objects list and all the metering tasks have
      been allocated to some Metering Entities.

      EDITORIAL NOTE: it has to verified whether this is the only case.

      In this case, the MNE MUST act as a MNR for this session from now
      on.  All the remaining requests MUST NOT be forwarded any further.

   RESPONSE / NOTIFY

      M-NSLP response messages and asynchronous notifications are
      forwarded upstream, i.e. the reverse direction of the data flow,
      until they reach the MNI.

6.5.  Interaction with GIST

   M-NSLP request messages (CONFIGURE or REFRESH) are initiated by the
   MNI and forwarded downstream, i.e. in the same direction as the data
   flow, towards the MNR, using the GIST API.

   M-NSLP response messages can be initiated by the MNR or by any MNF on
   the signaling path and forwarded upstream, i.e. in the reverse
   direction as the data flow, towards the MNI, using the GIST API.

   M-NSLP asynchronous notifications can be initiated by any MNE on the
   signaling path and forwarded upstream, i.e. in the reverse direction
   as the data flow, towards the MNI, using the GIST API.

   All M-NSLP signaling is transported using GIST C-mode.



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 26]


Internet-Draft                Metering NSLP                   March 2007


   EDITORIAL NOTE: it should be verified whether D-mode might be also an
   option for initial configuration messages.  However, authentication/
   authorization issues need to be considered.


7.  Examples of Operation

7.1.  Example with MNE_Selection is ANY

   The MNI constructs a CONFIGURE message with the required MSPEC
   objects, and sends it towards the MNR.  Assume 2 MSPEC objects are
   included, for example, MSPEC1 for 'counting bytes', and MSPEC2 for
   'reporting the usage of the wireless link'.  Assume further that MNI
   itself can perform MSPEC1 while and MNF2 can perform MSPEC2, for
   example, because it is an access router managing a range of WLAN
   networks.  MNR can be, for example, the WLAN access point.

   The CONFIGURE message is interpreted by the MNEs along the data path.

   MNI removes MSPEC1 from the MSPEC objects list, changes its session
   state from 'closed' to 'pending.participating' and forwards the
   CONFIGURE message to MNF1.

   MNF1 receives the CONFIGURE message with only MSPEC2 in the MSPEC
   objects list.  However, MNF1 does not have the capabilities to meter
   and report the usage of the wireless link.  MNF1 changes its session
   state from 'closed' to 'pending.forward' and forwards the CONFIGURE
   message to MNF2.

   MNF2 interprets the CONFIGURE, removes MSPEC2 from the MSPEC objects
   list.  Furthermore, it notices that the MSPEC object lists is now
   empty.  Therefore, MNF2 replies with a positive RESPONSE message and
   becomes Responder for this session.  Subsequent signaling for this
   session is stopped at MNF2 as shown in Figure 4.  MNF2 starts the
   metering, changes the session state to 'metering.participating',
   constructs a positive RESPONSE message and sends it to MN1.

   MNF1 receives the RESPONSE message and changes the session state to
   'metering.forward'.

   MNI receives the RESPONSE message, starts the metering and changes
   the session state to 'metering.participating'.









Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 27]


Internet-Draft                Metering NSLP                   March 2007


       +---+  CONFIGURE  +--- +  CONFIGURE  +-- -+          +---+
       |   |------------>|    |------------>|    |          |   |
       |MNI|             |MNF1|             |MNF2|          |MNR|
       |   |<------------|    |<------------|    |          |   |
       +---+   RESPONSE  +--- +   RESPONSE  +----+          +---+

    Figure 3: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ANY'


       +---+    REFRESH  +---+    REFRESH  +---+          +---+
       |   |------------>|   |------------>|   |          |   |
       |MNI|             |MNF|             |MNF|          |MNR|
       |   |<------------|   |<------------|   |          |   |
       +---+   RESPONSE  +---+   RESPONSE  +---+          +---+

     Figure 4: REFRESH-RESPONSE Message Flow with MNE_Selection 'ANY'

7.2.  Example with MNE_Selection is ALL

   The MNI constructs a CONFIGURE message with the required MSPEC
   objects, and sends it towards the MNR.  The message is interpreted by
   each MNEs on the data path.  Each MNE changes its state for this
   session to 'pending.participating' or 'pending.forward' depending on
   whether they are taking part of the metering process.

   The MNR replies with a positive RESPONSE message.  The RESPONSE
   message is interpreted by each MNE.  Each MNE changes the session
   state to 'metering.participating' or 'metering.forward' depending on
   whether they are taking part of the metering process.



       +---+  CONFIGURE  +---+  CONFIGURE  +---+  CONFIGURE  +---+
       |   |------------>|   |------------>|   |------------>|   |
       |MNI|             |MNF|             |MNF|             |MNR|
       |   |<------------|   |<------------|   |<------------|   |
       +---+   RESPONSE  +---+   RESPONSE  +---+   RESPONSE  +---+

    Figure 5: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ALL'

   Similarly, a REFRESH message is initiated by MNI, travels towards the
   MNR where a RESPONSE is issued and sent back.









Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 28]


Internet-Draft                Metering NSLP                   March 2007


       +---+    REFRESH  +---+    REFRESH  +---+    REFRESH  +---+
       |   |------------>|   |------------>|   |------------>|   |
       |MNI|             |MNF|             |MNF|             |MNR|
       |   |<------------|   |<------------|   |<------------|   |
       +---+   RESPONSE  +---+   RESPONSE  +---+   RESPONSE  +---+

     Figure 6: REFRESH-RESPONSE Message Flow with MNE_Selection 'ALL'

7.3.  Example with MNE_Selection is FIRST_and_LAST

   The MNI constructs a CONFIGURE message with the required MSPEC
   objects, and sends it towards the MNR.  The message is interpreted by
   each MNEs on the data path.  Each MNE changes its state for this
   session to 'pending.forward' except MNI itself and MNR, which perform
   a transition to the state 'pending.participating'.

   The MNR replies with a positive RESPONSE message.  The RESPONSE
   message is interpreted by each MNE.  Each MNE changes the session
   state to 'metering.forward' except MNR and MNI, which perform a
   transition to the state 'metering.participating'.


       +---+  CONFIGURE  +---+  CONFIGURE  +---+  CONFIGURE  +---+
       |   |------------>|   |------------>|   |------------>|   |
       |MNI|             |MNF|             |MNF|             |MNR|
       |   |<------------|   |<------------|   |<------------|   |
       +---+   RESPONSE  +---+   RESPONSE  +---+   RESPONSE  +---+

       Figure 7: CONFIGURE-RESPONSE Message Flow with MNE_Selection
                             'FIRST_and_LAST'

   Similarly, a REFRESH message is initiated by MNI, travels towards the
   MNR where a RESPONSE is issued and sent back.


       +---+    REFRESH  +---+    REFRESH  +---+    REFRESH  +---+
       |   |------------>|   |------------>|   |------------>|   |
       |MNI|             |MNF|             |MNF|             |MNR|
       |   |<------------|   |<------------|   |<------------|   |
       +---+   RESPONSE  +---+   RESPONSE  +---+   RESPONSE  +---+

        Figure 8: REFRESH-RESPONSE Message Flow with MNE_Selection
                             'FIRST_and_LAST'








Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 29]


Internet-Draft                Metering NSLP                   March 2007


7.4.  Example with a Route Changes

   Assume a topology as in Figure 9:



           +-------+    +-------+     +-------+    +-------+
           |  MNI  |----|  MNF1 |-----|  MNF2 |----|  MNR1 |
           +-------+    +-------+ |   +-------+    +-------+
                                  |
                                  |   +-------+    +-------+    +-----+
                                  +---|  MNF3 |----|  MNR2 |----|host |
                                      +-------+    +-------+    +-----+


                  Figure 9: Example with a Route Change'

   After a route change MNF2 and MNR1 are not on the signaling path
   anymore.  MNF3 is new on the signaling path and receives a REFRESH
   message with an unknown Session ID.  It sends a negative RESPONSE
   with error code "Unknown Session".

   MNI receives the negative RESPONSE and re-initiates the signaling
   with a CONFIGURE message with the same Session ID.

   When the MNE receives a CONFIGURE message with the same Session ID it
   re-starts the configuration process: the session is considered as a
   new session.


8.  Bit-Level Formats and Error Messages

8.1.  Metering NSLP Messages

   All Metering NSLP messages start with a common header 'HEADER'.  The
   Metering NSLP common header is similar to the QoS NSLP header.  Note
   that it is not the same as the GIST Common Header.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Message Type  | Message Flags |      Generic Flags            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10: M-NSLP Message Common Header

   The fields in the common header are as follows:




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 30]


Internet-Draft                Metering NSLP                   March 2007


   Message Type: 8 bits

         1 = CONFIGURE
         2 = RESPONSE
         3 = NOTIFY

   Message-specific flags: 8 bits
      These flags are defined as part of the specification of individual
      messages.

   Generic flags: 16 bits
      There exists currently one generic flag, the Scoping bit (S).  The
      use of the S-bit is described with each message that makes use of
      it.

      The set of appropriate flags depends on the particular message
      being processed.  Any bit not defined as a flag for a particular
      message MUST be set to zero on sending and MUST be ignored on
      receiving.

8.2.  Metering NSLP Objects

   The Metering NSLP uses the Type-Length-Value (TLV) object format
   defined by GIST [I-D.ietf-nsis-ntlp].  Every object consists of one
   or more 32-bit words with a one-word header.  For convenience the
   standard object header is shown here:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|B|r|r|         Type          |r|r|r|r|        Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: M-NSLP Object Common Header

   The value for the Type field comes from Metering NSLP object type
   space, the various objects are presented in subsequent sections.  The
   Length field is given in units of 32 bit words and measures the
   length of the Value component of the TLV object (i.e., it does not
   include the standard header).

   The bits marked 'A' and 'B' are extensibility flags, and used to
   signal the desired treatment for objects whose treatment has not been
   defined in the protocol specification (i.e., whose Type field is
   unknown at the receiver).

   EDITORIAL NOTE: include text here for the explanation of the meaning



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 31]


Internet-Draft                Metering NSLP                   March 2007


   of the A and B bits.

8.2.1.  MSN

   Type:   MNSLP_MSN

   Length: 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Message Sequence Number                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 12: Message Sequence Number Object

8.2.2.  Session_LT

   Type:   MNSLP_Session_LT

   Length: 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Session Lifetime                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 13: Session Lifetime Object

8.2.3.  MNE_Selection

   Type:   MNSLP_MNE_Selection

   Length: 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Selection of Metering Entities                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 14: Selection of Metering Entities Object

   Possible values are:
      1 = ALL
      2 = ANY
      3 = FIRST
      4 = LAST





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 32]


Internet-Draft                Metering NSLP                   March 2007


      5 = FIRST_and_LAST
      greater than 1024 : Enterprise Specific

   EDITORIAL NOTE: it still needs to be defined in the case Enterprise
   Specific, how MNSLP_SelectionMNEs is encoded.

8.2.4.  INFO

   This object carries the response code, which may be indications for
   either a successful request or failed request depending on the value
   of the 'response code' field.

   Note that the format of this object is similar the INFO object for
   the NATFW NSLP.

   Type:   MNSLP_INFO

   Length: 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Resv. | Class | Response Code |         Object Type           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 15: Information Code Object

   The field 'Resv.' is reserved for future extensions and MUST be set
   to zero when generating such an object and MUST be ignored when
   receiving.  The 'Object Type' field contains the type of the object
   causing the error.  The value of 'Object Type' is set to 0, if no
   object is concerned.  The 4 bit class field contains the severity
   class.  The following classes are defined:
   o  0x1: Informational (NOTIFY only)
   o  0x2: Success
   o  0x3: Protocol error
   o  0x4: Transient failure
   o  0x5: Permanent failure
   o  0x6: Signaling session failures

   EDITORIAL NOTE: Response Codes need to be defined here.

8.2.5.  MSPEC Objects

   Type:

      Different types are possible.





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 33]


Internet-Draft                Metering NSLP                   March 2007


      *  MNSLP_IPFIX_MSPEC
      *  MNSLP_DIAMETER_MSPEC
      *  MNSLP_NETFLOW9
      Note that this list is extensible.
   Length: Variable.



9.  Mapping onto M-NSLP Requirements

   EDITORIAL NOTE: This section needs to be updated.

   With the design described above, the requirements from
   [I-D.fessi-nsis-m-nslp-framework] are at this point satisfied as
   follows:

   Extensibility:

      The actual configuration information is encapsulated in the MSPEC.
      The MSPEC is designed such as it is interpreted by the Metering
      Manager and can be opaque to the M-NSLP processing.  Furthermore,
      the MSPEC can be easily extended.  Therefore, from the point of
      view of the configuration information, this requirement is
      fulfilled.  Note however, that the Metering NSLP in its current
      design might show some lack of extensibility.  For example,
      considering the selection of the MNEs, it might be useful for
      future application of the Metering NSLP to have the option "ANY
      N", where N is greater than one.

   Interoperability:

      Again, whether different metering solutions can interwork depends
      on how the MSPEC is designed.  In QoS NSLP, the QSpec template
      design [I-D.ietf-nsis-qspec] aims at similar extensibility and
      interoperability.  It needs to be studied whether or not the
      solutions chosen by the QSpec can also be applied to the MSPEC.

   Flexible metering models:

      As above, this is an issue of MSPEC design.

   Distinguishing flows

      The aggregation feature detailed in this requirement can be
      realized as described in Section 4.6.






Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 34]


Internet-Draft                Metering NSLP                   March 2007


   Flexible data collection:

      Another issue that can be fixed in the MSPEC.

   Location of Metering Entities:

      MNEs, including MNI and MNR can be located anywhere on the data
      path.

   Access parameters of the Collector Information:

      Access parameters of the Collector Information on how to deliver
      flow records to the Collector is coded in the MSPEC.

   Configuration of Metering Entities:

      The protocol can configure Metering Entities that are MNEs, or
      that are controlled by MNEs.

   Selection of Metering Entities:

      As described in Section 4.4, a MNE should be able to decide to
      pull out of the metering process.  This is realized by the
      'Selection of Metering Entities' object.

   Metering Configuration State installation and removal:

      By means of the CONFIGURE message, the protocol can install and
      remove Metering Configuration State.

   Initiation and maintenance of metering tasks:

      Triggers and correlation identifier are transported in the MSPEC.

   Reaction to Route Changes:

      The protocol detects route changes by a REFRESH or a refreshing
      CONFIGURE message and installs state along the new route, as
      described in Section 4.7.

   Scoping of configuration:

      The M-NSLP needs to provide sufficient means for flexible scoping
      signaling messages.

   Requirements not mentioned in this list are not yet addressed.





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 35]


Internet-Draft                Metering NSLP                   March 2007


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

   An extensive analysis of security issues related to the Metering NSLP
   is presented in Section 7 of [I-D.fessi-nsis-m-nslp-framework].
   Based on this section, future versions of the M-NSLP protocol
   specification will elaborate the required security mechanisms for the
   M-NSLP.


11.  Open Issues

   Open issues for the Metering NSLP are discussed here:
   https://www.ri.uni-tuebingen.de/cgi-bin/roundup.cgi/mnslp/


12.  Acknowledgements

   The authors would like to thank Robert Hancock, Martin Stiemerling
   and Andreas Klenk for their valuable input.

   Furthermore, the authors would like to thank Angie So.  By providing
   the first running prototype of the Metering NSLP, she gave us a
   helpful feedback for the protocol specification.


13.  References

13.1.  Normative References

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signalling Transport", draft-ietf-nsis-ntlp-12 (work in
              progress), March 2007.

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

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,



Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 36]


Internet-Draft                Metering NSLP                   March 2007


              August 1996.

13.2.  Informative References

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", RFC 3954, October 2004.

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.

   [I-D.ietf-ipfix-protocol]
              Claise, B., "Specification of the IPFIX Protocol for the
              Exchange", draft-ietf-ipfix-protocol-24 (work in
              progress), November 2006.

   [I-D.ietf-ipfix-info]
              Quittek, J., "Information Model for IP Flow Information
              Export", draft-ietf-ipfix-info-15 (work in progress),
              February 2007.

   [I-D.ietf-psamp-sample-tech]
              Zseby, T., "Sampling and Filtering Techniques for IP
              Packet Selection", draft-ietf-psamp-sample-tech-07 (work
              in progress), July 2005.

   [I-D.ietf-psamp-mib]
              Dietz, T. and B. Claise, "Definitions of Managed Objects
              for Packet Sampling", draft-ietf-psamp-mib-06 (work in
              progress), June 2006.

   [I-D.ietf-psamp-info]
              Dietz, T., "Information Model for Packet Sampling
              Exports", draft-ietf-psamp-info-05 (work in progress),
              October 2006.




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 37]


Internet-Draft                Metering NSLP                   March 2007


   [I-D.dressler-ipfix-aggregation]
              Dressler, F., "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-03 (work in progress),
              June 2006.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [I-D.ietf-nsis-qos-nslp]
              Manner, J., "NSLP for Quality-of-Service Signaling",
              draft-ietf-nsis-qos-nslp-12 (work in progress),
              October 2006.

   [I-D.ietf-nsis-fw]
              Hancock, R., "Next Steps in Signaling: Framework",
              draft-ietf-nsis-fw-07 (work in progress), December 2004.

   [I-D.ietf-nsis-nslp-natfw]
              Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
              Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in
              progress), October 2006.

   [I-D.ietf-nsis-qspec]
              Ash, J., "QoS NSLP QSPEC Template",
              draft-ietf-nsis-qspec-15 (work in progress),
              February 2007.

   [I-D.fessi-nsis-m-nslp-framework]
              Fessi, A., "Framework for Metering NSLP",
              draft-fessi-nsis-m-nslp-framework-03 (work in progress),
              June 2006.

   [I-D.ietf-aaa-diameter-cc]
              Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H.
              Hakala, "Diameter Credit-control Application",
              draft-ietf-aaa-diameter-cc-06 (work in progress),
              August 2004.

   [3GPP.32.240]
              3GPP, "Telecommunication management; Charging management;
              Charging architecture and principles", 3GPP TS 32.240
              6.0.0, September 2004.








Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 38]


Internet-Draft                Metering NSLP                   March 2007


Authors' Addresses

   Ali Fessi
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Sand 13
   Tuebingen  72072
   Germany

   Phone: +49 7071 29-70576
   Email: fessi@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/


   Georg Carle
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Sand 13
   Tuebingen  72072
   Germany

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


   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/


   Juergen Quittek
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511-15
   Email: quittek@netlab.nec.de
   URI:   http://www.netlab.nec.de/




Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 39]


Internet-Draft                Metering NSLP                   March 2007


   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13627
   Germany

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


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

   Email: Hannes.Tschofenig@siemens.com


































Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 40]


Internet-Draft                Metering NSLP                   March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Fessi, et al.   draft-dressler-nsis-metering-nslp-05.txt       [Page 41]


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