Network Working Group A. Fessi Internet-Draft G. Carle Expires: September 6, 2007 University of Tuebingen F. Dressler University of Erlangen J. Quittek NEC C. Kappler H. Tschofenig Siemens AG March 5, 2007 NSLP for Metering Configuration Signaling <draft-dressler-nsis-metering-nslp-05.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Monitoring, metering and accounting of packets are increasingly Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 1] Internet-Draft Metering NSLP March 2007 important functionality that needs to be provided in the Internet. This document proposes the definition of a new NSIS Signaling Layer Protocol (NSLP), named Metering NSLP (M-NSLP), which allows the dynamic configuration of Metering Entities on the data path. An accompanying document [I-D.fessi-nsis-m-nslp-framework] provides a problem statement, describes scenarios where such a path-coupled configuration of Metering Entities is useful, elaborates requirements for a path-coupled protocol for the configuration of Metering Entities and discusses the applicability of NSIS for this purpose. This document defines a Metering NSLP protocol design and messages, and describes the protocol operation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Model of operation . . . . . . . . . . . . . . . . . . . . 7 3.2. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 9 3.2.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Soft State . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Message Sequencing . . . . . . . . . . . . . . . . . . . . 10 4.3. Message Scoping . . . . . . . . . . . . . . . . . . . . . 10 4.4. Selection of MNEs . . . . . . . . . . . . . . . . . . . . 11 4.5. Coordination of Metering Tasks . . . . . . . . . . . . . . 11 4.6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Reaction to Route Changes . . . . . . . . . . . . . . . . 11 4.8. Metering Configuration Information . . . . . . . . . . . . 12 4.9. Required State Information . . . . . . . . . . . . . . . . 12 5. Metering NSLP Messages and Objects . . . . . . . . . . . . . . 13 5.1. Metering NSLP Objects . . . . . . . . . . . . . . . . . . 13 5.1.1. The 'Session Identifier' Object (SID) . . . . . . . . 13 5.1.2. The 'Message Sequence Number' Object (MSN) . . . . . . 13 5.1.3. The 'Selection of Metering Entities' Object (MNE_Selection) . . . . . . . . . . . . . . . . . . . 13 5.1.4. The 'Session Lifetime' Object (Session_LT) . . . . . . 14 5.1.5. The 'MNSLP Hop Count' Object (MNSLP_Hop_Count) . . . . 14 5.1.6. The 'Information Code' Object (INFO) . . . . . . . . . 14 Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 2] Internet-Draft Metering NSLP March 2007 5.1.7. MSPEC Objects . . . . . . . . . . . . . . . . . . . . 15 5.2. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 15 5.2.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. MSPEC Objects . . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. IPFIX MSPEC Object . . . . . . . . . . . . . . . . . . 17 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Session State Machine . . . . . . . . . . . . . . . . . . 18 6.2. Standard Message Processing Rules . . . . . . . . . . . . 21 6.2.1. Message Parsing . . . . . . . . . . . . . . . . . . . 21 6.2.2. Authentication and Authorization . . . . . . . . . . . 21 6.2.3. Message Sequencing . . . . . . . . . . . . . . . . . . 21 6.2.4. MNSLP Hop Counting . . . . . . . . . . . . . . . . . . 22 6.3. Message Processing Rules . . . . . . . . . . . . . . . . . 23 6.3.1. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . 23 6.3.2. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.3. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.4. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 25 6.3.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 25 6.4. Message Forwarding . . . . . . . . . . . . . . . . . . . . 26 6.5. Interaction with GIST . . . . . . . . . . . . . . . . . . 26 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 27 7.1. Example with MNE_Selection is ANY . . . . . . . . . . . . 27 7.2. Example with MNE_Selection is ALL . . . . . . . . . . . . 28 7.3. Example with MNE_Selection is FIRST_and_LAST . . . . . . . 29 7.4. Example with a Route Changes . . . . . . . . . . . . . . . 30 8. Bit-Level Formats and Error Messages . . . . . . . . . . . . . 30 8.1. Metering NSLP Messages . . . . . . . . . . . . . . . . . . 30 8.2. Metering NSLP Objects . . . . . . . . . . . . . . . . . . 31 8.2.1. MSN . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2.2. Session_LT . . . . . . . . . . . . . . . . . . . . . . 32 8.2.3. MNE_Selection . . . . . . . . . . . . . . . . . . . . 32 8.2.4. INFO . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.2.5. MSPEC Objects . . . . . . . . . . . . . . . . . . . . 33 9. Mapping onto M-NSLP Requirements . . . . . . . . . . . . . . . 34 10. Security considerations . . . . . . . . . . . . . . . . . . . 36 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 3] Internet-Draft Metering NSLP March 2007 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 41 Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 4] Internet-Draft Metering NSLP March 2007 1. Introduction Monitoring, metering and accounting of packets is an important functionality in many networks today. Several working groups have described mechanisms to collect and report usage data for resource consumption in a network by a particular entity. For example, the IPFIX WG defines a protocol for this purpose. The PSAMP WG defines a standard to sample subsets of packets by statistical and other methods. RADIUS (see [RFC2865] and [RFC2866]) and DIAMETER (see [RFC3588] and [I-D.ietf-aaa-diameter-cc]) are also protocols which provide information about consumed resources. The Meter MIB [RFC2720] is a MIB for collecting flow information. However, it is also necessary to configure and coordinate the entities performing the metering. RADIUS, DIAMETER and SNMP are candidates for this configuration. Nevertheless, these protocols require some knowledge about the location of the appropriate Metering Entities to configure them. In more complex network topologies and architectures, the appropriate entities to meter the properties of a given data flow can be discovered dynamically using path-coupled signaling. If more than one Metering Entity is required, all of them can potentially be configured and coordinated with a single message along the path. Scenarios and requirements for Metering NSLP are described in [I-D.fessi-nsis-m-nslp-framework]. This draft defines the Metering NSLP for configuration and coordination of Metering Entities in a path-coupled fashion. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Furthermore, the terminology defined by GIST [I-D.ietf-nsis-ntlp] applies to this draft. Moreover, this document uses the following terms: Metering Record A Metering Record describes flow characteristics for a particular flow. Examples of such data are packet counter and time information. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 5] Internet-Draft Metering NSLP March 2007 Monitoring Probe A Monitoring Probe is an entity that examines data flows in order to gather Metering Records. Metering Entity A Metering Entity is a node that is equipped with one or more Monitoring Probes. A Metering Entity MAY process the Metering Records, e.g. by aggregating them or by sampling them, before they are exported elsewhere, typically to a Collector. A Metering Entity MAY host other functions, for example, for processing of NSIS signaling. Collector A Collector receives Metering Records from one or multiple Metering Entities. These Metering Records can be aggregated and/or correlated by the Collector. The Collector is typically not co-located with a Metering Entity. Another protocol (e.g. IPFIX) is needed to transport the Metering Records from the Metering Entity to the Collector. Metering Configuration State A State used/kept by the Metering Manager to configure the Monitoring Probe. Metering Manager A unit co-located with the Monitoring Probe that communicates with M-NSLP processing. It holds Metering Configuration State which is used to configure the Monitoring Probe. Metering NSIS Entity (MNE) A Metering Entity which supports the Metering NSLP. Metering NSIS Initiator (MNI) The first node in the sequence of MNEs that issues a configuration message for a flow or aggregate. Metering NSIS Responder (MNR) The last node in the sequence of MNEs that receives a configuration message for a flow or aggregate. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 6] Internet-Draft Metering NSLP March 2007 Metering NSIS Forwarder (MNF) A MNE that is neither MNI nor MNR. 3. Protocol Overview The design for the Metering NSLP and the processing of M-NSLP messages is in some aspects similar to QoS NSLP [I-D.ietf-nsis-qos-nslp] and in other aspects to the NATFW NSLP [I-D.ietf-nsis-nslp-natfw]. One of the main differences compared to the QoS NSLP and the NATFW NSLP is that only a subset (in some cases even only one) of the Metering Entities in the signaling path will take part in the actual Metering. This fact has several consequences on the signaling itself and therefore on the protocol design. 3.1. Model of operation Figure 1 shows an example logical model of the operation of the Metering NSLP and the associated metering mechanism in a MNE. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 7] Internet-Draft Metering NSLP March 2007 +---------------+ | Local | | Management | +---------------+ ^ V +---------+ +----------+ +----------+ | Policy | | M-NSLP | | Metering | | Control |<<>>|Processing|<<>>| Manager | +---------+ +----------+ +----------+ . ^ | V | ^ . V | V . V | V . V +----------+ V | GIST | V .-.-.-.-.-|Processing|-.-.-v.-.-.-.-.-.-.- . +----------+ V | | v . . v | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | v | . v . | +---------------------+ | +----------+ | | +-----------+ <-.-| Input | | Monitoring | | Outgoing |-.-> | Packet | | | | Interface | ===>|Processing|===| Probe |====| |==> +----------+ | | +-----------+ +---------------------+ <.-.-> = signaling flow =====> = data flow (sender --> receiver) <<<>>> = control and configuration operations Figure 1: Metering-NSLP in Metering Entity The Monitoring Probe collects metering data and processes them into Metering Records, which can be sent to the Collector. The Monitoring Probe is co-located with the Input Packet Processing and the Outgoing Interface. A M-NSLP message called CONFIGURE transports: o Control information objects for the M-NSLP Processing, such as message sequence numbers and whether the MNE should actually take part in the metering process Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 8] Internet-Draft Metering NSLP March 2007 o Metering configuration information objects, also called MSPEC objects, that describe the actual configuration information. The MSPEC objects are interpreted by the Metering Manager and SHOULD be opaque to the M-NSLP Processing. o Policy information to authenticate and authorize the configuration request The M-NSLP Processing decides if the current MNE is addressed by this configuring message. If yes, the MSPEC objects are extracted from the M-NSLP message and passed to the Metering Manager, where they are interpreted and used to install Metering Configuration State. The Metering Manager uses this state to configure the Monitoring Probe. The Policy Control determines whether the sender of the M-NSLP message is authorized to configure the Monitoring Probe. From the perspective of a single node, the request for configuration of Metering Entities may result from processing a local management request, or from processing an incoming M-NSLP message. The local management may in turn be triggered by a local application, e.g. when a video is requested from a video server, or by a physically separate network node. 3.2. Metering NSLP Messages The Metering NSLP messages are classified into 3 categories: o request messages o response messages o asynchronous notifications 3.2.1. CONFIGURE CONFIGURE is a M-NSLP request message. It is used to create Metering Configuration State in a Metering Entity. 3.2.2. REFRESH REFRESH is a M-NSLP request message. It is used: o to extend the lifetime of an existing M-NSLP session. o for terminating a session (with session lifetime zero). o to detect route changes at the NSLP layer. 3.2.3. OPTIONS OPTIONS is a M-NSLP request message. It is used to inquire the metetering capabilities of MNEs along the signaling path. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 9] Internet-Draft Metering NSLP March 2007 3.2.4. RESPONSE The RESPONSE message is used to provide information about the result of a previous M-NSLP request. This includes explicit confirmation of the state manipulation signaled in the CONFIGURE/REFRESH message or an error code. 3.2.5. NOTIFY The NOTIFY message is an asynchronous notifications message used to convey information to a MNE. It differs from RESPONSE messages in that it is sent asynchronously and does not need to refer to any particular state or previously received message. The information conveyed by a NOTIFY message is typically related to error conditions. An example would be a notification to the MNI about state being torn down. 4. Design Decisions 4.1. Soft State NSIS state is always soft state and needs to be refreshed. The control information in CONFIGURE/REFRESH messages carry an object that determines the lifetime of a M-NSLP session. The MNI suggests a lifetime for the session that it is being signaled for. Each MNE participating in the metering process MAY or MAY not accept the suggested lifetime or MAY start the metering with a reduced lifetime, depending on the local policies of the MNEs. This behavior is similar to the calculation of session lifetime in the NATFW-NSLP [I-D.ietf-nsis-nslp-natfw]. 4.2. Message Sequencing The order in which M-NSLP requests arrive influences the eventual configuration state that will be stored at a MNE. Therefore the M-NSLP supports the detection of message duplication and re-ordering using a Message Sequence Number (MSN) object. More Details on Message Sequencing are provided in Section 6.2.3 4.3. Message Scoping Metering Entities at the edge of a signaling scope (for example, at the edge of the administrative domain of an ISP) MUST be marked accordingly. The Metering NSLP does not provide means by itself to discover dynamically the border of the signaling scope. When a MNE recognize that it is at the edge of the signaling scope, Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 10] Internet-Draft Metering NSLP March 2007 it MUST terminate the signaling and act as NSIS Responder (NR). 4.4. Selection of MNEs An interesting feature of the Metering NSLP is that only a subset of MNEs on the data path might take part in the actual metering. Metering Entities taking part in the metering process are determined based, for example, on their type or position on the path. When a CONFIGURE message is sent, each MNE on the data path needs to determine whether it will take part in the metering process. For this reason, the 'Selection of Metering Entities' object is included in CONFIGURE messages. 4.5. Coordination of Metering Tasks The M-NSLP allocates different metering tasks to different Metering Entities on the signaling path depending on their position and metering capabilities. A 'Correlation ID' is included in the MSPEC and distributed to the Metering Entities during the configuration process. This 'Correlation ID' can be forwarded to the Collector, which can correlate Metering Records coming from different Metering Entities and belonging to the same session/measurement. 4.6. Aggregation The metering configuration SHOULD allow aggregation of Metering Records belonging to the same user or application. The information required for the aggregation must be specified in the MSPEC. Such aggregation can be done in two ways. o A Monitoring Probe separately collects and reports data for each micro flow (e.g., given for all different combinations of port numbers) contained in the macro flow that is signaled by the NTLP. o A Monitoring Probe separately collects micro flows but reports all flows in a single record. 4.7. Reaction to Route Changes M-NSLP automatically adapts to re-routing events. State along the old path times out automatically. When a new REFRESH message is initiated by the MNI and hits a MNE that is a new on the signaling path, the MNE sends a negative RESPONSE with error code "Unknown Session" backwards to the MNI. The MNI MAY re-initiate the signaling along the new path. Since metering tasks are allocated dynamically to MNEs on the path, when a MNE receives a CONFIGURE message for an existing session, old state for this session MUST be torn down and a new session is created Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 11] Internet-Draft Metering NSLP March 2007 in order to avoid inconsistencies with an old configuration. 4.8. Metering Configuration Information The actual configuration information for the Metering Entities is carried within the MSPEC objects. MSPEC objects are interpreted by the Metering Manager and SHOULD be opaque to M-NSLP Processing. Each MSPEC object contains a meter configuration. A single CONFIGURE message MAY contain multiple MSPEC objects describing different metering tasks, which MAY be allocated to different MNEs. The Metering NSLP does not provide its own format for encoding the MSPEC objects. Instead, formats of existing protocols, such as IPFIX [I-D.ietf-ipfix-protocol], Diameter [RFC3588], or NetFlow [RFC3954], are re-used. The encoding of an MSPEC object depends on the metering and reporting technology. For example, the MSPEC object used for the configuration of an IPFIX device is encoded in IPFIX format. Technology-specific encoding avoids the problems of mapping the different semantics of information models for these technologies to each other. 4.9. Required State Information For each M-NSLP session, the required state information at each MNE consists of: NTLP state NTLP state is required for each M-NSLP session at each MNE on the signaling path, even if the MNE is not taking part in the metering process, in order to avoid GIST re-discovering the MNE each time when it refreshes its routing state [I-D.ietf-nsis-ntlp]. M-NSLP state M-NSLP state is required for each M-NSLP session at each MNE on the signaling path. Even if the MNE is not taking part in the metering process a minimal session state is required, which consists of the Session Identifier (SID) and the Session Lifetime (Session_LT). Assume MNEs located on the signaling path, which are not taking part in the metering process, would not save M-NSLP state for this M-NSLP session. Then when a MNE receives a REFRESH message with an unknown Session ID, it would not be able to make the difference: * whether the MNE is new on the signaling path due to a route change Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 12] Internet-Draft Metering NSLP March 2007 * or whether the MNE has been already on the signaling path but is not taking part in the metering process. Therefore, the MNE needs to keep M-NSLP state for this session in order to be aware of it. Implementations of the M-NSLP MAY include optimizations to reduce the amount of memory required if the session is known but the MNE is not taking part in the metering process. Metering Configuration State (Optional) Metering Configuration State is required for each M-NSLP only if the MNE is taking part in the metering process. It includes the MSPEC objects which describe the metering tasks that are allocated to the MNE. 5. Metering NSLP Messages and Objects 5.1. Metering NSLP Objects 5.1.1. The 'Session Identifier' Object (SID) SID is globally statistically unique identifier for a MNSLP session. SID is not carried explicitly by MNSLP messages. It is rather carried by GIST. SID MUST be generated for each new MNSLP session by the MNI and provided to GIST via the GIST API. All MNFs and the MNR receive the SID via the GIST API and MUST NOT modify it. Note that this is conform to the specification of GIST [I-D.ietf-nsis-ntlp]: Section 3.5. (Signaling Sessions): "Signaling applications provide the session identifier (SID) whenever they wish to send a message, and GIST reports the SID when a message is received." 5.1.2. The 'Message Sequence Number' Object (MSN) MSN is used to detect duplicate and lost Metering NSLP messages. It is also used to to mach an incoming RESPONSE message to the appropriate request. 5.1.3. The 'Selection of Metering Entities' Object (MNE_Selection) This object is required to determine which MNEs will actually take part in the metering. The value of MNE_Selection can be one of the following: Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 13] Internet-Draft Metering NSLP March 2007 o FIRST: the first MNE in the signaling path, i.e. the NI. o LAST: the last MNE signaling in the signaling path, i.e. the NR o 'FIRST_and_LAST': both the NI and the NR take part in the signaling. o ANY: any available MNE can perform the metering. o ALL: Each MNE capable of executing this metering request MUST perform it. "ALL" must be interpreted here as "as many as possible". o Enterprise-specific: Enterprises may wish to define their own methods to decide which Metering Entities should perform the metering. In this case, the parameter 'Selection of Metering Entities' needs to be combined with an enterprise-specific identifier. (See also http://www.iana.org/assignments/enterprise-numbers) If enterprises use their own defined methods for the MNE selection, some other M-NSLP objects not defined in this document may be required to take the decision which MNE will take part in the metering process. 5.1.4. The 'Session Lifetime' Object (Session_LT) This object carries the requested lifetime for a M-NSLP session in a CONFIGURE / REFRESH message or the granted session lifetime in a RESPONSE message, in milliseconds. When a M-NSLP session expires, the Metering Manager MUST configure the Monitoring Probe to stop the Metering. A value of zero for the 'Session Lifetime' object leads to immediate termination of the corresponding session. 5.1.5. The 'MNSLP Hop Count' Object (MNSLP_Hop_Count) This object carries the number of previous MNEs on the signaling path for this session. This object is a integer which starts by zero at the MNI and MUST be incremented by one at each MNSLP hop on the signaling path. 5.1.6. The 'Information Code' Object (INFO) This object carries the response code, which may be an indication for either a successful or failed request depending on the value of the 'response code' field (See Section 8.2.4 for more details). Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 14] Internet-Draft Metering NSLP March 2007 5.1.7. MSPEC Objects The MSPEC objects describe the actual Configuration information. They are interpreted in the Metering Manager and SHOULD be opaque to M-NSLP Processing. MSPEC objects are described separately in Section 5.3. 5.2. Metering NSLP Messages This section defines which objects are carried in each Metering NSLP message. The description is provided in Augmented Backus-Naur Form (ABNF) specified in [RFC4234]. Message format at the bit-level is provided in Section 8 The ABNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation should create messages with the objects in the order shown here, but accept the objects in any order, except for MSPEC object(s) which always appear last in the message, and whose mutual order matters. All M-NSLP messages start with a common header 'HEADER' which is defined in Section 8 Note that the Session ID (SID) is not explicitly mentioned in this notation, since it is provided in GIST. 5.2.1. CONFIGURE The format of a CONFIGURE message is as follows: CONFIGURE = HEADER MSN Session_LT MNE_Selection [MNSLP_Hop_Count] <1>*MSPEC (According to [RFC4234] '<1>*MSPEC' means 'one or more MSPEC objects') 5.2.2. REFRESH The format of a REFRESH message is as follows: REFRESH = HEADER MSN Session_LT 5.2.3. OPTIONS The format of a OPTIONS message is as follows: OPTIONS = HEADER MSN Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 15] Internet-Draft Metering NSLP March 2007 5.2.4. RESPONSE The format of a RESPONSE message is as follows: RESPONSE = HEADER MSN INFO Session_LT <0>*MSPEC (According to [RFC4234] '<0>*MSPEC' means 'zero or more MSPEC objects') The MSN MUST be the same as in the corresponding M-NSLP request in order to match a RESPONSE message to the appropriate request Session_LT carries the granted session lifetime, which might be lower than the session lifetime requested by the MNI. NO MSPEC object MUST be included if INFO indicates a successful confirmation of the request. The MSPEC objects are required only to report a failure in case the MSPEC objects list in the CONFIGURE message, or a sub-set of it, can not be processed. 5.2.5. NOTIFY The format of a NOTIFY message is as follow: NOTIFY = HEADER INFO The INFO indicates the reason for the notification. 5.3. MSPEC Objects As mentioned above, the MSPEC objects describe the actual configuration information. They are interpreted in the Metering Manager and SHOULD be opaque to M-NSLP Processing. Each MSPEC object contains a meter configuration. The MRI provides additional information to the MSPEC object on the flows/packets to be metered. The combination of the MRI and an MSPEC object contains a complete description of a requested metering task. A single CONFIGURE message may contain multiple MSPEC objects describing different metering tasks. There is no common format or semantics for encoding metering tasks within an MSPEC object. The encoding of an MSPEC object depends on the requested metering and reporting technology, such as IPFIX, Diameter, or NetFlow. There are different types of MSPEC objects depending on the metering and reporting technology. For example, there are IPFIX MSPEC objects, Diamter MSPEC objects, etc. The object type, which is Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 16] Internet-Draft Metering NSLP March 2007 provided in the object header as described in Section 8.2, implicits the requested metering and reporting technology. Independently of the encoding, each MSPEC object MUST, in combination with the MRI, contain sufficient information for configuring an MNE to peform a metering task. Specifications of MSPEC objects MUST ensure that they provide sufficient means for configuring the MNE as described in sections 4.1.2 and 4.2.2 of [I-D.fessi-nsis-m-nslp-framework]. Below the MSPEC object for IPFIX metering tasks is specified. MSPEC objects for other meters may be defined in further standards documents. Proprietary MSPEC objects MAY be also used. 5.3.1. IPFIX MSPEC Object The IPFIX MSPEC object uses structure, semantics and encoding of IPFIX Messages as defined in [I-D.ietf-ipfix-protocol] and [I-D.ietf-ipfix-info]. An IPFIX MSPEC object consists of a single IPFIX Message that contains three Sets, a Template Set, an Option Template Set, and a Data Set. Each set contains a single record only. Fields of the header of the contained IPFIX Message are filled with values according to section 3.1 of [I-D.ietf-ipfix-protocol] except for fields "Export Time" and "Observation Domain ID" which must be both set to 0x00000000. The Template Record in the Template Set defines the requested reporting. Except for the Template ID in the Template Record Header, the MNE MUST use exactly this Template Record for reporting metering results. The MNE also MUST use the Template ID received in the Template record for its metering reports. But if there is a collision caused by two different MSPEC objects (potentially from different NSIS sessions) that would violate the uniqueness of Template IDs as specified in section 3.4.1 of [I-D.ietf-ipfix-protocol], then the MNE MUST solve this conflict by modifying Template IDs. In order to keep the probability of such a collision low, the Template ID SHOULD be a randomly generated number. The Option Template Record in the Option Template Set describes the format of the single Data Record in the Data Set. To the Template ID the same rules apply as for the Template Record. The Scope Field Count is always 0. The Data Record in the Data Set contains the requested metering configuration. It is structured according to the Option Template Record in the Option Template Set. It MUST contain the following Information Elements that are specified in [I-D.ietf-ipfix-info]. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 17] Internet-Draft Metering NSLP March 2007 flowKeyIndicator This Information Element identifies which of the reported Flow properties are Flow Keys. collectorIPv4Address or collectorIPv6Address, respectively The IPv4 or IPv6 address, respectively, to which metering results are requested to be reported. collectorProtocolVersion The version of the IPFIX protocol to be used. collectorTransportProtocol and collectorTransportPort The transport protocol and transport port number to be used for reporting metering results The Data record MAY contain further Information Elements for specifying the metering task, for example, the flowIdleTimeout. If flow properties to be measured are specified in the Data record, they serve as filter. Only Flows that match the values of all these Information Element MUST be reported by the MNE. If multiple values are contained for the same property, i.e. it multiple Information Elements with the same Information Element identifier are contained, then it is sufficient if one of these values is matched by a Flow. 6. Processing Rules 6.1. Session State Machine The hereby presented state machine of a M-NSLP session outlines the operation of the M-NSLP. It has three main states: 'closed': At this state, the MNE does not keep any state for the session. 'pending': At this state a CONFIGURE message has been received. The 'pending' state consists of 2 sub-states Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 18] Internet-Draft Metering NSLP March 2007 pending.forward The MNE is not taking part in the metering process. Instead, it is just expecting a confirmation to know that the session is active and some other MNEs will be metering. pending.participating The MNE is actively taking part in the metering process. The MNE has been configured. However, the configuration has not been activated yet, i.e. metering function has not been started. 'metering': At this state the configuration request has been successfully confirmed with an appropriate RESPONSE message. The 'metering' state consists also of 2 sub-states. metering.forward The MNE is not actively taking part in the metering process. Instead, it is informed that the session is active and there are some other MNEs along the signaling path for this session that took over the metering process. metering.participating The MNE is actively taking part in the metering process The MNE is metering according to a metering configuration received by a CONFIGURE message. A session is uniquely identified by the SID. All sessions start in state 'closed'. Transitions between states are caused by events: CONF: This transition is triggered by a CONFIGURE message that is received and processed successfully by the MNE and that identifies a new session. CONF-O: This transition is triggered by a CONFIGURE message that is received and processed successfully by the MNE and that identifies an existing session in state 'pending' or 'metering'. This transition leads always to the state 'closed' in order to avoid Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 19] Internet-Draft Metering NSLP March 2007 inconsistencies with old configurations. Furthermore, this transition MUST be immediately followed by a 'CONF' transition, i.e. after the old session is torn down, a new session is created. REFR: This transition is triggered by a REFRESH message that identifies an existing session in state 'pending' or 'metering'. RESP-P: This transition is triggered by a positive RESPONSE message that indicates that a metering configuration request or a refreshing request can be activated. This transaction always leads to state 'metering'. RESP-N: This transition is triggered by a negative RESPONSE message. This transaction always leads to state 'closed'. T-OUT-1: This transition is triggered by a timeout of a session in state 'pending'. The time interval for this timeout is typically large enough in order to tolerate network failures, network congestion and slow MNEs along the signaling path. This transition always leads to state 'closed'. T-OUT-2: This transition is triggered by a timeout of a session in state 'metering'. The time interval for this timeout is defined by the MNSLP session lifetime. This transition always leads to state 'closed'. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 20] Internet-Draft Metering NSLP March 2007 REFR +----+ | v +----------+ | session | | closed |<---------------+ +----------+ | | ^ | | | CONF-O | CONF-O CONF | | RESP-N | RESP-N v | T-OUT-1 | T-OUT-2 +----------+ +----------+ | pending | RESP-P | metering | | |---------->| | +----------+ +----------+ | ^ | ^ REFR | | REFR | | +----+ RESP-P +----+ Figure 2: M-NSLP Session State Machine 6.2. Standard Message Processing Rules 6.2.1. Message Parsing When a M-NSLP message is received, the MNE first checks the message format. In case of a malformed message or a mandatory object is missing, the MNE MUST NOT propagate the message any further. If the message has been a request the MNE MUST construct an RESPONSE message indicating the error condition and send it back to towards the MNI. If it has been a response, the message is discarded silently. If a message contains an object of an unrecognized type, then the behavior depends on the object type value. 6.2.2. Authentication and Authorization When a M-NSLP message is received, the MNE MUST determine whether the sender of the request is authenticated and authorized before any state changing actions are performed. 6.2.3. Message Sequencing Message sequencing in the Metering NSLP is identical to message sequencing in the NATFW NSLP. In more details: Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 21] Internet-Draft Metering NSLP March 2007 M-NSLP messages need to carry an identifier so that all MNEs along the path can distinguish messages sent at different points in time. Messages can be lost along the path or duplicated. So all MNEs should be able to identify either old messages that have been received before (duplicated), or the case that messages have been lost before (loss). This requires every Metering message to carry a message sequence number (MSN), see also Section 5.1.2. The MSN MUST be set by the NI and MUST NOT be set or modified by any other MNE. The initial value for the MSN MUST be generated randomly and MUST be unique only within the session for which it is used. The NI MUST increment the MSN by one for every message sent. Once the MSN has reached the maximum value, the next value it takes is zero. All MNEs MUST use the algorithm defined in [RFC1982] to detect MSN wrap-arounds. NSIS forwarders and the responder store the MSN from the initial CONFIGURE packet which creates the session as the start value for the session. NFs and NRs MUST include the received MSN value in the corresponding RESPONSE message that they generate. When receiving a request message, a MNE uses the MSN given in the message to determine whether the state being requested is different to the state already installed. If the received MSN value is equal to or lower than the stored MSN value, this can indicate a duplicated or replayed message. In this case, the message MUST NOT have any impact the state of the MNE or the MNSLP session. However, the message MUST be forwarded towards the next MNSLP hop, since one or more of the MNEs on the rest of the signaling path may have not received this message yet. If the received MSN value is greater than the already stored MSN value, the MNE MUST update its stored state accordingly, if permitted by all security checks, and stores the updated MSN value accordingly. 6.2.4. MNSLP Hop Counting Depending on the application scenario for the MNSLP, MNEs may need to know their position on the signaling path. In this case, a MNE needs to make the difference between: o the number of IP hops between the MNI and itself o the number of GIST hops between the MNI and itself o the number of MNSLP hops between the MNI and itself The GIST-hop-count and IP-TTL can be provided by the GIST API as described in [I-D.ietf-nsis-ntlp] (Section B.1 and Section B.2). The MNI MAY introduce an 'MNSLP Hop Count' object in the CONFIGURE Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 22] Internet-Draft Metering NSLP March 2007 message. In cases it does, it MUST set the 'MNSLP Hop Count' to zero. If a 'MNSLP Hop Count' object is included in a CONFIGURE message, MNFs and MNRs MUST increment the 'MNSLP Hop Count' by one before the message is forwarded to the next MNSLP hop. 6.3. Message Processing Rules 6.3.1. CONFIGURE When a MNE receives a CONFIGURE message, and after successful message parsing and authentication/authorization are performed, the MNE performs a lookup in its M-NSLP session table. If the session already exists, the state for this session MUST be torn down and a new session MUST be created in order to avoid inconsistencies with earlier configurations due to the dynamic allocation of the MSPEC objects to the MNEs. Now, regardless of whether the session is new or has been renewed, the MNE needs to figure out if it will take part in the metering process based on the MNE_Selection object, the MSPEC objects list and the capabilities of the MNE. 6.3.1.1. MNE_Selection is ALL o If the MNE is capable of metering the objects in the MSPEC objects list, then the MNE is taking part in the metering process. The MNE MUST change the current session state to 'pending.participating'. o If the MNE is NOT capable of metering the objects in the MSPEC objects list, then the MNE is NOT taking part in the metering process. The MNE MUST change the current session state to 'pending.forward' 6.3.1.2. MNE_Selection is FIRST_and_LAST If MNE_Selection is FIRST_and_LAST and the MNE is the first or the last on the signaling path: o If the MNE is capable of metering the objects in the MSPEC objects list, then the MNE is taking part in the metering process. The MNE MUST change the current session state to 'pending.participating'. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 23] Internet-Draft Metering NSLP March 2007 o If MSPEC objects can not be metered, i.e. the MNE is the first or the last on the signaling path but is not capable to measure the objects given in the MSPEC objects list, the MNE generates a negative RESPONSE message with the appropriate INFO object. The MNE changes the current session state to 'closed'. o EDITORIAL NOTE: The case FIRST_and_LAST is different from the cases ALL and ANY here. If MNE_Selection is FIRST_and_LAST and the MNE is NOT the first NOR the last on the signaling path, the MNE MUST change the current session state to 'pending.forward'. 6.3.1.3. MNE_Selection is ANY In case MNE_Selection is 'ANY', the MNE inspects the MSPEC objects list and removes those objects that it is capable to meter and adds them to its local MSPEC objects list for this session. This local MSPEC objects list represents the list of metering tasks allocated to this MNE for this session. o After inspecting the MSPEC objects list in the CONFIGURE message, if the local MSPEC objects list is empty, i.e. the MNE is not able to meter any of the given objects in the MSPEC objects list, the MNE MUST change the current session state to 'pending.forward'. o If the local MSPEC objects list is NOT empty, i.e. the MNE has been allocated some metering tasks from the MSPEC objects list, the MNE MUST change the current session state to 'pending.participating'. The local MSPEC objects is stored in the Metering Configuration State in order to use when the configuration will be activated. 6.3.2. REFRESH When a MNE receives a REFRESH message, and after successful message parsing and authentication/authorization are performed, the MNE performs a lookup in its M-NSLP session table. o If the Session ID is not known, the MNE constructs a negative RESPONSE message with the appropriate error code and sends it upstream towards the MNI. o If the Session ID is found, the MNE remembers the requested lifetime in the REFRESH message and waits for a confirmation with a RESPONSE message. The current session state remains the same. 6.3.3. OPTIONS tbd. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 24] Internet-Draft Metering NSLP March 2007 6.3.4. RESPONSE When a MNE receives a RESPONSE message and after successful message parsing and authentication/authorization are performed, the remaining processing of the RESPONSE message depends on whether it is a negative RESPONSE or a positive RESPONSE. If it is a negative RESPONSE with the appropriate INFO object: o The MNE MUST change the current state for this session to 'closed'. o The MNE MAY keep state information for this session for optimization purposes, since the the MNI may re-initiate the signaling with different parameters soon. o The MNE MUST forward the message upstream towards the MNI as described in Section 6.4. When the MNI receives this message it MAY take the appropriate action based on the content of the INFO object. If the RESPONSE message is a positive RESONSE, the processing of the message depends on the type of the corresponding M-NSLP request: RESPONSE to a CONFIGURE message The pending configuration can be activated. If the session is currently in state 'pending.participating' the MNE MUST change the session state to 'metering.participating', and the Monitoring Probe MUST be configured to start the metering. If the session is in state 'pending.forward' the MNE MUST change the session state to 'metering.forward'. No configuration action with the Monitoring Probe is taken. RESPONSE to a REFRESH message All existing timeouts for this session are reset. The session lifetime is extended with the lifetime given in the RESPONSE message. Note that this can be different from the session lifetime given in the previous REFRESH message. In both cases, the MNE updates the session lifetime. If the session lifetime is zero, this implies that the session state is changed immediately to 'closed'. 6.3.5. NOTIFY tbd. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 25] Internet-Draft Metering NSLP March 2007 6.4. Message Forwarding CONFIGURE / REFRESH After a M-NSLP request is successfully processed as described in Section 6.3 (no error has been generated), then the session can be either in state 'pending' or 'metering'. Now, MNE needs to decide whether to forward the M-NSLP request towards the MNR or to construct a positive RESPONSE message. M-NSLP requests MUST be forwarded downstream except if: * the M-NSLP request has reached the MNR * the 'scoping' flag is set and the signaling scope has been reached. * all the involved MNEs in the metering process for this session have been reached. The latter case can occur with a CONFIGURE request if MNE_Selection is 'ANY' and the MSPEC objects list has become empty, i.e. an appropriate MNE has been already found for each object in the MSPEC objects list and all the metering tasks have been allocated to some Metering Entities. EDITORIAL NOTE: it has to verified whether this is the only case. In this case, the MNE MUST act as a MNR for this session from now on. All the remaining requests MUST NOT be forwarded any further. RESPONSE / NOTIFY M-NSLP response messages and asynchronous notifications are forwarded upstream, i.e. the reverse direction of the data flow, until they reach the MNI. 6.5. Interaction with GIST M-NSLP request messages (CONFIGURE or REFRESH) are initiated by the MNI and forwarded downstream, i.e. in the same direction as the data flow, towards the MNR, using the GIST API. M-NSLP response messages can be initiated by the MNR or by any MNF on the signaling path and forwarded upstream, i.e. in the reverse direction as the data flow, towards the MNI, using the GIST API. M-NSLP asynchronous notifications can be initiated by any MNE on the signaling path and forwarded upstream, i.e. in the reverse direction as the data flow, towards the MNI, using the GIST API. All M-NSLP signaling is transported using GIST C-mode. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 26] Internet-Draft Metering NSLP March 2007 EDITORIAL NOTE: it should be verified whether D-mode might be also an option for initial configuration messages. However, authentication/ authorization issues need to be considered. 7. Examples of Operation 7.1. Example with MNE_Selection is ANY The MNI constructs a CONFIGURE message with the required MSPEC objects, and sends it towards the MNR. Assume 2 MSPEC objects are included, for example, MSPEC1 for 'counting bytes', and MSPEC2 for 'reporting the usage of the wireless link'. Assume further that MNI itself can perform MSPEC1 while and MNF2 can perform MSPEC2, for example, because it is an access router managing a range of WLAN networks. MNR can be, for example, the WLAN access point. The CONFIGURE message is interpreted by the MNEs along the data path. MNI removes MSPEC1 from the MSPEC objects list, changes its session state from 'closed' to 'pending.participating' and forwards the CONFIGURE message to MNF1. MNF1 receives the CONFIGURE message with only MSPEC2 in the MSPEC objects list. However, MNF1 does not have the capabilities to meter and report the usage of the wireless link. MNF1 changes its session state from 'closed' to 'pending.forward' and forwards the CONFIGURE message to MNF2. MNF2 interprets the CONFIGURE, removes MSPEC2 from the MSPEC objects list. Furthermore, it notices that the MSPEC object lists is now empty. Therefore, MNF2 replies with a positive RESPONSE message and becomes Responder for this session. Subsequent signaling for this session is stopped at MNF2 as shown in Figure 4. MNF2 starts the metering, changes the session state to 'metering.participating', constructs a positive RESPONSE message and sends it to MN1. MNF1 receives the RESPONSE message and changes the session state to 'metering.forward'. MNI receives the RESPONSE message, starts the metering and changes the session state to 'metering.participating'. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 27] Internet-Draft Metering NSLP March 2007 +---+ CONFIGURE +--- + CONFIGURE +-- -+ +---+ | |------------>| |------------>| | | | |MNI| |MNF1| |MNF2| |MNR| | |<------------| |<------------| | | | +---+ RESPONSE +--- + RESPONSE +----+ +---+ Figure 3: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ANY' +---+ REFRESH +---+ REFRESH +---+ +---+ | |------------>| |------------>| | | | |MNI| |MNF| |MNF| |MNR| | |<------------| |<------------| | | | +---+ RESPONSE +---+ RESPONSE +---+ +---+ Figure 4: REFRESH-RESPONSE Message Flow with MNE_Selection 'ANY' 7.2. Example with MNE_Selection is ALL The MNI constructs a CONFIGURE message with the required MSPEC objects, and sends it towards the MNR. The message is interpreted by each MNEs on the data path. Each MNE changes its state for this session to 'pending.participating' or 'pending.forward' depending on whether they are taking part of the metering process. The MNR replies with a positive RESPONSE message. The RESPONSE message is interpreted by each MNE. Each MNE changes the session state to 'metering.participating' or 'metering.forward' depending on whether they are taking part of the metering process. +---+ CONFIGURE +---+ CONFIGURE +---+ CONFIGURE +---+ | |------------>| |------------>| |------------>| | |MNI| |MNF| |MNF| |MNR| | |<------------| |<------------| |<------------| | +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ Figure 5: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'ALL' Similarly, a REFRESH message is initiated by MNI, travels towards the MNR where a RESPONSE is issued and sent back. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 28] Internet-Draft Metering NSLP March 2007 +---+ REFRESH +---+ REFRESH +---+ REFRESH +---+ | |------------>| |------------>| |------------>| | |MNI| |MNF| |MNF| |MNR| | |<------------| |<------------| |<------------| | +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ Figure 6: REFRESH-RESPONSE Message Flow with MNE_Selection 'ALL' 7.3. Example with MNE_Selection is FIRST_and_LAST The MNI constructs a CONFIGURE message with the required MSPEC objects, and sends it towards the MNR. The message is interpreted by each MNEs on the data path. Each MNE changes its state for this session to 'pending.forward' except MNI itself and MNR, which perform a transition to the state 'pending.participating'. The MNR replies with a positive RESPONSE message. The RESPONSE message is interpreted by each MNE. Each MNE changes the session state to 'metering.forward' except MNR and MNI, which perform a transition to the state 'metering.participating'. +---+ CONFIGURE +---+ CONFIGURE +---+ CONFIGURE +---+ | |------------>| |------------>| |------------>| | |MNI| |MNF| |MNF| |MNR| | |<------------| |<------------| |<------------| | +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ Figure 7: CONFIGURE-RESPONSE Message Flow with MNE_Selection 'FIRST_and_LAST' Similarly, a REFRESH message is initiated by MNI, travels towards the MNR where a RESPONSE is issued and sent back. +---+ REFRESH +---+ REFRESH +---+ REFRESH +---+ | |------------>| |------------>| |------------>| | |MNI| |MNF| |MNF| |MNR| | |<------------| |<------------| |<------------| | +---+ RESPONSE +---+ RESPONSE +---+ RESPONSE +---+ Figure 8: REFRESH-RESPONSE Message Flow with MNE_Selection 'FIRST_and_LAST' Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 29] Internet-Draft Metering NSLP March 2007 7.4. Example with a Route Changes Assume a topology as in Figure 9: +-------+ +-------+ +-------+ +-------+ | MNI |----| MNF1 |-----| MNF2 |----| MNR1 | +-------+ +-------+ | +-------+ +-------+ | | +-------+ +-------+ +-----+ +---| MNF3 |----| MNR2 |----|host | +-------+ +-------+ +-----+ Figure 9: Example with a Route Change' After a route change MNF2 and MNR1 are not on the signaling path anymore. MNF3 is new on the signaling path and receives a REFRESH message with an unknown Session ID. It sends a negative RESPONSE with error code "Unknown Session". MNI receives the negative RESPONSE and re-initiates the signaling with a CONFIGURE message with the same Session ID. When the MNE receives a CONFIGURE message with the same Session ID it re-starts the configuration process: the session is considered as a new session. 8. Bit-Level Formats and Error Messages 8.1. Metering NSLP Messages All Metering NSLP messages start with a common header 'HEADER'. The Metering NSLP common header is similar to the QoS NSLP header. Note that it is not the same as the GIST Common Header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Message Flags | Generic Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: M-NSLP Message Common Header The fields in the common header are as follows: Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 30] Internet-Draft Metering NSLP March 2007 Message Type: 8 bits 1 = CONFIGURE 2 = RESPONSE 3 = NOTIFY Message-specific flags: 8 bits These flags are defined as part of the specification of individual messages. Generic flags: 16 bits There exists currently one generic flag, the Scoping bit (S). The use of the S-bit is described with each message that makes use of it. The set of appropriate flags depends on the particular message being processed. Any bit not defined as a flag for a particular message MUST be set to zero on sending and MUST be ignored on receiving. 8.2. Metering NSLP Objects The Metering NSLP uses the Type-Length-Value (TLV) object format defined by GIST [I-D.ietf-nsis-ntlp]. Every object consists of one or more 32-bit words with a one-word header. For convenience the standard object header is shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|r|r| Type |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: M-NSLP Object Common Header The value for the Type field comes from Metering NSLP object type space, the various objects are presented in subsequent sections. The Length field is given in units of 32 bit words and measures the length of the Value component of the TLV object (i.e., it does not include the standard header). The bits marked 'A' and 'B' are extensibility flags, and used to signal the desired treatment for objects whose treatment has not been defined in the protocol specification (i.e., whose Type field is unknown at the receiver). EDITORIAL NOTE: include text here for the explanation of the meaning Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 31] Internet-Draft Metering NSLP March 2007 of the A and B bits. 8.2.1. MSN Type: MNSLP_MSN Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Message Sequence Number Object 8.2.2. Session_LT Type: MNSLP_Session_LT Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Session Lifetime Object 8.2.3. MNE_Selection Type: MNSLP_MNE_Selection Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Selection of Metering Entities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Selection of Metering Entities Object Possible values are: 1 = ALL 2 = ANY 3 = FIRST 4 = LAST Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 32] Internet-Draft Metering NSLP March 2007 5 = FIRST_and_LAST greater than 1024 : Enterprise Specific EDITORIAL NOTE: it still needs to be defined in the case Enterprise Specific, how MNSLP_SelectionMNEs is encoded. 8.2.4. INFO This object carries the response code, which may be indications for either a successful request or failed request depending on the value of the 'response code' field. Note that the format of this object is similar the INFO object for the NATFW NSLP. Type: MNSLP_INFO Length: 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv. | Class | Response Code | Object Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Information Code Object The field 'Resv.' is reserved for future extensions and MUST be set to zero when generating such an object and MUST be ignored when receiving. The 'Object Type' field contains the type of the object causing the error. The value of 'Object Type' is set to 0, if no object is concerned. The 4 bit class field contains the severity class. The following classes are defined: o 0x1: Informational (NOTIFY only) o 0x2: Success o 0x3: Protocol error o 0x4: Transient failure o 0x5: Permanent failure o 0x6: Signaling session failures EDITORIAL NOTE: Response Codes need to be defined here. 8.2.5. MSPEC Objects Type: Different types are possible. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 33] Internet-Draft Metering NSLP March 2007 * MNSLP_IPFIX_MSPEC * MNSLP_DIAMETER_MSPEC * MNSLP_NETFLOW9 Note that this list is extensible. Length: Variable. 9. Mapping onto M-NSLP Requirements EDITORIAL NOTE: This section needs to be updated. With the design described above, the requirements from [I-D.fessi-nsis-m-nslp-framework] are at this point satisfied as follows: Extensibility: The actual configuration information is encapsulated in the MSPEC. The MSPEC is designed such as it is interpreted by the Metering Manager and can be opaque to the M-NSLP processing. Furthermore, the MSPEC can be easily extended. Therefore, from the point of view of the configuration information, this requirement is fulfilled. Note however, that the Metering NSLP in its current design might show some lack of extensibility. For example, considering the selection of the MNEs, it might be useful for future application of the Metering NSLP to have the option "ANY N", where N is greater than one. Interoperability: Again, whether different metering solutions can interwork depends on how the MSPEC is designed. In QoS NSLP, the QSpec template design [I-D.ietf-nsis-qspec] aims at similar extensibility and interoperability. It needs to be studied whether or not the solutions chosen by the QSpec can also be applied to the MSPEC. Flexible metering models: As above, this is an issue of MSPEC design. Distinguishing flows The aggregation feature detailed in this requirement can be realized as described in Section 4.6. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 34] Internet-Draft Metering NSLP March 2007 Flexible data collection: Another issue that can be fixed in the MSPEC. Location of Metering Entities: MNEs, including MNI and MNR can be located anywhere on the data path. Access parameters of the Collector Information: Access parameters of the Collector Information on how to deliver flow records to the Collector is coded in the MSPEC. Configuration of Metering Entities: The protocol can configure Metering Entities that are MNEs, or that are controlled by MNEs. Selection of Metering Entities: As described in Section 4.4, a MNE should be able to decide to pull out of the metering process. This is realized by the 'Selection of Metering Entities' object. Metering Configuration State installation and removal: By means of the CONFIGURE message, the protocol can install and remove Metering Configuration State. Initiation and maintenance of metering tasks: Triggers and correlation identifier are transported in the MSPEC. Reaction to Route Changes: The protocol detects route changes by a REFRESH or a refreshing CONFIGURE message and installs state along the new route, as described in Section 4.7. Scoping of configuration: The M-NSLP needs to provide sufficient means for flexible scoping signaling messages. Requirements not mentioned in this list are not yet addressed. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 35] Internet-Draft Metering NSLP March 2007 10. Security considerations The process of configuring entities to start and stop metering and to transmit collected resource records to a third party introduces security challenges. An extensive analysis of security issues related to the Metering NSLP is presented in Section 7 of [I-D.fessi-nsis-m-nslp-framework]. Based on this section, future versions of the M-NSLP protocol specification will elaborate the required security mechanisms for the M-NSLP. 11. Open Issues Open issues for the Metering NSLP are discussed here: https://www.ri.uni-tuebingen.de/cgi-bin/roundup.cgi/mnslp/ 12. Acknowledgements The authors would like to thank Robert Hancock, Martin Stiemerling and Andreas Klenk for their valuable input. Furthermore, the authors would like to thank Angie So. By providing the first running prototype of the Metering NSLP, she gave us a helpful feedback for the protocol specification. 13. References 13.1. Normative References [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", draft-ietf-nsis-ntlp-12 (work in progress), March 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 36] Internet-Draft Metering NSLP March 2007 August 1996. 13.2. Informative References [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [I-D.ietf-ipfix-protocol] Claise, B., "Specification of the IPFIX Protocol for the Exchange", draft-ietf-ipfix-protocol-24 (work in progress), November 2006. [I-D.ietf-ipfix-info] Quittek, J., "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-15 (work in progress), February 2007. [I-D.ietf-psamp-sample-tech] Zseby, T., "Sampling and Filtering Techniques for IP Packet Selection", draft-ietf-psamp-sample-tech-07 (work in progress), July 2005. [I-D.ietf-psamp-mib] Dietz, T. and B. Claise, "Definitions of Managed Objects for Packet Sampling", draft-ietf-psamp-mib-06 (work in progress), June 2006. [I-D.ietf-psamp-info] Dietz, T., "Information Model for Packet Sampling Exports", draft-ietf-psamp-info-05 (work in progress), October 2006. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 37] Internet-Draft Metering NSLP March 2007 [I-D.dressler-ipfix-aggregation] Dressler, F., "IPFIX Aggregation", draft-dressler-ipfix-aggregation-03 (work in progress), June 2006. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [I-D.ietf-nsis-qos-nslp] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-12 (work in progress), October 2006. [I-D.ietf-nsis-fw] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07 (work in progress), December 2004. [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in progress), October 2006. [I-D.ietf-nsis-qspec] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-15 (work in progress), February 2007. [I-D.fessi-nsis-m-nslp-framework] Fessi, A., "Framework for Metering NSLP", draft-fessi-nsis-m-nslp-framework-03 (work in progress), June 2006. [I-D.ietf-aaa-diameter-cc] Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. Hakala, "Diameter Credit-control Application", draft-ietf-aaa-diameter-cc-06 (work in progress), August 2004. [3GPP.32.240] 3GPP, "Telecommunication management; Charging management; Charging architecture and principles", 3GPP TS 32.240 6.0.0, September 2004. Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 38] Internet-Draft Metering NSLP March 2007 Authors' Addresses Ali Fessi University of Tuebingen Wilhelm-Schickard-Institute for Computer Science Sand 13 Tuebingen 72072 Germany Phone: +49 7071 29-70576 Email: fessi@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Georg Carle University of Tuebingen Wilhelm-Schickard-Institute for Computer Science Sand 13 Tuebingen 72072 Germany Phone: +49 7071 29-70505 Email: carle@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Falko Dressler University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27914 Email: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/ Juergen Quittek NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 90511-15 Email: quittek@netlab.nec.de URI: http://www.netlab.nec.de/ Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 39] Internet-Draft Metering NSLP March 2007 Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany Phone: +49 30 386-32894 Email: cornelia.kappler@siemens.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 40] Internet-Draft Metering NSLP March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fessi, et al. draft-dressler-nsis-metering-nslp-05.txt [Page 41]