[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: April 27, 2006                          University of Tuebingen
                                                             F. Dressler
                                                  University of Erlangen
                                                              J. Quittek
                                                                     NEC
                                                              C. Kappler
                                                           H. Tschofenig
                                                              Siemens AG
                                                        October 24, 2005


               NSLP for Metering Configuration Signaling
               <draft-dressler-nsis-metering-nslp-03.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 April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Monitoring, metering and accounting of packets are increasingly



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


Internet-Draft                Metering NSLP                 October 2005


   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, which allows the dynamic
   configuration of Metering Entities on the data path.  An accompanying
   document [I-D.fessi-nsis-m-nslp-framework] makes a problem statement,
   describes scenarios where such a path-coupled configuration of
   Metering Entities would be useful, elaborates requirements for a
   path-coupled configuration protocol for Metetering Entities and
   discusses the applicability of NSIS for this purpose.  This document
   defines a Metering NSLP protocol design and messages, outlines
   protocol operation.


Table of Contents

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

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

   3.  Basic Protocol Design  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Model of operation . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Protocol overview  . . . . . . . . . . . . . . . . . . . .  8
       3.2.1.  Metering NSLP Message types  . . . . . . . . . . . . .  8
     3.3.  Design Decisions . . . . . . . . . . . . . . . . . . . . . 10
       3.3.1.  Soft State . . . . . . . . . . . . . . . . . . . . . . 10
       3.3.2.  Message Sequencing . . . . . . . . . . . . . . . . . . 10
       3.3.3.  Message Scoping  . . . . . . . . . . . . . . . . . . . 10
       3.3.4.  Rerouting  . . . . . . . . . . . . . . . . . . . . . . 10
       3.3.5.  Selection of MNEs  . . . . . . . . . . . . . . . . . . 11
       3.3.6.  Refreshing Sessions  . . . . . . . . . . . . . . . . . 11
       3.3.7.  Aggregation  . . . . . . . . . . . . . . . . . . . . . 12

   4.  Metering NSLP Functional Specification . . . . . . . . . . . . 12
     4.1.  Metering NSLP Message Structure  . . . . . . . . . . . . . 12
       4.1.1.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.2.  REFRESH  . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.3.  RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.4.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  Metering NSLP Objects  . . . . . . . . . . . . . . . . . . 13
       4.2.1.  Message Sequence Number (MSN)  . . . . . . . . . . . . 13
       4.2.2.  Selection_of_MNEs Object . . . . . . . . . . . . . . . 13
       4.2.3.  MNE_Counter Object . . . . . . . . . . . . . . . . . . 14
       4.2.4.  StatusList Object  . . . . . . . . . . . . . . . . . . 14
       4.2.5.  Session Lifetime Object  . . . . . . . . . . . . . . . 14
       4.2.6.  MSPEC Objects  . . . . . . . . . . . . . . . . . . . . 15
     4.3.  MSPEC Objects  . . . . . . . . . . . . . . . . . . . . . . 15
       4.3.1.  The <FlowSpecification> Object . . . . . . . . . . . . 15
       4.3.2.  The <MeteredProperties> Object . . . . . . . . . . . . 17



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


Internet-Draft                Metering NSLP                 October 2005


       4.3.3.  The <MeteringConfigurationParameters> Object . . . . . 17

   5.  General Processing Rules . . . . . . . . . . . . . . . . . . . 19
     5.1.  State Manipulation . . . . . . . . . . . . . . . . . . . . 19
     5.2.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 19
     5.3.  Standard Message Processing Rules  . . . . . . . . . . . . 20
     5.4.  Message Processing Rules . . . . . . . . . . . . . . . . . 20
       5.4.1.  The CONFIGURE Message  . . . . . . . . . . . . . . . . 20
       5.4.2.  The REFRESH Message  . . . . . . . . . . . . . . . . . 22
       5.4.3.  The RESPONSE Message . . . . . . . . . . . . . . . . . 22
       5.4.4.  The NOTIFY Message . . . . . . . . . . . . . . . . . . 22
     5.5.  Session State Machine  . . . . . . . . . . . . . . . . . . 22

   6.  Examples of Operation  . . . . . . . . . . . . . . . . . . . . 24

   7.  Mapping onto M-NSLP Requirements . . . . . . . . . . . . . . . 25

   8.  Security considerations  . . . . . . . . . . . . . . . . . . . 27

   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 27

   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     11.2. Informative References . . . . . . . . . . . . . . . . . . 28

   Appendix A.  An Example for the Configuration of IPFIX Devices
                using the Metering NSLP . . . . . . . . . . . . . . . 30

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33



















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


Internet-Draft                Metering NSLP                 October 2005


1.  Introduction

   Monitoring, metering and accounting of packets is an important
   functionality in many networks today.  Several working groups have
   described mechanisms to collect and report usage data for resource
   consumption in a network by a particular entity.  For example, the
   IPFIX WG defines a protocol to collect such data.  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 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, this document uses the following terms:

   Metering Record

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






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


Internet-Draft                Metering NSLP                 October 2005


   Monitoring Probe

      A Monitoring Probe is an entity that examines the data flow in
      order to gather Metering Records.  These Metering Records are
      exported to a Collector.

   Metering Entity

      A Metering Entity is a node that is equipped with one or more
      Monitoring Probes.  A Metering Entity MAY host other functions as
      in Figure 1 below, such as Metering Manager, M-NSLP Processing,
      etc.  Note however, that the Collector is typically not co-located
      with the Metering Entity and an other protocol (e.g.  IPFIX) is
      needed to report the Metering Records to the Collector.

   Collector

      A Collector receives Metering Records from one or multiple
      Metering Entities.  These Metering Records can be aggregated
      and/or correlated by the Collector.

   Metering Configuration State

      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.

   MNE

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

   MNI

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

   MNR

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






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


Internet-Draft                Metering NSLP                 October 2005


   MNF

      A MNE that is neither MNI nor MNR.



3.  Basic Protocol Design

   The design for the Metering NSLP and the processing of M-NSLP
   messages is similar to QoS NSLP.  The main difference compared to the
   QoS NSLP is that only a subset (in some cases even only one) of the
   Metering Entities in the signaling path will take part of 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 Metering
   NSLP and the associated metering mechanism in a MNE.
































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


Internet-Draft                Metering NSLP                 October 2005


                                                            to the Collector
                                                                     ^
                                     +---------------+               *
                                     |     Local     |               *
                                     | Management    |               *
                                     +---------------+               *
                                             ^                       *
                                             V                       *
                  +----------+         +----------+    +---------+   *
                  |  M-NSLP  |         | Metering |    | Policy  |   *
                  |Processing|<<<<>>>>>|Management|<<>>| Control |   *
                  +----------+         +----------+    +---------+   *
                    .  ^   |                 V                       *
                    |  ^   .                 V                       *
                    |  V   .                 V                       *
                    |  V   .                 V                       *
                  +----------+               V      Metering Records *
                  |   GIST   |               V      *****************
                  |Processing|               V     *
                  +----------+               V     *
                    |      |              +-------------------+
                    .      .              |                   |
          +----------+    +-----------+   |   Monitoring      |
      <-.-|  Input   |    | Outgoing  |-.-|     Probe         |-.-.-.->
          |  Packet  |    | Interface |   |                   |
      ===>|Processing|====|           |===|                   |=======>
          +----------+    +-----------+   +-------------------+

              <.-.-> = signaling flow
              =====> = data flow (sender --> receiver)
              <<<>>> = control and configuration operations
              *****> = Measurement resp. Metering Records

   Figure 1: Metering-NSLP in Metering Entity

   The Monitoring Probe collects measurement data and processes them
   into Metering Records.  These Metering Records 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:
   a.  appropriate information to determine which MNEs on the path need
       to take part of the metering
   b.  metering configuration information
   c.  policy information to authenticate and authorize the
       configuration request

   The M-NSLP processing decides if the current MNE is addressed by this



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


Internet-Draft                Metering NSLP                 October 2005


   configuring message.  If yes, the metering configuration information
   is extracted from the M-NSLP message 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 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. a
   video being requested from a video server, or by a physically
   separate knowledgeable network node.

3.2.  Protocol overview

3.2.1.  Metering NSLP Message types

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

3.2.1.1.  Request Messages

   CONFIGURE

      CONFIGURE is a request message.  It is used to create Metering
      Configuration State in a Metering Entity.  The CONFIGURE message
      is idempotent; the resultant effect on the Metering Configuration
      State and on the M-NSLP state is the same whether a message is
      received once or many times.

   REFRESH

      The REFRESH message is a request message that is used for 2
      reasons:
      *  First, to extend the lifetime of an existing M-NSLP session if
         required.
      *  Second, REFRESH messages are used to inspect if the MNEs that
         are involved in the metering process are still taking part of
         it.  This might not be the case, for example, if a re-routing
         event has happened and one of the involved MNEs in not on the
         path anymore.





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


Internet-Draft                Metering NSLP                 October 2005


      *  Third, for terminating a session.

3.2.1.2.  Response Messages

   RESPONSE

      The RESPONSE message is used to provide information about the
      result of a previous M-NSLP message.  This includes explicit
      confirmation of the state manipulation signaled in the CONFIGURE
      message, the response to a REFRESH 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 idempotent; the resultant effect on the
      Metering Configuration State and on the M-NSLP state is the same
      whether a message is received once or many times.


3.2.1.3.  Asynchronous Notifications

   NOTIFY

      The NOTIFY message is 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
      notification to an upstream peer about state being torn down.


   Each Metering NSLP message has a common header which indicates the
   message type and contains flags.  The parameters carried in each of
   the Metering NSLP messages are defined in Section 4.1.  Message
   Processing Rules are defined in Section 5.4.

   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 and whether the MNE
      should actually take part of the Metering.

   Metering specification (MSPEC)

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




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


Internet-Draft                Metering NSLP                 October 2005


   Policy objects

      Policy objects contain data used to authenticate M-NSLP messages
      and authorize the configuration of the MNEs.  They are interpreted
      by Policy Control.


   Detailed information about the Metering NSLP objects can be found in
   Section 4.2.

3.3.  Design Decisions

3.3.1.  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.  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 very similar to to the calculation of
   Session Lifetime in NATFW-NSLP [I-D.ietf-nsis-nslp-natfw].

3.3.2.  Message Sequencing

   The order in which CONFIGURE messages arrive influences the eventual
   configuration state that will be stored at a MNE.  Therefore M-NSLP
   supports the detection of CONFIGURE message duplication and re-
   ordering using a Message Sequence Number (MSN).

3.3.3.  Message Scoping

   Metering Entities at the edge of a signaling scope (for example, at
   the edge of the adminstrative 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 M-NSLP processing recognizes that the Metering Entity is of
   the type specified, it terminates the signaling.  The MNE acts as a
   Signaling Responder.

3.3.4.  Rerouting

   M-NSLP automatically adapts to rerouting events because state along
   the old path times out, and a new CONFIGURE message with the same
   SESSION_ID will install state along the new path.

   For M-NSLP it is generally not important to quickly tear down



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


Internet-Draft                Metering NSLP                 October 2005


   configuration state along the old path, however for some
   applications, e.g. accounting, it is vital to quickly configure MNEs
   on the new path.

3.3.5.  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, number or position on the path.
   This feature is the most striking difference to the 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.  For this reason, we need the object
   Selection_of_MNEs in the CONFIGURE message.

   When the MNE finds out it is not involved in the metering, it does
   not need to install, neither Metering Configuration State, nor M-NSLP
   state.  (For clarification, see here Section 5.1 where the different
   state information that an MNE needs to store is illustrated).

3.3.6.  Refreshing Sessions

   Refreshing M-NSLP sessions is required for several reasons.
   o  First, to extend the lifetime of an existing M-NSLP session if
      required.
   o  Second, by refreshing M-NSLP sessions, it can be inspected if the
      MNEs that are involved in the metering process are still metering.
      This might not be the case, for example, if a re-routing event has
      happened and one of the involved MNEs in not on the path anymore.

   To realize the latter requirement, we introduce the Metering NSLP
   message REFRESH, which differs from the CONFIGURE message.

   After a REFRESH message travels all the way from the MNI to the MNR,
   the MNR responds with a RESPONSE message where MNEs can write their
   current status.  Each MNE that is involved in the metering process
   marks an appropriate field reserved for it in the RESPONSE message to
   say "METERING".  For this reason we use the StatusList object in the
   Metering NSLP that is used by the RESPONSE message.

   MNEs that are not taking part of the metering process have not
   installed any M-NSLP state for this session and are agnostic about
   it.  These MNEs will just forward the REFRESH/RESPONSE message
   towards the MNR/MNI.




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


Internet-Draft                Metering NSLP                 October 2005


   When the RESPONSE message arrives at the MNI, the MNI verifies if the
   previously selected MNEs are still involved.  If not, the MNI can re-
   initiates the signaling with a CONFIGURE message with the same
   SESSION_ID and the same Correlation-ID (if there is one
   Correlation-ID in the MSPEC objects).

3.3.7.  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.  Metering NSLP Functional Specification

4.1.  Metering NSLP Message Structure

   As in other NSLPs, Metering NSLP messages consists of a common
   header, followed by a body consisting of a variable number of
   variable-length, typed "objects".  The common header and other
   objects are encapsulated together in a GIST NSLP-Data object.

   The following subsections define the objects carried in each of the
   Metering NSLP messages.

4.1.1.  CONFIGURE

   The CONFIGURE message carries the following objects:
   o  SESSION_ID: A large identifier provided by GIST or set locally.
   o  Message Sequence Number (MSN)
   o  Selection_of_MNEs: this object is required to determine which MNEs
      will actually take part of the metering.
   o  MNE_Counter: this parameter is used to count how many MNEs on the
      path are participating in the metering process.  Each MNE that is
      participating in the metering process increments this parameter by
      one.
   o  MSPEC: the MSPEC objects determine the actual configuration.  The
      MSPEC SHOULD be opaque to the Metering NSLP.
   o  Session Lifetime: this object gives the requested lifetime for a
      M-NSLP session.





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


Internet-Draft                Metering NSLP                 October 2005


4.1.2.  REFRESH

   The REFRESH message carries the following objects:
   o  SESSION_ID: this parameter refers to the same SESSION_ID given in
      the initial CONFIGURE message in the Metering NSLP session.
   o  Message Sequence Number (MSN)
   o  MNE_Counter: this parameter is used to count how many MNEs on the
      path are participating in the metering process.  Each MNE that is
      participating in the metering process increments this parameter by
      one.
   o  Session Lifetime: this object gives the requested lifetime to
      extend the M-NSLP session.

4.1.3.  RESPONSE

   The RESPONSE message carries the following objects:
   o  Message Sequence Number (MSN): the MNR MUST send the same MSN as
      in the corresponding M-NSLP request message in order to match a
      RESPONSE to the appropriate request message.
   o  Selection_of_MNEs: in some scenarios the actual MNEs that will
      take part of the metering are not determined until the RESPONSE
      message arrives.  For this reason, the parameter Selection_of_MNEs
      might be required.
   o  StatusList: This object contains one field of the size of one byte
      for each MNE participating in the metering process.  Each
      participating MNE can store its status in the appropriate field
      reserved for it.  The size of StatusList can be interpreted from
      the value of MNE_Counter.  The status can be, for example,
      "METERING", "NO DATA" or "OVERLOADED".
   o  ERROR_CODE: this object is required if the configuration can not
      be achieved successfully.

4.1.4.  NOTIFY

   A NOTIFY message MUST contain an ERROR_SPEC object indicating the
   reason for the notification.

4.2.  Metering NSLP Objects

4.2.1.  Message Sequence Number (MSN)

   As mentioned above, the Message Sequence Number is used to detect
   duplicate Metering NSLP messages.

4.2.2.  Selection_of_MNEs Object

   As mentioned above, this parameter is required to determine which
   MNEs will actually take part of the metering.  The value of the



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


Internet-Draft                Metering NSLP                 October 2005


   Selection_of_MNEs parameter can be one of the following:

   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 of the
      signaling.

   o  ANY: one MNE should be arbitrarily chosen to 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". here

   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_MNEs needs to
      be combined with an enterprise-specific identifier.  (See also
      http://www.iana.org/assignments/enterprise-numbers)

4.2.3.  MNE_Counter Object

   This parameter is used to count how many MNEs on the path are
   participating in the metering process.  Each MNE that is
   participating in the metering process increments this parameter by
   one.  When a request message (CONFIGURE or REFRESH) arrives at the
   MNR, the object MNE_Counter will contain the number of the MNEs
   participating in the metering process along the signaling path.

4.2.4.  StatusList Object

   This object is used for the RESPONSE message where each of the
   involved MNEs in the metering process has one field where it can
   store its current status.  The StatusList consists of one field of
   the size of one byte for each MNE participating in the metering
   process.  The status can be, for example, "METERING", "NO DATA" or
   "OVERLOADED".

   The size of the StatusList object is determined by the MNR based on
   the object MNE_Counter.

4.2.5.  Session Lifetime Object

   This object gives the requested lifetime for a M-NSLP session in
   seconds.  When a M-NSLP session expires, the Metering Manager MUST
   configure the Monitoring Probe to stop the Metering.  The
   corresponding Metering Configuration State is delete.



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


Internet-Draft                Metering NSLP                 October 2005


   A value of zero for this object leads to immediate termination of the
   corresponding session.

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

4.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.  The MSPEC objects
   MUST be extensible.  The order of objects is not defined, meaning
   that objects may occur in any sequence.

   The MSPEC consists of up to 3 objects.  No object can have more than
   one instances within a MSPEC.
   1.  <Flow Specification>: This section specifies the flow to be
       measured.  This object is optional within an MSPEC.  If it is not
       present, then the flow to be measured is specified by the Message
       Routing Information (MRI) that is provided by the NTLP for the
       NSIS session.
   2.  <Measured Properties>: This object specifies the set of packet
       properties or flow properties to be reported.  Examples of flow
       properties are the source IP address, the time stamp of the last
       packet observed, and the number of packets observed.
   3.  <Measurement Configuration Parameters>: This object includes a
       set of configuration parameters for the metering process and the
       reporting process.  Examples for these parameters are the
       reporting protocol, the reporting interval, and the flow idle
       expiration time.  This object can further configure how the flow
       specified by MRI and the <Flow Specification> object is split
       into sub-flows.  An example is an MRI that includes all TCP
       packets between NI and NR.  In such a case, the <Measurement
       Configuration Parameters> object can specify that for each
       combination of source and destination port numbers a different
       sub-flow is reported.

4.3.1.  The <FlowSpecification> Object

   The <FlowSpecification> object restricts the set of considered flows
   to be metered.  This object is not mandatory in the MSPEC.  If it is
   not present, then the M-NSLP uses the Message Routing Information
   (MRI) provided in GIST and considers it as the data flow to be
   metered.



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


Internet-Draft                Metering NSLP                 October 2005


   If this object is present, then two alternatives are possible.  The
   first alternative further restricts the flow specification given by
   the MRI.  The other one completely replaces the MRI with an arbitrary
   new flow specification.  While the first alternative is fully in line
   with the NSIS architecture and framework, the applicability of NSIS
   to the second alternative needs to be investigated.

   In both cases, the <FlowSpecification> is given as a set of flow
   properties with value limitations.  Each element of this set
   identifies a flow property according to the IPFIX information model
   [I-D.ietf-ipfix-info].  A flow property is identified by the IPFIX
   Information Element identifier.  Currently, these Information
   Elements are defined in [I-D.ietf-ipfix-info] and [I-D.ietf-psamp-
   info].  In the future, the list of IPFIX Information Elements will be
   maintained by IANA.

   EDITORIAL NOTE: the previous sentence needs to be updated after IANA
   created a registry for IPFIX Information Elements

   The value limitation can be
      a single value,
      a combination of a start value and an end value of a range,
      a combination of a single value and a binary mask, or
      a set of values.

   A packet is only measured if for all flow properties the that are
   contained in the <FlowSpecification> object, the corresponding values
   comply with the specified limitations.  This way of filtering packets
   before they are measured is consistent with the filter specification
   of the PSAMP MIB module as defined in Section 5.2.8 of [I-D.ietf-
   psamp-mib].

   Besides the set of flow properties with value limitations a
   <FlowSpecification> object must further contain an indicator, whether
   or not all packets that are measured must also match the MRI.

   The table below gives an example of a set of flow properties with
   value limitations within a <FlowSpecification> object.













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


Internet-Draft                Metering NSLP                 October 2005


     +-----------------------+-----------------------------------------+
     |destinationIPv6Address | 2F00:00B4:0000:0000:0000:0221:44DD:0000 |
     |-----------------------+-----------------------------------------|
     | protocolIdentifier    | 6 (TCP)                                 |
     |-----------------------+-----------------------------------------|
     | tcpDestinationPort    | [4030,4034]                             |
     |-----------------------+-----------------------------------------|
     | tcpFlagAck            | 1                                       |
     |-----------------------+-----------------------------------------|
     | tcpFlagSyn            | 1                                       |
     +-----------------------+-----------------------------------------+

   Figure 2: An example of a flow specification in the MSPEC

   In the example above, the MSPEC instructs that TCP packets with
   destination IPv6 address 2F00:00B4:0000:0000:0000:0221:44DD:0000,
   destination port number between 4030 and 4034 where both the SYN and
   ACK flags are set, are to be metered.

4.3.2.  The <MeteredProperties> Object

   The <MeteredProperties> object specifies the list of packet
   properties or flow properties that need to be measured by the NME for
   each reported packet or flow. <MeteredProperties> is a list of IPFIX
   Inforamtion Element identifiers.  Currently, these Information
   Elements are defined in [I-D.ietf-ipfix-info] and [I-D.ietf-psamp-
   info].  In the future, the list of IPFIX Information Elements will be
   maintained by IANA.

   EDITORIAL NOTE: the previous sentence needs to be updated after IANA
   created a registry for IPFIX Information Elements.

   The current list of defined IPFIX Information Elements is not
   sufficient for some of the scenarios outlined in [I-D.fessi-nsis-m-
   nslp-framework].  However, the IPFIX information model is extensible
   and the missing Information Elements can be added by the procedure
   described in Section 6 (Extending the Information Model) of
   [I-D.ietf-ipfix-info].

4.3.3.  The <MeteringConfigurationParameters> Object

   The configuration parameters for the requested measurement are given
   as a list of Attribute-Value-Pairs (AVPs).  The list of configuration
   parameters includes:







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


Internet-Draft                Metering NSLP                 October 2005


     +-----------------------+-----------------------------------------+
     |       Attribute       |               Remarks                   |
     |-----------------------+-----------------------------------------|
     | Export protocol       | The value will be IPFIX, Netflow9,      |
     |                       | Netflow 5, etc                          |
     |-----------------------+-----------------------------------------|
     | Reporting interval    | This parameter corresponds to           |
     |                       | flowActiveTimeOut in the IPFIX          |
     |                       | Information Model                       |
     |-----------------------+-----------------------------------------|
     | Flow expiration time  | This parameter corresponds to           |
     |                       | flowInactiveTimeOut in the IPFIX        |
     |                       | Information Model                       |
     |-----------------------+-----------------------------------------|
     | Collector ID          | Type: IP4 or IP6 address or an other    |
     |                       | type of address, for example, a name    |
     |                       | than can be resolved by DNS.            |
     +-----------------------+-----------------------------------------+
     | encryptionRequired    | This parameters instructs if the        |
     |                       | Metering Records need to be encrypted   |
     |                       | when they are sent to the Collector.    |
     |                       | EDITORIAL NOTE: Eventually, more        |
     |                       | parameters need to be provided here     |
     |                       | to fulfill the security requirements.   |
     |                       | For example, a certificate of the       |
     |                       | Collector can be provided to assure that|
     |                       | Metering Records are not delivered to a |
     |                       | bogus Collector.                        |
     +-----------------------+-----------------------------------------+
     | Packet Sampling alg.  | see [I-D.ietf-psamp-info]               |
     +-----------------------+-----------------------------------------+
     | Packet Sampling params| see [I-D.ietf-psamp-info]               |
     +-----------------------+-----------------------------------------+
     | AggregationRules      |                                         |
     +-----------------------+-----------------------------------------+

   Figure 3: MeteringConfigurationParameters in the MSPEC

   Some of the attributes in the list of
   <MeteringConfigurationParameters> above have an identifier specified
   in the IPFIX Information Model [I-D.ietf-ipfix-info], for example,
   flowActiveTimeOut and flowInactiveTimeOut.

   [I-D.ietf-psamp-info] provides an extension of the IPFIX Information
   Model, with a list of identifiers for packet sampling algorithms and
   a list of identifiers for parameters for packet sampling algorithms.

   Other attributes in the AVL list <MeteringConfigurationParameters>



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


Internet-Draft                Metering NSLP                 October 2005


   need to be identified using identifiers that are consistent with the
   IPFIX Information Model, i.e. identifiers that are used for other
   objects in the IPFIX Information Model MUST not be used here.

   The attribute AggregationRules will be elaborated in future versions
   of this document based on [I-D.dressler-ipfix-aggregation]


5.  General Processing Rules

5.1.  State Manipulation

   The state that needs to be stored at a MNE for a M-NSLP session can
   be of different types:

   o  NTLP state

   o  M-NSLP state

   o  Metering Configuration State


   As mentioned in Section 2, Metering Configuration State is the state
   used/kept by the Metering Manager to configure the Monitoring Probe.
   This consists of the parameters specified in the MSPEC section
   (Section 4.3).

   One of the attractive properties of the Metering NSLP is that MNEs
   that are not taking part of the metering do not need to install any
   M-NSLP state.  Nor do they need to install Metering Configuration
   State.  However, MNEs that are not taking part of the metering
   process still need to store NTLP state in order to avoid GIST re-
   discovering them each time when it refreshes its routing state.  For
   more details on how GIST refreshes its routing state, please see
   [I-D.ietf-nsis-ntlp].

5.2.  Message Forwarding

   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) using GIST.

   When a MNE receives a request message, the message is forwarded
   downstream to the next MNE, except in 2 cases:
   o  the CONFIGURE message has reached the MNR.
   o  the involved MNEs in the configuration have been reached.

   The latter case can be for example:



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


Internet-Draft                Metering NSLP                 October 2005


   o  if the SCOPING flag is set and the CONFIGURE message has reached
      the end of the scope of the signaling.
   o  if Selection_of_MNEs is 'ANY' and an appropriate MNE has been
      already found.
   o  if Selection_of_MNEs is FIRST. (in this case, only the MNI is
      involved in the signaling)

   In these cases, there is no need to forward the M-NSLP message
   further.

   M-NSLP response messages are forwarded upstream along the data path
   towards the MNI.

   M-NSLP asynchronous notifications can be sent upstream or downstream
   depending on the reason for the notification.

5.3.  Standard Message Processing Rules

   If a mandatory object is missing from a message then the receiving
   MNE MUST NOT propagate the message any further.  It MUST construct an
   RESPONSE message indicating the error condition and send it back to
   towards the MNI.

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

5.4.  Message Processing Rules

5.4.1.  The CONFIGURE Message

   When a MNE receives a CONFIGURE message, it performs the following
   steps:
   o  The MNE checks the message format.  In case of malformed messages,
      the MNE sends a RESPONSE message with the appropriate ERROR_SPEC.
   o  Before performing any state changing actions, the MNE MUST
      determine whether the sender of the request is authorized to
      perform this configuration action.
   o  After the CONFIGURE message is authorized, the MNE needs to figure
      out if it will take part of the metering or not based on the
      Selection_of_MNEs object:
      *  If (Selection_of_MNEs = FIRST) or (Selection_of_MNEs = LAST) or
         (Selection_of_MNEs = 'FIRST and LAST'), the MNE figures out if
         one these contraints equates to true.  If yes, the MSPEC is
         extracted from the CONFIGURE message and passed to the Metering
         Manager as shown in Figure 1.
      *  If (Selection_of_MNEs = ALL) the MSPEC is extracted from the
         CONFIGURE message and passed to the Metering Manager.




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


Internet-Draft                Metering NSLP                 October 2005


      *  If Selection_of_MNEs = 'ANY', the MNE verifies first if
         MNE_Counter is equal to one.  This means, it verifies, if there
         has been already one MNE on the path that is willing to take
         this task.  If MNE_Counter is zero, the MNE verifies based on
         its current status (number of existing measurements, current
         load, etc) if it is able to perform the metering request.  If
         yes, the MSPEC is extracted from the CONFIGURE message and
         passed to the Metering Manager.
   o  If the evaluation of Selection_of_MNEs results in to not taking
      part of the metering, then the MNE does not store any Metering
      Configuration State.  Now, the MNE decides whether to forward the
      CONFIGURE message.  This decision is taken based on Section 5.2
   o  If the evaluation of Selection_of_MNEs results in to taking part
      of the metering and the MSPEC is passed to the Metering Manager,
      the Metering Manager verifies if the Monitoring Probe is able to
      perform the metering based on the information in the MSPEC
      parameters, for example, if the requested export protocol is
      supported, and if the sampling algorithm is supported, etc.
   o  If the Metering Manager categorizes the metering request as
      feasible, it stores the Metering Configuration State and informs
      the M-NSLP processing.  Note however that the configuration is not
      activated, i.e. the Monitoring does not start the metering, until
      the MNE receives the matching RESPONSE.  Now, the MNE increments
      the parameter MNE_Counter by one to signal that it is taking part
      of the metering.  Afterwards, the MNE needs to decide whether to
      forward the CONFIGURE message or not.  Again here, this decision
      can be taken based on Section 5.2.
   o  If the evaluation of Selection_of_MNEs results in to taking part
      of the metering, but the Metering Manager categorizes the metering
      request as NOT feasible, then:
      *  If (Selection_of_MNEs = FIRST) or (Selection_of_MNEs = LAST) or
         (Selection_of_MNEs = 'FIRST and LAST') and the MNE is indeed
         the first or the last MNE on the signaling path, then the MNE
         constructs a RESPONSE message with the appropriate ERROR_SPEC
         and sends it back towards the MNI.  Otherwise, the MNE forwards
         the message to the next MNE.
      *  If (Selection_of_MNEs = ANY) and the message has reached the
         MNR, i.e. no appropriate MNE has been found on the path, then
         the MNE (which is in this case the MNR) constructs a RESPONSE
         message with the appropriate ERROR_SPEC and sends it back
         towards the MNI.  Otherwise, the MNE forwards the message to
         the next MNE.
      *  If (Selection_of_MNEs = ALL), since "ALL" must be understood
         here as "as many as possible", the MNE does not need to
         generate a RESPONSE message with an ERROR_SPEC.  It just needs
         to forward the message to the next MNE.





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


Internet-Draft                Metering NSLP                 October 2005


5.4.2.  The REFRESH Message

   Processing REFRESH messages is simple:
   o  If the SESSION_ID is known, the MNE verifies based on its local
      policies if the requested lifetime is allowed.  If not, the MNE
      adapts the time interval to its local policies.  Now, the MNE
      increments the parameter MNE_Counter by one to signal that it is
      still taking part of the metering.  Afterwards, the MNE decides
      whether to forward the REFRESH message to the next MNE on the
      path.  This decision can be taken based on Section 5.2.  Note
      here, that the lifetime of the M-NSLP session is not extended
      until the corresponding RESPONSE message arrives.  Also note that
      a lifetime of zero lead to immediate termination of the session
      when the corresponding RESPONSE message arrives.
   o  If the SESSION_ID is unknown, i.e. the MNE has not stored any
      M-NSLP state for this session, the message is just forwarded to
      the next MNE on the path.

5.4.3.  The RESPONSE Message

   If a RESPONSE message is a negative response with an ERRPR_SPEC
   object, the MNE just forwards the message towards the MNI.  When the
   MNI receives this message it has to take the appropriate action based
   on the content of the ERROR_SPEC object.

   If the RESPONSE message is a positive RESONSE, the processing of the
   message depends on the type of the corresponding M-NSLP request
   message (CONFIGURE or REFRESH).  However, in both cases, the RESPONSE
   message contains the object StatusList where the MNEs that are
   involved in the metering process can report their status.  This
   status can be, for example, "METERING", "NO DATA" or "OVERLOADED".

   Processing RESPONSE messages is described in several parts of this
   documents.  However, it still needs to be described more clearly in
   this section in future versions.

5.4.4.  The NOTIFY Message

   tbd.

5.5.  Session State Machine

   The state machine of a M-NSLP session has three main states:








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


Internet-Draft                Metering NSLP                 October 2005


   'session closed':

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

   'pending':

      At this state a CONFIGURE message has been received, the MNE has
      been successfully configured (i.e. authentication and
      authorization succeeded, the evaluation of Selection_of_MNEs and
      the evaluation of the MSPEC objects by the Metering Manager were
      positive, etc.) however the configuration has not been activated
      yet, i.e. metering function has been started.

   'metering':

      At this state the MNE is metering according to a metering
      configuration received by a CONFIGURE message.


   All of these states have sub-states, but the basic M-NSLP operation
   per session is described on the level of these three states.

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

   CONF:

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

   REFR:

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

   RESP-M:

      This transition is triggered by a RESPONSE message that is sent by
      the MNE in order to indicate that a metering configuration sent by
      a CONFIGURE message of the same session has become active at the
      MNE.  This transaction always leads to state 'metering'.

   RESP-N:

      This transition is triggered by a RESPONSE message that is sent by
      the MNE in order to indicate that a metering configuration sent by
      a CONFIGURE message of the same session has not become active at



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


Internet-Draft                Metering NSLP                 October 2005


      the MNE.  This transaction always leads to state 'session closed'.

   T-OUT:

      This transition is triggered by a time out of a session in state
      'pending' or 'metering'.  This transaction always leads to state
      'session closed'.


             REFR +----+
                  |    v
               +----------+
               | session  |
               | closed   |<-------------+
               +----------+              |
                  |    ^                 |
             CONF |    | RESP-N          | RESP-N
                  v    | T-OUT           | T-OUT
               +----------+         +----------+
               | pending  | RESP-M  | metering |
               |          |-------->|          |
               +----------+         +----------+
             CONF |    ^          CONF |    ^
             REFR |    |          REFR |    |
                  +----+        RESP-M +----+


6.  Examples of Operation

   The basic signaling sequences are similar to QoS NSLP: To start a
   configuration, the MNI constructs a CONFIGURE message with the
   required MSPEC objects, and sends it to the MNR.  The message is
   interpreted by MNEs on the data path.  The MNR replies with a
   RESPONSE message.


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

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







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


Internet-Draft                Metering NSLP                 October 2005


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

   More detailed examples of operation will be depicted in future
   versions of this document.


7.  Mapping onto M-NSLP Requirements

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







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


Internet-Draft                Metering NSLP                 October 2005


   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 3.3.5, a MNE should be able to decide to
      pull out of the metering process.  This is realized by the
      Selection_of_MNEs 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 3.3.4.

   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-03.txt       [Page 26]


Internet-Draft                Metering NSLP                 October 2005


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.

   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.


9.  Open Issues
   o  The objects in the MSPEC presented above are currently a work-in-
      progress and will be elaborated and detailed further in future
      versions of this document.  One of the open issues with the MSPEC
      is, for example, whether the <FlowSpecification> should be
      restricted to the MRI from the NTLP, or extend it, or can be even
      unrelated to it.
   o  The protocol in its current design allows to select, except the
      case "FIRST and LAST", either only one MNE or all the MNEs on the
      path for the metering process.  Based on the current scenarios
      elaborated in [I-D.fessi-nsis-m-nslp-framework], this is
      sufficient.  However, the option to have, for example, "ANY N",
      where N is greater than one, might be useful in future
      applications of the Metering NSLP.
   o  In some cases, the Collector needs to distinguish between the
      Metering Records received from the different MNEs in order to
      correlate them.  For example, if Selection_of_MNEs is "FIRST and
      LAST", the Collector needs to know, which data come from the first
      and resp. the last MNE on the signaling path.  Also, in the case
      where Selection_of_MNEs is "ALL", the Collector needs to know the
      position of the MNEs that are sending the Metering Records on the
      path in order to correlate them correctly, (for example to
      calculate the hop-by-hop delay).  This information needs to be
      transferred to the Collector in the Metering Records using an
      other protocol.  However, the M-NSLP might also need to provide
      mechanisms to coordinate this.  Each MNE need to know its position
      on the path, i.e. how many MNEs exists between it and the MNI.
      Moreover, if not all the IP hops on the path do support the
      Metering NSLP, it will be useful for the Collector to know how far
      each pair of adjacent MNEs are from each other.
   o  Based on the current analysis of the security issues of the
      Metering NSLP discussed in Section 8, an authentication and
      authorization scheme for the Metering NSLP needs to be elaborated.
      The policy objects carried in Metering NSLP messages need to be
      specified.



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


Internet-Draft                Metering NSLP                 October 2005


   Additional open issues appear in the main body of the text.


10.  Acknowledgements

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


11.  References

11.1.  Normative References

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signaling Transport", draft-ietf-nsis-ntlp-08 (work in
              progress), September 2005.

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

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

   [I-D.ietf-ipfix-protocol]
              Claise, B., "IPFIX Protocol Specification",
              draft-ietf-ipfix-protocol-19 (work in progress),
              September 2005.

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




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


Internet-Draft                Metering NSLP                 October 2005


   [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., "Definitions of Managed Objects for Packet
              Sampling", draft-ietf-psamp-mib-04 (work in progress),
              February 2005.

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

   [I-D.dressler-ipfix-aggregation]
              Dressler, F., "IPFIX Aggregation",
              draft-dressler-ipfix-aggregation-01 (work in progress),
              July 2005.

   [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]
              Bosch, S., "NSLP for Quality-of-Service signalling",
              draft-ietf-nsis-qos-nslp-08 (work in progress),
              October 2005.

   [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-07 (work in
              progress), July 2005.

   [I-D.ietf-nsis-qspec]
              Ash, J., "QoS-NSLP QSPEC Template",
              draft-ietf-nsis-qspec-06 (work in progress), October 2005.

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

   [I-D.ietf-aaa-diameter-cc]



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


Internet-Draft                Metering NSLP                 October 2005


              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.


Appendix A.  An Example for the Configuration of IPFIX Devices using the
             Metering NSLP

   When the IPFIX protocol is used to report the Metering Records to the
   Collector, the attributes in <FlowSpecification> and
   <MeteredProperties> concatenated together will constitute the IPFIX
   Template for exporting the Metering Records, since they carry all the
   information that is needed for the Template.

   Metering configuration parameters such as sampling algorithm and
   reporting interval can be reported to the Collector using an Option
   Template in order to avoid re-reporting them with each Metering
   Records.  In this case, the Option Template needs to refer to the
   original Template.

   Future versions of this document will include more detailed
   description of an example for the configuration of IPFIX Devices
   using the Metering NSLP with the corresponding templates.






















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


Internet-Draft                Metering NSLP                 October 2005


Authors' Addresses

   Ali Fessi
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Auf der Morgenstelle 10C
   Tuebingen  71076
   Germany

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


   Georg Carle
   University of Tuebingen
   Wilhelm-Schickard-Institute for Computer Science
   Auf der Morgenstelle 10C
   Tuebingen  71076
   Germany

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


   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-03.txt       [Page 31]


Internet-Draft                Metering NSLP                 October 2005


   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-03.txt       [Page 32]


Internet-Draft                Metering NSLP                 October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




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


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