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

Versions: 00 01 02 03 04

Network Working Group                                           A. Fessi
Internet-Draft                                   University of Tuebingen
Expires: April 27, 2006                                       C. Kappler
                                                                  C. Fan
                                                              Siemens AG
                                                             F. Dressler
                                                  University of Erlangen
                                                                A. Klenk
                                                 University of Tuebingen
                                                        October 24, 2005


                      Framework for Metering NSLP
               <draft-fessi-nsis-m-nslp-framework-02.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

   This document motivates and describes an architectural framework for
   a new NSLP, which allows the dynamic configuration of Metering



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 1]


Internet-Draft              M-NSLP Framework                October 2005


   Entities on the data path to record monitoring and measurement data
   and report it to a data collector.  Different scenarios are described
   where such a path-coupled configuration of the Metering Entities can
   be useful.  Currently, the focus is on three scenarios: accounting,
   QoS measurement and monitoring for network security.  Moreover, this
   document suggests the appropriate parameters to be configured for
   each scenario.  Furthermore, it gathers requirements for a path-
   coupled configuration protocol of Metering Entities.  Finally, the
   applicability of the NSIS architecture for this purpose is discussed.


Table of Contents

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

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

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4

   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Accounting . . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Scenario Description . . . . . . . . . . . . . . . . .  7
       4.1.2.  Required Parameters  . . . . . . . . . . . . . . . . .  8
     4.2.  QoS Monitoring . . . . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  Scenario Description . . . . . . . . . . . . . . . . . 11
       4.2.2.  Configuration Parameters . . . . . . . . . . . . . . . 13
     4.3.  Monitoring for Network Security  . . . . . . . . . . . . . 14
       4.3.1.  Scenario Description . . . . . . . . . . . . . . . . . 14
       4.3.2.  Required Parameters  . . . . . . . . . . . . . . . . . 16

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  General requirements . . . . . . . . . . . . . . . . . . . 18
       5.1.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . 18
       5.1.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . 18
       5.1.3.  Security . . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  Flexible metering model  . . . . . . . . . . . . . . . . . 18
     5.3.  Distinguishing flows . . . . . . . . . . . . . . . . . . . 19
     5.4.  Aggregation of Metering Records  . . . . . . . . . . . . . 19
     5.5.  Flexible data collection . . . . . . . . . . . . . . . . . 19
     5.6.  Location of Metering Entities  . . . . . . . . . . . . . . 19
     5.7.  Location of the Collectors . . . . . . . . . . . . . . . . 19
     5.8.  Configuration protocol . . . . . . . . . . . . . . . . . . 20
       5.8.1.  Configuration of Metering Entities . . . . . . . . . . 20
       5.8.2.  Selection of Metering Entities . . . . . . . . . . . . 20
       5.8.3.  Metering Configuration State installation and
               removal  . . . . . . . . . . . . . . . . . . . . . . . 20
       5.8.4.  Initiation and maintenance of metering tasks . . . . . 20
       5.8.5.  Reaction to Route Changes  . . . . . . . . . . . . . . 20



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 2]


Internet-Draft              M-NSLP Framework                October 2005


       5.8.6.  Collection of information on available Metering
               Entities . . . . . . . . . . . . . . . . . . . . . . . 20
       5.8.7.  Scoping of configuration . . . . . . . . . . . . . . . 20
     5.9.  Metering across domains  . . . . . . . . . . . . . . . . . 21

   6.  Applicability of the NSIS Architecture . . . . . . . . . . . . 21

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     7.1.  Authorization Model  . . . . . . . . . . . . . . . . . . . 22
     7.2.  Inter-working between different domains  . . . . . . . . . 22
     7.3.  End User Privacy . . . . . . . . . . . . . . . . . . . . . 22
     7.4.  ISP Privacy  . . . . . . . . . . . . . . . . . . . . . . . 23
     7.5.  Forged Collector . . . . . . . . . . . . . . . . . . . . . 23
     7.6.  Denial-of-Service Attacks on the Collector . . . . . . . . 23
     7.7.  Denial-of-Service Attacks on Metering Entities . . . . . . 23
     7.8.  Verification of the Flow Specification . . . . . . . . . . 24

   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 29


























Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 3]


Internet-Draft              M-NSLP Framework                October 2005


1.  Introduction

   Monitoring, metering and accounting of packets is an important
   functionality in many networks today.  Several working groups are
   working on mechanisms for collecting and reporting usage data, flow
   or packet information.  For example, the IPFIX (IP Flow Information
   Export) Working Group defines a protocol to collect and report flow
   information ([I-D.ietf-ipfix-protocol]).  The PSAMP (Packet SAMPling)
   Working Group focuses on reporting per packet information for further
   processing ([I-D.ietf-psamp-framework]).

   However, it is also necessary to configure and coordinate the
   entities doing the metering.  If we are interested in one or more
   Metering Entities to meter a specific flow, then all potential
   candidates for this task are on the path used by this particular
   flow.  They can easily be addressed by sending a configuration
   message along the path of the flow.  If more than one Metering Entity
   is required, all of them can potentially be configured and
   coordinated with a single message along the path.

   The Metering Entities can do either statistics on these flows, packet
   sampling or some other special treatment for the packets, for
   example, examining the packet payload, or just report that this
   packet has passed this point.  The Metering Entities can be
   configured and can be coordinated to achieve a certain goal together,
   which can be, for example, accounting, QoS monitoring or monitoring
   for network security.


2.  Terminology

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

   Furthermore, this document uses the terms "Metering Data", "Metering
   Record", "Monitoring Probe", "Metering Entity", "Collector", as
   defined in [I-D.dressler-nsis-metering-nslp].


3.  Problem Statement

   There is a need in industry and the Internet research community to
   collect and export information on data flows.  We call such
   information Metering Records.  Metering Records are useful in
   mediation systems, accounting systems, and network management systems
   to facilitate services such as Internet research, measurement,
   accounting, billing, QoS monitoring, intrusion detection, and traffic



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 4]


Internet-Draft              M-NSLP Framework                October 2005


   profiling/engineering.  In recognition of the need for such metering
   the IPFIX WG was founded.

   While the purpose for collecting Metering Records in each case is
   different, the basic architecture of such metering systems is usually
   identical, cf. Figure 1.  Measurement data is collected by a
   Monitoring Probe, and from there reported to a Metering Entity.  The
   Metering Entity produces Metering Data from the measurement data or
   additional data such as session information.  Monitoring Probe and
   Metering Entity are co-located.  One Metering Entity may control
   several Monitoring Probes; in any event the Monitoring Probe is
   controlled by a Metering Entity.  The Metering Entity transmits its
   Metering Data to the actual Collector.  The Collector correlates
   Metering Data relating to the same event from different Metering
   Entities and produces a Metering Record.  There might be more than
   one Collector depending on the actual tasks.





                       +-----------------+
                       |    Collector    |
                       | +-------------+ |
                       | | Met. Record | |
                       | +-------------+ |
                       +-----------------+
                           ^ ^ ^ ^ ^
                       ***     *    ***
                    ***        *       ***
                 ***           *          ***
              ***              *              ***
       +-------------+    +-----------+    +-------------+
       |   +-----+   |    |  +-----+  |    |   +-----+   |
       |   | ME  |   |    |  | ME  |  |    |   | ME  |   |
       |   +-----+   |    |  +-----+  |    |   +-----+   |
   ===>|    ^  ^     |===>|     ^     |===>|    ^  ^     |
       |   /    \    |    |     |     |    |   /    \    |
   --->|  /      \   |--->|     |     |--->|  /      \   |
       |+----+ +----+|    |   +----+  |    |+----+ +----+|
       || MP | | MP ||    |   | MP |  |    || MP | | MP ||
       |+----+ +----+|    |   +----+  |    |+----+ +----+|
       +-------------+    +-----------+    +-------------+
       +---+
       |ME |= Metering     === = Meter. Configuration   --- = Data Flow
       +---+  Entity             Signaling Messages

       +----+



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 5]


Internet-Draft              M-NSLP Framework                October 2005


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



   Figure 1: Schematic Metering Architecture

   In this context two problems need to be solved:
   o  Measurement data need to be reported from the Monitoring Probes to
      the Metering Entities and Metering Data need to be transported
      from the Metering Entities to the Collector.  IPFIX is, for
      example, a protocol suitable for this task.
   o  The Metering Entities need to be configured and coordinated.  This
      document suggests path-coupled signaling for this purpose.

   In a flexible environment, it must be possible to dynamically
   configure and coordinate Metering Entities rather than hardwiring
   them.  Configuration and coordination includes, for example, what
   entities do the metering for a particular flow or session, providing
   triggers to start or stop metering, distribution of identifiers for
   the Collector to correlate Metering Records, and so forth.  The IPFIX
   WG has identified the needs for such configurations but has defined
   the work currently as "out of the scope" [RFC3917].  The
   configuration can be performed, for example, using RADIUS ([RFC2138])
   or DIAMETER ([RFC3588]).  The PSAMP (Packet Sampling) WG is also
   currently developing a MIB module for configuring packet sampling
   ([I-D.ietf-psamp-mib]).  Nevertheless, all these alternatives allow
   only the configuration of single Metering Entities, and assume that
   the location of the Metering Entities to be configured is known
   before.  Dynamic discovery, configuration and coordination of
   distributed Metering Entities is not supported.

   Since the most appropriate Metering Entities for metering a specific
   flow are located along the same path as the flow itself, a path-
   coupled signaling protocol for distributing the configuration
   information seems useful.


4.  Scenarios

   This section describes three scenarios for the usage of path-coupled
   configuration of Metering Entities: accounting, QoS monitoring, and
   monitoring for network security.

4.1.  Accounting






Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 6]


Internet-Draft              M-NSLP Framework                October 2005


4.1.1.  Scenario Description

   Flexible usage-based charging is mainly a problem in 3G mobile
   telecommunication networks.  But with the advent of IP in these
   networks and with 3GPP's All-IP perspective, there is also an
   increasing need for IP technology to provide such functionality.

   When starting an application session, for example, a video streaming,
   usually there are several possible Metering Entities on the data
   path, for example, the application server, the WLAN access point, the
   ingress nodes of several transit networks or any router on the path
   with metering functionality.  These Metering Entities have different
   capabilities.  For example, routers along the path might be able to
   account packets and packets sizes while the WLAN access point is able
   to report the usage of wireless link and whether the end host is
   roaming.  If content-based accounting is also required, the most
   appropriate Metering Entity to perform this task will be the
   Application Server.

   An example of such a scenario is illustrated in Figure 2 where a data
   receiver expects data from a data sender via two routers Router 1 and
   Router 2.  The application server (i.e., data sender) may or may not
   (as in Figure 2) belong to the administrative domain.


                   +-------------------------+
   Data Receiver   | Router 1    Router 2    |       Data Sender
   +-----------+   |  +-----+     +-----+    |      +-----------+
   |           |<-----|     |<----|     |<----------|Application|
   |Application|   |  |+---+|     |+---+|    |      |   +---+   |
   |           |   |  ||ME ||<===>||ME ||<=========>|   |ME |   |
   +-----------+   |  |+---+|     |+---+|    |      |   +---+   |
                   |  +-----+     +-----+    |      +-----------+
                   |   Administrative Domain |
                   +-------------------------+
       +---+
       |ME | = Metering     === = Signaling    --- = Data Flow
       +---+   Entity             Messages

   Figure 2: Signaling to configure metering for accounting

   As a prerequisite to charging, one or more Metering Entities collect
   Metering Records independently for the same session.  Existing
   accounting concepts handle multiple Metering Entities by statically
   configuring them [3GPP.32.260].  Some of those Metering Entities
   always generate Metering Records, which will may be discarded later.
   For example, in the case of a pure content charging scheme, only the
   Metering Entity at the Data Sender (Application Server) needs to



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 7]


Internet-Draft              M-NSLP Framework                October 2005


   perform metering.  All other Metering Entities do not need to perform
   any metering since their Metering Data will be discarded anyway.
   Therefore, a flexible mechanism is required to distribute this
   information to the Metering Entities along the path and to find the
   appropriate Metering Entity on the path depending on the charging
   scheme.

   In the case where a mixed content and access charging should be
   applied, not only the content accessed but also the data volume is
   relevant for the metering process.  In this case, the Metering Entity
   at the Data Sender should be configured to account the content
   accessed, and one of the other Metering Entities along the path, for
   example, Router 1 or Router 2 must be configured to count bytes.

   Furthermore, Metering Records need to be correlated at the Collector
   in order to match them to the same session.  In current accounting
   concepts ([3GPP.32.260]), data correlation is performed by hardwiring
   one of Metering Entities to generate a correlation ID, and by
   manually configuring a chain of Metering Entities to which this
   correlation ID is distributed.  This is very inflexible and leads to
   unnecessary overhead.

   Using a path-coupled configuration protocol, this correlation ID can
   be distributed at the configuration.

   When a handover occurs other Metering Entities become involved, for
   example the new WLAN access point.  Metering Data collected by the
   different Metering Entities needs to be correlated and aggregated.

   Furthermore, Metering Entities need to know to which Collector they
   must send their Metering Data.  This information can be also be
   distributed dynamically during the signaling for configuration.

   Configuring Metering Entities dynamically along the path has
   potentially also an other advantage.  It allows to benefit from the
   capabilities of the Metering Entities along the path and not to
   restrict the metering tasks to few nodes that are statistically
   configured.  This will help to avoid scalability problems, where few
   Metering Entities might not able to handle the load caused by a large
   number of metering tasks.

4.1.2.  Required Parameters

   In a client/server environment the Application Server (for example, a
   video streaming server) acts as signaling initiator.  It sends a
   configuring request message towards the user terminal.  The Metering
   Entities along the path evaluates this message.




Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 8]


Internet-Draft              M-NSLP Framework                October 2005


   Given that the user terminal can not be seen as a trusted network
   function, the signaling will travel until the last router before the
   user terminal which might be, for instance, a WLAN access point.
   This router acts as a signaling responder.

   The parameters that need to be configured with the configuration
   request message are the following:

   Correlation ID

      This parameter refers to an ID which is unique for each service.
      It will be used by the Collector to assign different accounting
      records to the same service.

   Flow ID

      This parameter identifies the data flow(s) that need(s) to be
      accounted.  Here, the flow information from the NTLP can be used.
      However, several entries SHOULD be possible for this parameter to
      enable configuring the Metering Entities to perform accounting for
      several flows (for instance audio and video) using a single
      configuration message.

   Metered Objects

      This parameter contains a list of the objects that need to be
      accounted for the considered data flow.

      *  Flow Properties: These are dynamic properties of the data
         stream to be metered:
         +  number of observed packets of the flow
         +  number of observed octets of the flow
         +  timestamp of first observation of a packet of the flow.
         +  timestamp of last observation of a packet of the flow.

      Note that in the timestamps, the absolute time might be required
      since the tariffs might depend on the time of the day.

      Besides the metered objects above, the following objects may also
      need to be recorded and reported to the Collector:

      *  Application events: service invocation, loss of bearer,
         insertion of advertisements and other application events.
      *  Mobility events: horizontal and vertical handovers.
      *  Access network type
      *  Report if the end host is roaming.





Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt        [Page 9]


Internet-Draft              M-NSLP Framework                October 2005


      *  Access network types: so the user can be charged differently
         depending on the current access technology
      *  Different identities for the end host: e.g.  Mobile Subsriber
         ISDN Number(MSISDN)
      *  IP address of gateways, meters and other network elements

   Reporting Interval

      In order to reduce the number of export messages sent to the
      Collector, it is advantageous not to send accounting data
      immediately but to wait until the message is filled with a certain
      amount of data.  This parameter indicates the maximum time to wait
      for more data until an exported data set is sent.  Long living
      flows are reported regularly in interval no longer than specified
      by this parameter.

   Flow Expiration Time

      If no packets are observed for the specified amount of time
      interval, the flow is considered as expired and it is reported.

   Collector ID

      This parameter specifies where the accounting records need to be
      sent to.

   Reporting Protocol

      This parameter specifies which protocol to use to report the
      accounting data, for example, IPFIX, Netflow5 or Netflow9.

   SelectionOfMeteringEntities

      This parameter determines how the Metering Entities that should
      perform the accounting of the considered data flow are selected.
      For the accounting scenario, possible options for this parameter
      are:
      *  ANY: any Metering Entity on the path that is capable of
         performing accounting with the requested objects in the
         parameter "Metered Objects" should do it.  In the extreme case,
         this could be the signaling initiator itself.
      *  Enterprise-specific: Enterprises may wish to define their own
         methods to decide which Metering Entities should perform the
         metering.  In this case, the parameter
         SelectionOfMeteringEntities needs to be combined with an
         enterprise-specific identifier.  (See also
         http://www.iana.org/assignments/enterprise-numbers)




Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 10]


Internet-Draft              M-NSLP Framework                October 2005


4.2.  QoS Monitoring

4.2.1.  Scenario Description

   For a network user, it may be interesting at any time to check the
   QoS for a certain service.  The service of interest can be coarse
   grained, for example, the QoS parameters provided by the link to the
   edge router (access point) or fine grained, for example, the QoS
   provided by a UDP data stream received from a video server.  In any
   case, the first step of analysis that the user can perform is
   measuring the rates of sent and received traffics (including a
   consideration of re-transmissions).

   If such cases, local measurement indicates a non-satisfactory
   situation.  A next step of analysis would be QoS measurement along
   the data path of the service of interest.  A measurement of packet
   bit rate, packet loss, jitter and other QoS parameters at several
   points of the data path could identify the cause of unsatisfactory
   QoS and locate where it is caused.

   A similar, probably more important scenario is an ISP that detects
   that the QoS it provides to a customer does not match the service
   level agreement for this service.  Then a measurement at several
   locations along the data path of the service of interest would be
   desirable for identifying the cause and location of QoS degradation.

   Both cases described above (and a huge range of related cases) could
   be solved by massive deployment of metering technology, for example,
   by measuring all flows at all routers in the network.  Then, in case
   of a problem (or of a regular check) the information for a certain
   flow of interest can be retrieved from the huge amount of collected
   metering data.  This approach is oversized, scales badly, and the
   benefit gained is most likely not worth the investment and the
   operational costs.

   Configuring available Metering Entities on the data path appears to
   be a more appropriate solution.  In such a scenario, the requesting
   party would configure some or all available Metering Entities along
   the path of a service of interest in order to meter the particular
   service and report the metered data.

   Such configuration can be performed in a traditional way by
   individually, one by one, configuring all Metering Entities.  This
   requires knowledge about the path taken by the service of interest,
   knowledge about the available Metering Entities on this path and a
   communication with each of them using an agreed (preferably
   standardized) protocol.




Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 11]


Internet-Draft              M-NSLP Framework                October 2005


   The approach suggested by this document simplifies this task.  By
   using path-coupled configuration of traffic measurement, a requesting
   party that is located on the path of interest does just need to send
   a single configuration request along the path in order to communicate
   with all available Metering Entities on this particular path.

   Since different measurements are required for different QoS
   parameters, the request sent along the path varies.  This is
   illustrated by two example scenarios, one for packet loss metering
   and one for delay metering.


      +---------------------------------------------------------+
      |                                                         |
      |                   Administrative Domain                 |
      |                                                         |
      |  ingress       internal       internal        egress    |
      |   node          node 1         node 2          node     |
      | +-------+      +-------+      +-------+      +-------+  |
      | |       |<====>|       |<====>|       |<====>|       |  |
      | |       |      |       |      |       |      |       |  |
   ---->|  ME   |----->|  ME   |----->|  ME   |----->|  ME   |---->
      | |       |      |       |      |       |      |       |  |
      | +-------+      +-------+      +-------+      +-------+  |
      |                                                         |
      +---------------------------------------------------------+

      +---+
      |ME | = Metering   === = Signaling    --- = Data Flow
      +---+   Entity           Messages

   Figure 3: Signaling to configure metering for QoS monitoring

   Figure 3 shows a data stream passing a domain.  Let's assume that at
   the ingress node a problem with the data stream is detected and that
   it wants to initiate traffic measurement for the data stream along
   the path it takes through the domain.  Then the ingress node sends a
   signaling message along the path in order to configure available
   Metering Entities.

   If packet loss in the domain is the target of this investigation,
   then all available Metering Entities on the path will be requested to
   participate in the measurement.  All will be requested to measure the
   number of packets observed for the data stream of interest and to
   report the results to either the requesting ingress node or to
   another Collector of traffic metering data.  Then the collected data
   can be analyzed in order to identify locations in the domain where
   packet loss occurs.  Note here, that the Metering Entities need to



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 12]


Internet-Draft              M-NSLP Framework                October 2005


   report their positions on the path to the Collector in order to
   enable reasonable evaluation of the Metering Records.

   In a similar way delay can be analyzed.  Different to loss metering,
   delay measurement require per packet reporting from the Metering
   Entities.  For each observed packet belonging to the data stream of
   interest, the Metering entity needs to report a hash value of the
   packet header and a timestamp.  In order to reduce the number of
   reports, reporting can be restricted to a certain range of hash
   values.  Then the Collector of the metered data can again analyze the
   sources of delay within the domain.  Note here that, as above, the
   Metering Entities need to report their positions on the path to the
   Collector.

   If less detailed metering is required, for example, if loss and delay
   only needs to be measured for the entire domain (and not hop by hop),
   then not all Metering Entities need to participate.  It is sufficient
   if just the ingress and the egress node perform metering.  Metering
   at internal nodes is not required.  Per-domain packet loss and per-
   domain delay can be derived from packet counters and time stamped
   packet hash values metered at ingress and egress nodes.

4.2.2.  Configuration Parameters

   Very similar to the accounting scenario in Section 4.1.2, the
   signaling initiator sends a configuration request message along the
   data path.  The parameters that need to be configured are the
   following:

   Correlation ID

      Similar to the accounting scenario, this is an ID that identifies
      this measurement.  It can be used by the Collector for identifying
      incoming reports that belong to the same measurement.

   Flow ID

      Same as for the accounting scenario

   Metered Objects

      The objects to be measured:
      1.  Flow Properties: same as for the accounting scenario.
      2.  Packet Properties:
          +  hash value
          +  number of octets





Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 13]


Internet-Draft              M-NSLP Framework                October 2005


          +  time stamp

   Reporting Interval

      Same as for the accounting scenario

   Flow Expiration Time

      Same as for the accounting scenario

   Collector ID

      Same as for the accounting scenario

   Reporting Protocol

      Same as for the accounting scenario

   SelectionOfMeteringEntities

      This parameter specifies the requirement for Metering Entities
      along the data path.  Among the required values for this parameter
      are
      *  first: only the first available Metering Entity on the path is
         requested to perform metering.  In the extreme case, this
         request is served by the signaling initiator itself.
      *  last: only the last available Metering Entity on the path is
         requested to perform metering.  In the extreme case, this
         request is served by the signaling responder.
      *  all: all available Metering Entities on the path are requested
         to perform metering.
      *  first and last: only the first and the last available Metering
         Entities on the path are requested to perform metering.


4.3.  Monitoring for Network Security

4.3.1.  Scenario Description

   Basically, the prevention of various threats in the Internet is based
   on the detection of an ongoing malicious activity and the
   configuration of appropriate firewall rules.  Distributed monitoring
   is required for scanning particular malicious flows.  In case of IP
   address spoofing, a path-coupled configuration of the Metering
   Entities can be used to detect packets that are not supposed to be
   routed on this path.

   Most network security mechanisms such as intrusion detection are



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 14]


Internet-Draft              M-NSLP Framework                October 2005


   based on the capability to monitor the network behavior.  Network
   monitoring involves:
   o  statistics, i.e. collection of statistical measures, such as
      packet rate, bit rate, number of connections, etc.
   o  packet sampling, i.e. collection of complete packets based on
      rules (filters) and sampling algorithms

   The gathered information about the network traffic can be used for an
   analysis of packet's payload for known attack/intrusion patterns as
   well as for anomaly detection mechanisms.

   It is desirable that monitoring devices can be re-configured
   dynamically, depending on the state of the network to know more about
   a specific data flow when an attack is being assumed.  Note here,
   that the attack might be of a different nature, for example, SYN
   flood or ICMP flood, or application-specific attacks.

   Figure 4 depicts such as scenario.  A potential on-going attack is
   detected, either by the victim, which sends a notification to the
   Attack Detection System, or by the Attack Detection System itself.
   The attack detection system instructs the ingress points of the
   network to perform metering for the traffic designated to the victim
   and initiate signaling towards the victim for metering configuration.




























Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 15]


Internet-Draft              M-NSLP Framework                October 2005


       +-----------------------------------------------------------+
       |                                                           |
       |                 Administrative Domain A                   |
       |                                                           |
       |              +----------------------------+               |
       |              |    Attack Detection System |               |
       |              +----------------------------+               |
       |               ^          ^   ^          ^                 |
       |             **          *     *           #               |
       |           **           *       *            #             |
       |         **            *         *             #           |
       |       **             *           *              #         |
       | Ingress Node A      probe 1     probe 2                   |
       | +-----------+      +----+      +----+      +-----------+  |
       | |           |=====>|    |=====>|    |=====>|           |  |
       | |           |      |    |      |    |      |           |  |
    ---->|    ME     |----->| ME |----->| ME |----->|    victim |---->
       | |           |      |    |      |    |      |           |  |
       | +-----------+      +----+      +----+      +-----------+  |
       |                                                           |
       +-----------------------------------------------------------+

       +---+
       |ME |= Metering     === = Meter. Configuration   --- = Data Flow
       +---+  Entity             Signaling Messages      ## other protocol

   Figure 4: Signaling to configure metering for attack detection

   In the figure above, the Metering Entities along the data path from
   the ingress point A to the victim can be configured to meter/monitor
   the packets belonging to a particular data flow.  Metering Data is
   transferred to the according attack detection system for further
   analysis.

4.3.2.  Required Parameters

   Very similar to the accounting scenario in Section 4.1.2, the
   signaling initiator sends a configuration message along the data
   path.  The parameters that need to be configured are the following:

   Correlation ID

      Similar to the accounting scenario, this is an ID that identifies
      this measurement.  It can be used by the Collector for identifying
      incoming reports that belong to the same measurement.






Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 16]


Internet-Draft              M-NSLP Framework                October 2005


   Flow ID

      Same as for the accounting scenario

   Metered Objects

      The objects to be measured:
      1.  Flow Properties: same as for the accounting scenario.
      2.  Packet Properties:
          +  header information
          +  parts of the packet
          +  complete packets

   Reporting Interval

      Same as for the accounting scenario

   Flow Expiration Time

      Same as for the accounting scenario

   Collector ID

      Same as for the accounting scenario

   Reporting Protocol

      Same as for the accounting scenario in case of requested flow
      statistics or PSAMP for reporting complete per packet information.

   SelectionOfMeteringEntities

      This parameter specifies the requirement for Metering Entities
      along the data path.  Among the required values for this parameter
      are
      *  ANY: any Metering Entity on the path that is capable of
         performing the monitoring should do it.  In the extreme case,
         this could be the signaling initiator itself.
      *  first: only the first available Metering Entity on the path is
         requested to perform metering.  In the extreme case, this
         request is served by the signaling initiator itself.
      *  last: only the last available Metering Entity on the path is
         requested to perform metering.  In the extreme case, this
         request is served by the signaling responder.
      *  all: all available Metering Entities on the path are requested
         to perform metering.





Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 17]


Internet-Draft              M-NSLP Framework                October 2005


      *  first and last: only the first and the last available Metering
         Entities on the path are requested to perform metering.


5.  Requirements

   This section describes the requirements for a path-coupled signaling
   for the configuration of Metering Entities.  We assume existing
   protocols or other means for transferring
   1.  captured packet information from the Monitoring Probes to the
       Metering Entities and
   2.  Metering Data from the Metering Entities to Collectors.

   Note that the Monitoring Probes and the Metering Entities are co-
   located.

5.1.  General requirements

5.1.1.  Extensibility

   The specification of the path-coupled metering configuration protocol
   should be extensible to future technologies.  This includes the
   extensibility of the configuration of the Metering Entities.

   Moreover, the metering configuration protocol should bridge between
   different existing metering solutions, for example, those defined in
   3GPP.  The communication may be organized using proxy or agent based
   systems.

5.1.2.  Scalability

   A Metering Entity needs to keep state and perform metering actions
   for each accepted metering task.  Handling high numbers of metering
   tasks need to be provided by the Metering Entity implementation and
   is not subject of a signaling protocol.  However, the protocol design
   should provide scalability for state keeping and refresh for a large
   number of concurrent metering tasks.

5.1.3.  Security

   Security requirement of the path-coupled metering configuration
   protocol are discussed in Section 7

5.2.  Flexible metering model

   The metering configuration protocol should support a flexible
   metering model.  Depending on the metering scenario, different
   information must be exchanged between the Metering Entities.



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 18]


Internet-Draft              M-NSLP Framework                October 2005


5.3.  Distinguishing flows

   A primary capability of the metering function is the identification
   of data packets belonging to different applications or users.  The
   configuration of the Metering Entities should take this parameter
   into account.  During the data flow life-time, statistics describing
   the properties of this data flow are gathered and exported to a
   Collector.  The metering configuration should be flexible to allow
   the description of multiple services and associated flows.

   Flows belonging to one application: the metering configuration should
   allow the aggregation of Metering Records for streams belonging to a
   particular application, for example, a multimedia transmission with
   associated data transfers (web pages).

5.4.  Aggregation of Metering Records

   The metering configuration SHOULD allow the aggregation of Metering
   Data belonging to the same measurement or to the same applications to
   reduce the data exported to the Collector.

5.5.  Flexible data collection

   After the gathering of Metering Data, it has to be transferred to the
   appropriate Collector(s).  The protocol for configuring Metering
   Entities MUST be independent of the protocol used for transferring
   Metering Data.  One possible protocol is IPFIX [I-D.ietf-ipfix-
   protocol].  The IPFIX information model ([I-D.ietf-ipfix-info]) is
   very flexible for extensions and, therefore, adequate for this
   application.

5.6.  Location of Metering Entities

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

   Metering Entities can be located anywhere along the data path, for
   example, only in a subset of the path, or only at start and end point
   etc.

5.7.  Location of the Collectors

   The Metering Data need to be transferred to one or eventually several
   Collectors.  The process of discovering which Collector is interested
   in which Metering Data is out of scope.  It is assumed that the
   signaling initiator knows the location of the Collectors by different



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 19]


Internet-Draft              M-NSLP Framework                October 2005


   means.

5.8.  Configuration protocol

5.8.1.  Configuration of Metering Entities

   The protocol MUST be able to configure Metering Entities, for
   example, to control which information needs to be collected and which
   entities are allocated which task.

   Protocol messages need to be interpreted only by Metering Entities.

5.8.2.  Selection of Metering Entities

   The protocol MUST provide functionality to select Metering Entities
   that become part of a metering process by specifying, for example,
   their type, position or total number.

5.8.3.  Metering Configuration State installation and removal

   The protocol MUST be able to install metering state and also to
   remove it.  Furthermore, metering state SHOULD be soft state in order
   to cope with rerouting and device failure.

5.8.4.  Initiation and maintenance of metering tasks

   The protocol MUST be able to transport a trigger to start and stop of
   collection of Metering Data, a correlation identifier that allows the
   Collector to correlate Metering Data received from different Metering
   Entities, and a trigger to send off Metering Data to the Collector.

5.8.5.  Reaction to Route Changes

   The protocol MUST be able to react to rerouting of the packets that
   are to be metered.  Rerouting may imply including new Metering
   Entities and removing some.  This requirement is important especially
   for the accounting scenario: if routes change unnoticed the user will
   use the service for free.

5.8.6.  Collection of information on available Metering Entities

   The protocol MAY support the collection of information on Metering
   Entities and their capabilities without actually installing any
   state.

5.8.7.  Scoping of configuration

   The protocol MUST be able to scope messages.  For example, the scope



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 20]


Internet-Draft              M-NSLP Framework                October 2005


   could be the domain of an operator.  Another important type of scope
   is up to a particular type of Metering Entity.  An example is a scope
   that terminates a signaling message originating in the core of the
   network at the access router in order to both save resources on the
   air interface and to hide monitoring or charging configuration data
   from the user.  Another example is scoping the signaling, for
   example, to the responsible UMTS GGSN (Gateway GPRS Support Node: a
   router that serves as a gateway between mobile networks and packet
   data networks) because it is known that Metering Entities beyond the
   GGSN are of no interest for this particular metering configuration.

5.9.  Metering across domains

   Metering configuration SHOULD be possible across administrative
   domains.  There are challenging security aspects in this goal.  (See
   also Section 7)


6.  Applicability of the NSIS Architecture

   According to the NSIS framework [RFC4080], the NSIS protocol suite
   can support various signaling applications that need to install or
   manipulate state in NSIS-aware network nodes (NEs) along the path of
   a data flow.  The NSLP messages do not need to run all the way
   between the data flow endpoints.  Rather, the NSIS initiating NE and
   the NSIS receiving NE can be located anywhere along the data path.

   The problem of path-coupled signaling to configure Metering Entities
   seems to be well suited to be solved with a novel NSIS signaling
   application, the Metering NSLP.  The Metering NSLP can run on top of
   the NTLP similarly to the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the
   NAT/Firewall NSLP [I-D.ietf-nsis-nslp-natfw]

   The Metering NSLP needs to be able to install, modify and remove
   metering configuration related state.  Furthermore, signaling for
   metering configuration needs the flexibility provided by NSIS to
   start and end on arbitrary Metering Entities.  Any Metering Entity on
   the data path is able to initiate metering configuration signaling.
   The selection of signaling initiator and receiver depends on the
   configuration and on the specific application environment.

   Finally, a Metering NSLP, similar to QoS NSLP, would be independent
   of the actual configuration information it carries.  Hence, it can be
   used for any metering application.


7.  Security Considerations




Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 21]


Internet-Draft              M-NSLP Framework                October 2005


   The process of configuring Metering Entities to start and stop
   metering and to transmit collected Metering Data to a third party
   introduces several security challenges.  The following security
   issues need to be considered for the design of the Metering NSLP.

7.1.  Authorization Model

   It MUST be assured that configuration messages for starting,
   refreshing and stopping a metering configuration are correctly
   authorized before the configuration is executed.  Bogus configuration
   messages can be used for different kind of attacks.  For example, in
   the accounting scenario if a malicious user is able to stop metering
   of requested services then fraud is possible.  Also, it MUST be not
   possible to configure Metering Entities in such a way that other
   users are charged for the usage of a service which they have not
   used.

   The authorization model for the Metering NSLP can be, for example,
   similar to the authorization model for the QoS NSLP (New Jersey
   Turnpike, i.e. a chain-of-trust is established by peering
   relationships between neighboring networks entities).

7.2.  Inter-working between different domains

   Inter-working between multiple domains causes authorization problems.
   If the scope of the configuration signaling should go beyond the
   borders of a single domain, the ISPs need to be authorized to perform
   metering configuration across other domains and to collect metering
   and monitoring data.  A high degree of trust is required to allow
   other domains to configure Metering Entities and to collect the
   Metering Data of particular users.

   The above considerations raise the main question whether the Metering
   NSLP can be used outside a single administrative domain.  Ideally, it
   should have a broader applicability but security, privacy and other
   operational concerns may limit its applicability for multiple domain
   traversal (and also end-to-end signaling).

7.3.  End User Privacy

   The collection of Metering Data about individual flows is a privacy
   sensitive task.  ISPs which intend to deploy the Metering NSLP may
   need to clarify the following questions:
   o  Who owns, in legal terms, the collected data (e.g., the user who
      initiated the flow, the owner of the Monitoring Probe?
   o  Does ownership imply other rights (e.g., the right to
      dissemination)?  Is it necessary to consider privacy policies?  Is
      it necessary to constrain the distribution of the collected data



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 22]


Internet-Draft              M-NSLP Framework                October 2005


      in some way (e.g. based on user privacy policies)?
   o  Do certain terms and conditions, to which the metering site(s),
      and the user have to agree, apply?
   o  Is it necessary to protect the confidentiality of the metered
      data?

   Note for the last bullet point, that confidentiality of the Metering
   Data in general is feasible.  For example, the IPFIX protocol
   supports the transport of the Metering Data using ESP ([ID-ietf-
   ipfix-protocol]).

7.4.  ISP Privacy

   This issue is relevant only for the case that the signaling for
   metering configuration operates across several domains and Metering
   Data might be delivered to a Collector belonging to a foreign
   administrative domain.  In this case, the Metering Data may reveal
   sensitive topology information of the ISP network.

7.5.  Forged Collector

   It MUST be assured that the Collector that is specified in a
   configuration message is eligible to receive the Metering Data.
   Otherwise several kind of attacks are possible.
   o  As already mentioned in Section 7.3 and Section 7.4 if the
      Metering Data are received by a bogus Collector, this will reveal
      customer and/or ISP sensitive information
   o  In the accounting scenario the customer could, by specifying an
      uneligible Collector, cause the resource usage data to be sent to
      a bogus Collector and therefore would be able to use the services
      for free.

7.6.  Denial-of-Service Attacks on the Collector

   In any application scenario for the Metering NSLP, it MUST be assured
   that the Collector is supposed to receive the Metering Data.
   Otherwise, a DoS attack (via amplification) would be possible if data
   can be sent to an arbitrary IP address.  The adversary needs to send
   a single metering NSLP message in order to flood a victim with
   potentially a huge amount of data over a certain period of time.

7.7.  Denial-of-Service Attacks on Metering Entities

   Metering Entities can be subject to DoS attacks if a large number of
   Metering Data have to be collected or large per-flow states are
   created.





Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 23]


Internet-Draft              M-NSLP Framework                October 2005


7.8.  Verification of the Flow Specification

   The flow specification within a metering configuration message
   (which, as mentioned above, may or may not be equal to the Message
   Routing Information from the NTLP) needs to be verified for
   integrity.  Especially, it MUST be assured that an end host may be
   able to trigger the collection of Metering Data by itself about a
   flow that it created (this depends also on the application scenario)
   but not for other flows belonging to other users.  However, if there
   is a signaling proxy that initiates the signaling on behalf of other
   users, different authorization policies need to be deployed.


8.  Contributors

   This document is the result of the effort of a Metering NSLP team
   that has been built.  Except the individuals listed in the author
   list, the team includes also Juergen Quittek and Hannes Tschofenig.

   Furthermore, the authors would like to thank Ralph Kuehne (Siemens
   AG/ University of Tuebingen) and Uwe Foell for their input on the
   description of the accounting scenario.


9.  References

9.1.  Normative References

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

   [I-D.dressler-nsis-metering-nslp]
              Dressler, F., "NSLP for Metering Configuration Signaling",
              draft-dressler-nsis-metering-nslp-02 (work in progress),
              July 2005.

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

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






Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 24]


Internet-Draft              M-NSLP Framework                October 2005


9.2.  Informative References

   [RFC2138]  Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S.
              Willens, "Remote Authentication Dial In User Service
              (RADIUS)", RFC 2138, April 1997.

   [RFC3726]  Brunner, M., "Requirements for Signaling Protocols",
              RFC 3726, April 2004.

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

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

   [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-info]
              Quittek, J., "Information Model for IP Flow Information
              Export", draft-ietf-ipfix-info-11 (work in progress),
              September 2005.

   [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-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-psamp-framework]
              Duffield, N., "A Framework for Packet Selection and
              Reporting", draft-ietf-psamp-framework-10 (work in
              progress), January 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.

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



Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 25]


Internet-Draft              M-NSLP Framework                October 2005


              6.0.0.

   [3GPP.32.260]
              3GPP, "Telecommunication management; Charging management;
              Charging architecture and principles;  IP Multimedia
              Subsystem (IMS) charging", 3GPP TS 3GPP.32.260.













































Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 26]


Internet-Draft              M-NSLP Framework                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/


   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13627
   Germany

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


   Changpeng Fan
   Siemens AG
   Siemensdamm 62
   Berlin  13627
   Germany

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


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

   Phone: +49 9131 85-27914
   Email: dressler@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/







Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 27]


Internet-Draft              M-NSLP Framework                October 2005


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

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









































Fessi, et al.   draft-fessi-nsis-m-nslp-framework-02.txt       [Page 28]


Internet-Draft              M-NSLP Framework                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-fessi-nsis-m-nslp-framework-02.txt       [Page 29]


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