IP Flow Information Export WG G. Muenz Internet-Draft TU Muenchen Intended status: Standards Track B. Claise Expires: April 26, 2010 P. Aitken Cisco Systems, Inc. October 23, 2009 Configuration Data Model for IPFIX and PSAMP Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 1] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices using UML (Unified Modeling Language) class diagrams. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 2] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 6 1.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Structure of the Configuration Data Model . . . . . . . . . . 8 3.1. UML Representation . . . . . . . . . . . . . . . . . . . . 10 3.2. Exporter Configuration . . . . . . . . . . . . . . . . . . 15 3.3. Collector Configuration . . . . . . . . . . . . . . . . . 17 4. Configuration Parameters . . . . . . . . . . . . . . . . . . . 18 4.1. ObservationPoint Class . . . . . . . . . . . . . . . . . . 18 4.2. SelectionProcess Class . . . . . . . . . . . . . . . . . . 19 4.2.1. Selector Class . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Sampler Classes . . . . . . . . . . . . . . . . . . . 21 4.2.3. Filter Classes . . . . . . . . . . . . . . . . . . . . 22 4.3. Cache Class . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.1. CacheLayout Class . . . . . . . . . . . . . . . . . . 25 4.4. ExportingProcess Class . . . . . . . . . . . . . . . . . . 26 4.4.1. Destination Class . . . . . . . . . . . . . . . . . . 27 4.4.2. FileWriter Class . . . . . . . . . . . . . . . . . . . 29 4.4.3. Options Class . . . . . . . . . . . . . . . . . . . . 30 4.5. CollectingProcess Class . . . . . . . . . . . . . . . . . 31 4.5.1. Receiver Class . . . . . . . . . . . . . . . . . . . . 32 4.5.2. FileReader Class . . . . . . . . . . . . . . . . . . . 33 4.6. Transport Layer Security Class . . . . . . . . . . . . . . 33 4.7. Transport Session Class . . . . . . . . . . . . . . . . . 37 4.7.1. Template Class . . . . . . . . . . . . . . . . . . . . 38 5. Adaptation to Device Capabilities . . . . . . . . . . . . . . 39 6. YANG Module of the IPFIX/PSAMP Configuration Data Model . . . 40 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.1. PSAMP Device . . . . . . . . . . . . . . . . . . . . . . . 78 7.2. IPFIX Device . . . . . . . . . . . . . . . . . . . . . . . 81 7.3. Export of Flow Records and Packet Reports . . . . . . . . 84 7.4. Collector and File Writer . . . . . . . . . . . . . . . . 89 7.5. Deviations . . . . . . . . . . . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 91 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 3] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 4] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 1. Introduction IPFIX and PSAMP compliant Monitoring Devices (routers, switches, monitoring probes, Collectors etc.) offer various configuration possibilities that allow adapting network monitoring to the goals and purposes of the application, such as accounting and charging, traffic analysis, performance monitoring, security monitoring. The use of a common vendor-independent configuration data model for IPFIX and PSAMP compliant Monitoring Devices facilitates network management and configuration, especially if Monitoring Devices of different implementers and/or manufacturers are deployed simultaneously. On the one hand, a vendor-independent configuration data model helps storing and managing the configuration data of Monitoring Devices in a consistent format. On the other hand, it can be used for local and remote configuration of Monitoring Devices. However, this requires that Monitoring Devices natively support the configuration data model, or that a mapping between the configuration data model and the device-specific representation of configuration data is provided. The purpose of this document is the specification of a vendor- independent configuration data model that covers the commonly available configuration parameters of Selection Processes, Caches, Exporting Processes, and Collecting Processes. The configuration data model is defined using UML (Unified Modeling Language) class diagrams [UML] while the actual configuration data is encoded in Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML document conforming to the configuration data model contains the configuration data of one Monitoring Device. In order to ensure compatibility with the NETCONF protocol [RFC4741], YANG [I-D.ietf-netmod-yang] is used as the modeling language. If required, the YANG specification of the configuration data model can be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] using the pyang tool [YANG-WEB]. YANG provides mechanisms to adapt the configuration data model to device-specific constraints and to augment the model with additional device-specific or vendor-specific parameters. For the configuration of remote Monitoring Devices, an appropriate protocol is needed to transfer the XML encoded configuration data. The configuration data model is compatible with the NETCONF protocol [RFC4741]. However, alternative protocols, such as the Simple Object Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also suitable for transferring XML data from a network management system to a Monitoring Device. 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]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 5] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 1.1. IPFIX Documents Overview The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], per the requirements defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Processes to IPFIX Collecting Process. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] specifies the IPFIX Management Information Base (IPFIX MIB). Finally, [RFC5472] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. The storage of IPFIX Messages in a file is specified in [I-D.ietf-ipfix-file]. 1.2. PSAMP Documents Overview The framework for packet selection and reporting [RFC5474] enables network elements to select subsets of packets by statistical and other methods, and to export a stream of reports on the selected packets to a Collector. The set of packet selection techniques (Sampling, Filtering, and hashing) standardized by PSAMP are described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collector. Instead of exporting PSAMP Packet Reports, the stream of selected packets may also serve as input to the generation of IPFIX Flow Records. Like IPFIX, PSAMP has a formal description of its Information Elements, their name, type and additional semantic information. The PSAMP information model is defined in [RFC5477]. [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base (PSAMP MIB). 2. Terminology This document adopts the terminologies used in [RFC5101], [I-D.ietf-ipfix-file], and [RFC5476]. As in these documents, all specific terms have the first letter of a word capitalized when used in this document. The following listing indicates in which references the definitions of those terms that are commonly used throughout this document can be found: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 6] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 o Definitions adopted from [RFC5101]: * Collection Process * Collector * Data Record * Exporter * Flow Record * Information Element * IPFIX Device * IPFIX Message * Observation Domain * Observation Point * (Options) Template o Definitions adopted from [I-D.ietf-ipfix-file]: * File Reader * File Writer o Definitions adopted from [RFC5476]: * Filtering * Observed Packet Stream * Packet Report * PSAMP Device * Sampling * Selection Process * Selection Sequence * Selection Sequence Report Interpretation * Selector, Primitive Selector, Composite Selector The terms Metering Process and Exporting Process have different definitions in [RFC5101] and [RFC5476]. In the scope of this document, these terms are used according to the following definitions which cover the deployment in both PSAMP Devices and IPFIX Devices: Metering Process: The Metering Process generates IPFIX Flow Records or PSAMP Packet Reports, depending on its deployment as part of an IPFIX Device or PSAMP Device. Inputs to the process are packets observed at one or multiple Observation Points belonging to a single Observation Domain, as well as characteristics describing the packet treatment at these Observation Points. The function of the Metering Process is split into two types of functional blocks: Selection Processes and Caches. Exporting Process: Depending on its deployment as part of an IPFIX Device or PSAMP Device, the Exporting Process sends IPFIX Flow Records or PSAMP Packet Reports to one or more Collecting Processes. The IPFIX Flow Records or PSAMP Packet Reports are generated by one or more Metering Processes. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 7] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 In addition to the existing IPFIX and PSAMP terminology, the following terms are defined: Cache: The Cache is a functional block in a Metering Process which maintains IPFIX Flow Records or PSAMP Packet Reports. According to [RFC5101], the maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. The maintenance of Packet Reports covers the same set of functions. Cache Layout: The Cache Layout defines the superset of fields that are included in the Packet Reports or Flow Records maintained by the Cache. The fields are specified by the corresponding Information Elements. In general, the largest possible subset of the specified fields is derived for every Packet Report or Flow Record. More specific rules about which fields must be included are given in Section 4.3.1. Cache Mode: The Cache Mode specifies whether Packet Reports or Flow Records are generated by the Cache. In the case of Flow Records, it also specifies the Flow expiration policy. Monitoring Device: A Monitoring Device implements at least one of the functional blocks specified in the context of IPFIX or PSAMP. In particular, the term Monitoring Device encompasses Exporters, Collectors, IPFIX Devices, and PSAMP Devices. Selected Packet Stream: The Selected Packet Stream is the set of all packets selected by a Selection Process. 3. Structure of the Configuration Data Model The IPFIX reference model in [RFC5470] describes Metering Processes, Exporting Processes, and Collecting Processes as functional blocks of IPFIX Devices. The PSAMP framework [RFC5474] provides the corresponding information for PSAMP Devices and introduces Selection Processes as functional blocks within Metering Processes. In Section 2 of the document, the Cache is defined as another functional block within Metering Processes. Further explanations about the relationship between Selection Processes and Caches are given later on in this section. IPFIX File Reader and File Writer are defined as specific kinds of Exporting and Collecting Processes in [I-D.ietf-ipfix-file]. Monitoring Device implementations usually maintain the separation of Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 8] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 various functional blocks although they do not necessarily implement all of them. Furthermore, they provide various configuration possibilities; some of them are specified as mandatory by the IPFIX protocol [RFC5101] or PSAMP protocol [RFC5476]. The configuration data model enables the setting of commonly available configuration parameters for Selection Processes, Caches, Exporting Processes, and Collecting Processes. In addition, it allows specifying the composition of functional blocks within a Monitoring Device configuration and their linkage with Observation Points. In a Monitoring Device implementation, the functionality of the Metering Process is commonly split into packet Sampling and Filtering functions performed by Selection Processes, and the maintenance of Flow Records and Packet Reports performed by Caches. Figure 1 illustrates this separation with the example of a basic Metering Process consisting of one Selection Process and one Cache. +-----------------------------------+ | Metering Process | | +-----------+ Selected | Observed | | Selection | Packet +-------+ | Stream of Packet -->| Process |---------->| Cache |--> Flow Records or Stream | +-----------+ Stream +-------+ | Packet Reports +-----------------------------------+ Figure 1: Selection Process and Cache forming a Metering Process The configuration data model adopts the separation of Selection Processes and Caches in order to support the flexible configuration and combination of these functional blocks. As defined in [RFC5476], the Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output (Selected Packet Stream). The action of the Selection Process on a single packet of its input is defined by a Primitive Selector or a Composite Selector. The Cache generates Flow Records or Packet Reports from the Selected Packet Stream, depending on the configured Cache Mode. The Observed Packet Stream at the input of a Selection Process MUST only contain packets originating from a single Observation Domain. Similarly, the Selected Packet Stream at the input of a Cache MUST only contain packets originating from a single Observation Domain. Packets from Observation Points belonging to different Observation Domains MUST NOT enter the same Selection Process or the same Cache. Beyond the basic Metering Process shown in Figure 1, the configuration data model enables the specification of more complex configurations. A single Cache may process the output of multiple Selection Processes. The Selected Packet Stream may be copied to Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 9] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 enter several Caches, for example one Cache that generates Flow Records and another Cache that generates Packet Reports. Selection Processes can also be cascaded, such that the Selected Packet Stream at the output of one Selection Process is passed to another Selection Process. Cascading Selection Processes can be useful in specific contexts such as the example in Section 7.3. The selection of parameters in the configuration data model is based on configuration issues discussed in the IPFIX and PSAMP documents [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. Furthermore, the structure and content of the IPFIX MIB module [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib] have been taken into consideration. Consistency between the configuration data model and the IPFIX and PSAMP MIB modules is an intended goal. Therefore, parameters in the configuration data model are named according to corresponding managed objects. Certain IPFIX MIB objects containing state data have been adopted as state parameters in the configuration data model. State parameters cannot be configured, yet their values can be queried from the Monitoring Device. The next section explains how UML class diagrams are deployed to illustrate the structure of the configuration data model. Thereafter, Section 3.2 and Section 3.3 explain the class diagrams for the configuration of Exporters and Collectors, respectively. Each of the presented classes contains specific configuration parameters which are specified in Section 4. The formal definition of the configuration data model in YANG is given in Section 6. Section 7 illustrates the usage of the model with example configurations in XML. Section 5 gives a short introduction to YANG concepts that allow adapting the configuration data model to the capabilities of a device. 3.1. UML Representation We use UML class diagrams [UML] to explain the structure of the configuration data model. The attributes of the classes are the configuration or state parameters of the Monitoring Device. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 10] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 +------------------------------------------------+ | Destination | +------------------------------------------------+ | name |<>-----+ | exportMemberType = parallel | | 0..1 | ipfixVersion = 10 | | | transportProtocol | +------------+ | destinationIpAddress | | Transport- | | destinationPort = 4739|4740 | | Layer- | | sendBufferSize {opt.} | | Security | | rateLimit[0..1] | +------------+ | localIpAddress[0..*] {SCTP only} | | timedReliability = 0 {SCTP only} | | numberOfStreams {opt.} {SCTP only} | | sourceIpAddress[0..1] {UDP only} | | templateRefreshTimeout = 600 {UDP only} | | optionsTemplateRefreshTimeout = 600 {UDP only} | | templateRefreshPacket[0..1] {UDP only} | | optionsTemplateRefreshPacket[0..1] {UDP only} | +------------------------------------------------+ Figure 2: UML example: Destination class As an example, Figure 2 shows the UML diagram of the Destination class, which is specified in more detail in Section 4.4.1. The upper box contains the name of the class. The lower box lists the attributes of the class. The only parameters that MUST be configured by the user are name, transportProtocol, and destinationIpAddress. The remaining parameters have either defaults values, specific properties, or a multiplicity indicator starting with zero A default value is indicated after the attribute behind the equality symbol ("="). It means that this default value MUST be used by the Monitoring Device if the parameter is not configured by the user. In the example, IPFIX version 10 must be used if not configured differently. For destinationPort, two default values are indicated, namely the registered ports for IPFIX with and without transport layer security (i.e., DTLS or TLS), respectively. Note that such alternative default values cannot be formally specified in YANG. Instead, they are described in the "description" statement. An attribute with property "{opt.}", such as sendBufferSize in the Destination class, represents a parameter that MAY be configured by the user. Otherwise, the Monitoring Device will assign an appropriate value for this parameter. As a result, the parameter will always exist in the configuration data, yet it is not mandatory for the user to configure it. Note that this property cannot be formally specified in YANG. Instead, it is described in the Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 11] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 "description" statement. The property "{SCTP only}" ("{UDP only}") means that the corresponding parameters are only available if the transport protocol is SCTP (UDP). In YANG, this is formalized in a "when" statement. Another property not shown in the example is "{readOnly}" specifying state parameters which cannot be configured by the user. An attribute with a multiplicity indicator of "[0..1]" represents an OPTIONAL configuration parameter. The parameter is not included in the configuration data unless the user configures it. Typically, the absence of the parameter has a specific meaning. For example, not configuring rateLimit in the Destination class means that no rate limiting will be applied to the exported data. A multiplicity indicator of "[0..*]" means that this parameter MAY be configured multiple times with different values. In the example, multiple local IP addresses may be configured if SCTP is transport protocol. Note that attributes without this multiplicity indicator MUST NOT appear more than once in each object of the class. If some parameters are related to each other, it can make sense to group these parameters in a subclass. This is especially useful if different subclasses represent choices of different parameter sets, or if the parameters of a subclass may appear multiple times. For example, the Destination class MAY contain the parameters of the TransportLayerSecurity subclass. Classes define the structure of the objects of a specific configuration. Objects and their parameters are encoded as XML elements. So, one object of the Destination class corresponds to one occurrence of my-destination ... There are various possibilities how objects of classes can be related to each other. In the scope of this document, we use two different types of relationship between objects: aggregation and unidirectional association. In UML class diagrams, two different arrow types are used as shown in Figure 3. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 12] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 +---+ 0..* +---+ +---+ 0..* 1 +---+ | A |<>------| B | | A |-------->| B | +---+ +---+ +---+ +---+ (a) Aggregation (b) Unidirectional association Figure 3: Class relationships in UML class diagrams Aggregation means that one object is part of the other object. In Figure 3 (a), an object of class B is part of an object of class A. This corresponds to nested XML elements: ... ... Note that we write class names starting with a capital letter throughout this document. The corresponding XML elements use identical names starting with an uncapitalized letter because they represent objects, not classes. A unidirectional association is a reference to an object. In Figure 3 (b), an object of class A contains a reference to an object of class B. This corresponds to separate XML elements that are not nested. To distinguish different objects of class B, class B must have a key. In the configuration data model, all keys are string parameters called "name", corresponding to XML elements . The names must be unique within the XML document. The reference to a specific object of class B is encoded with an XML element which contains the corresponding object name. In the given example, this may look as follows: ... foo ... foo ... In Figure 3, the indicated numbers define the multiplicity: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 13] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 "1": one only "0..*": zero or more "1..*": one or more In the case of aggregation, the multiplicity indicates how many objects of one class may be included in one object of the other class. In Figure 3 (a), an object of class A may contain an arbitrary number of objects of class B. In the case of unidirectional association, the multiplicity at the arrowhead specifies the number of objects of a given class that may be referred to. The multiplicity at the arrow tail specifies how many different objects of one class may refer to a single object of the other class. In Figure 3 (b), an object of class A refers to single object of class B. One object of class B can be referred to from an arbitrary number of objects of class A. Similar to classes that are referenced in UML associations, classes which contain configuration parameters and which occur with multiplicity greater than one in an aggregation relationship must have a key which allows distinguishing different objects. This key is necessary because every configuration parameter must be addressable in order to manipulate or delete it. The values of the key must be unique in the scope of the aggregating object. Hence, under the assumption that class B in Figure 3 (a) contains at least one configuration parameter, all objects of class B belonging to the same object of class A must have different key values. Again, the key appears as an attribute called "name" in all concerned classes. A class which contains state parameters but no configuration parameters, such as the Template class (see Section 4.7.1), does not have a key. This is because state parameters cannot be manipulated or deleted, and therefore do not need to be addressable. Note that the usage of keys as described above is also required by YANG [I-D.ietf-netmod-yang] which mandates the existence of a key for all elements which appear in lists of configuration data. The configuration data model for IPFIX and PSAMP makes use of unidirectional associations to specify the data flow between different functional blocks. For example, if the output of a Selection Process is processed by a Cache, this corresponds to an object of the SelectionProcess class that contains a reference to an object of the Cache class. The configuration data model does not mandate that such a reference exists for every functional block that has an output. If such a reference is absent, the output is dropped without any further processing. Although such configurations are incomplete, we do not consider them as invalid as they may temporarily occur if a Monitoring Device is configured in multiple Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 14] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 steps. Also, it might be useful to pre-configure certain functions of a Monitoring Device in order to be able to switch to a new configuration more quickly. 3.2. Exporter Configuration Figure 4 below shows the main classes of the configuration data model which are involved in the configuration of an IPFIX or PSAMP Exporter. The role of the classes can be briefly summarized as follows: o The ObservationPoint class specifies an Observation Point (i.e., an interface or linecard) of the Monitoring Device at which packets are captured for traffic measurements. An object of the ObservationPoint class may be associated with one or more objects of the SelectionProcess class configuring Selection Processes that process the observed packets in parallel. As long as an ObservationPoint object is specified without any references to SelectionProcess objects, the Observation Point is not deployed for traffic measurements. o The SelectionProcess class contains the configuration parameters of a Selection Process. The Selection Process may be composed of a single Selector or a sequence of Selectors, defining a Primitive or Composite Selector, respectively. The Selection Process selects packets from an Observed Packet Stream originating from one or multiple Observation Points. Therefore, a SelectionProcess object MAY be referred to from multiple ObservationPoint objects. The corresponding Observation Points must belong to the same Observation Domain. A Selection Process MAY pass the Selected Packet Stream to one or multiple Caches. Therefore, the SelectionProcess class enables references to objects of the Cache class. It is possible to cascade different Selection Processes. In this case, the Selected Packet Stream at the output of one or multiple Selection Processes is passed to the input of another Selection Process. Therefore, a SelectionProcess object MAY be referred to from multiple SelectionProcess objects. For the same reason, one SelectionProcess object may refer to other objects of the same class. When cascading multiple Selection Processes, it must be ensured that all packets entering a Selection Process have been observed at Observation Points belonging to the same Observation Domain. A configuration example is given later in Section 7.3. If a Selection Process is configured without any reference to Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 15] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 Selection Processes or Caches that receive the selected packets, the selected packets are not accounted in any Packet Report or Flow Record. o The Cache class contains configuration parameters of a Cache. A Cache may receive the output of one or more Selection Processes and maintains corresponding Packet Reports or Flow Records. Therefore, an object of the Cache class MAY be referred to from multiple SelectionProcess objects. However, the configuration MUST ensure that all packets entering the Selection Process have been observed at Observation Points belonging to the same Observation Domain. Configuration parameters of the Cache class specify the size of the Cache, the Cache Mode and Layout, and expiration parameters. The Cache Mode determines if Packet Reports or Flow Records are generated. A Cache MAY pass its output to one or multiple Exporting Process. Therefore, the Cache class enables references to one or multiple objects of the ExportingProcess class. If a Cache object does not specify any reference to an ExportingProcess object, the Cache output is dropped. o The ExportingProcess class contains configuration parameters of an Exporting Process. It includes various transport protocol specific parameters and the export destinations. An object of the ExportingProcess class MAY be referred to from multiple objects of the Cache class. An Exporting Process MAY be configured as a File Writer according to [I-D.ietf-ipfix-file]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 16] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 +------------------+ | ObservationPoint | +------------------+ 0..* | | 0..* V +------------------+ | SelectionProcess | +------------------+<-+ 0..* | 0..* | | 0..* | +---+ 0..* V +------------------+ | Cache | +------------------+ 0..* | | 0..* V +------------------+ | ExportingProcess | +------------------+ Figure 4: Class diagram of Exporter configuration 3.3. Collector Configuration Figure 5 below shows the main classes of the configuration data model which are involved in the configuration of a Collector. An object of the CollectingProcess class specifies the local IP addresses, transport protocols and port numbers of a Collecting Process. Alternatively, the Collecting Process MAY be configured as a File Reader according to [I-D.ietf-ipfix-file]. An object of the CollectingProcess class may refer to one or multiple ExportingProcess objects configuring Exporting Processes that reexport the received data. As an example, an Exporting Process can be configured as a File Writer in order to save the received IPFIX Messages in a file. +-------------------+ 0..* 0..* +------------------+ | CollectingProcess |----------->| ExportingProcess | +-------------------+ +------------------+ Figure 5: Class diagram of Collector configuration Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 17] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4. Configuration Parameters This section specifies the configuration and state parameters of the configuration data model separately for each class. Parameters serving as keys are depicted in brackets. 4.1. ObservationPoint Class +-------------------------------+ | ObservationPoint | +-------------------------------+ 1 +--------------------+ | name |<>----------| Interface/Linecard | | observationPointId {readOnly} | +--------------------+ | observationDomainId | | | 0..* 0..* +--------------------+ | |----------->| SelectionProcess | +-------------------------------+ +--------------------+ +------------------+ +----------------------------------+ | Interface | | Linecard | +------------------+ +----------------------------------+ | ifIndex/ifName | | entPhysicalIndex/entPhysicalName | | direction = both | | direction = both | +------------------+ +----------------------------------+ Figure 6: ObservationPoint class Figure 6 shows the ObservationPoint class that identifies an Observation Point of the Monitoring Device. The Observation Point can either be an interface or a linecard. An object of the ObservationPoint class MUST specify the ID of the Observation Domain the Observation Point belongs to. Observation Points that are configured with the same Observation Domain ID belong to the same Observation Domain. The Observation Point ID (i.e., the value of the Information Element observationPointId [RFC5102]) is assigned by the Monitoring Device. It appears as a state parameter in the ObservationPoint class. The configuration parameters to identify an interface or a linecard are as follows: ifIndex/ifName (interface only): Either the index or name of the interface MUST be specified according to corresponding objects in the IF-MIB [RFC2863]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 18] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 entPhysicalIndex/entPhysicalName (linecard only): Either the index or name of the linecard MUST be specified according to corresponding objects in the ENTITY-MIB [RFC4133]. direction: This parameter specifies if ingress traffic, egress traffic, or both ingress and egress traffic is captured, using the values "ingress", "egress", and "both", respectively. If not configured, ingress and egress traffic is captured (i.e., the default value is "both"). If not applicable (e.g., in the case of a sniffing interface in promiscuous mode), the value of this parameter is ignored. An ObservationPoint object MAY refer to one or multiple SelectionProcess objects configuring Selection Processes that process the observed packets in parallel. 4.2. SelectionProcess Class +--------------------------------+ | SelectionProcess | +--------------------------------+ 1..* +----------+ | name |<>----------| Selector | | selectionSequenceId {readOnly} | +----------+ | | 0..* | |<---+ | | | | |----+ | | 0..* | | | | 0..* 0..* +----------+ | |----------->| Cache | +--------------------------------+ +----------+ Figure 7: SelectionProcess class Figure 7 shows the SelectionProcess class. The SelectionProcess class contains the configuration parameters of a Selection Process which selects packets from the Observed Packet Stream at its input and outputs the Selected Packet Stream to one or multiple other Selection Processes or Caches. A non-empty ordered list defines a sequence of Selectors. The actions defined by the Selectors are applied to the stream of incoming packet in the specified order. The state parameter selectionSequenceId contains the Selection Sequence ID (i.e., the value of the Information Element selectionSequenceId [RFC5477]) which is assigned by the Monitoring Device. The Selection Sequence ID MUST be unique within the Observation Domain as required by [RFC5477]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 19] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 The output of one Selection Process MAY be processed by other Selection Processes. Therefore, the SelectionProcess class allows references to itself, meaning that one SelectionProcess object MAY refer to other SelectionProcess objects. A SelectionProcess object MAY include references to one or more objects of the Cache class configuring Caches that receive the Selected Packet Stream and generate corresponding Packet Reports or Flow Records. 4.2.1. Selector Class +--------------------------------------+ | Selector | +--------------------------------------+ 1 +-----------------+ | name |<>------+ SelectAll/ | | selectorId {readOnly} | | SampCountBased/ | | packetsObserved {readOnly} | | SampTimeBased/ | | packetsDropped {readOnly} | | SampRandOutOfN/ | | selectorDiscontinuityTime {readOnly} | | SampUniProb/ | | | | FilterMatch/ | | | | FilterHash/ | +--------------------------------------+ +-----------------+ Figure 8: Selector class The Selector class in Figure 8 contains the configuration and state parameters of a Selector. Standardized PSAMP Sampling and Filtering methods are described in [RFC5475]; their configuration parameters are specified in corresponding sampler (SampCountBased, SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch, FilterHash) classes. In addition, the SelectAll class, which has no parameters, is used for a Selector that selects all packets. The Selector class includes exactly one of these sampler and filter classes, depending on the applied method. The state parameter selectorId contains the Selector ID (i.e., the value of the Information Element selectorId [RFC5477]) assigned by the Monitoring Device. The Selector ID MUST be unique within the Observation Domain as required by [RFC5477]. As state parameters, the Selector class contains the Selector statistics packetsObserved and packetsDropped that correspond to the objects of the ipfixSelectorStatsTable in the IPFIX MIB module [I-D.ietf-ipfix-mib]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 20] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.2.2. Sampler Classes +----------------+ +----------------+ +----------------+ | SampCountBased | | SampTimeBased | | SampRandOutOfN | +----------------+ +----------------+ +----------------+ | packetInterval | | timeInterval | | population | | packetSpace | | timeSpace | | size | +----------------+ +----------------+ +----------------+ +----------------+ | SampUniProb | +----------------+ | probability | +----------------+ Figure 9: Sampler classes The Sampler classes in Figure 9 contain the configuration parameters of specific Sampling algorithms: packetInterval, packetSpace: For systematic count-based sampling, packetInterval defines the number of packets that are consecutively sampled between gaps of length packetSpace. These parameters correspond to the Information Elements samplingPacketInterval and samplingPacketSpace [RFC5477]. timeInterval, timeSpace: For systematic time-based sampling, timeInterval defines the time interval during which all arriving packets are sampled. timeSpace is the gap between two sampling intervals. These parameters correspond to the Information Elements samplingTimeInterval and samplingTimeSpace [RFC5477]. The unit is microseconds. size, population: For n-out-of-N random sampling, size defines the number of elements taken from the parent population. population defines the number of elements in the parent population. These parameters correspond to the Information Elements samplingSize and samplingPopulation [RFC5477]. probability: For uniform probabilistic sampling, probability defines the sampling probability. This parameter corresponds to the Information Element samplingProbability [RFC5477]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 21] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.2.3. Filter Classes +--------------------------+ | FilterMatch | +--------------------------+ | ieId/ieName | | ieEnterpriseNumber[0..1] | | value | +--------------------------+ +--------------------------+ | FilterHash | +--------------------------+ 1..* +---------------+ | hashFunction = BOB |<>-------| SelectedRange | | ipPayloadOffset = 0 | +---------------+ | ipPayloadSize = 8 | | name | | digestOutput = false | | min | | initialiserValue[0..1] | | max | +--------------------------+ +---------------+ Figure 10: Filter classes The Filter classes in Figure 10 contain the configuration parameters of specific Filtering methods. For property match filtering, the configuration parameters are: ieId, ieName, ieEnterpriseNumber: The property to be matched is specified by either ieId or ieName, specifying the ID or name of the Information Element, respectively. ieEnterpriseNumber MUST be used for enterprise-specific Information Elements. If ieEnterpriseNumber is omitted or zero, this is Information Element is not enterprise-specific but registered at IANA. value: Matching value. For hash-based filtering, the configuration parameters are: hashFunction: Hash function to be used. The following parameter values are defined by the configuration data model: * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in [RFC5475], Appendix A.1 * CRC: CRC-32 function as specified in [RFC1141] Default value is "BOB". Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 22] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize configure the offset and the size of the payload section used as input to the hash function. Default values are 0 and 8, respectively, corresponding to the minimum configurable values according to [RFC5476], Section 6.2.5.6. These parameters correspond to the Information Elements hashIPPayloadOffset and hashIPPayloadSize [RFC5477]. digestOutput: digestOutput enables or disables the inclusion of the packet digest in the resulting PSAMP Packet Report. This requires that the Cache Layout of the Cache generating the Packet Reports includes a digestHashValue field. This parameter corresponds to the Information Element hashDigestOutput [RFC5477]. initialiserValue: Initializer value to the hash function. This parameter corresponds to the Information Element hashInitialiserValue [RFC5477]. If not configured by the user, the monitoring device arbitrarily chooses an initializer value. One or more ranges of matching hash values are defined by the min and max parameters of the SelectedRange subclass. These parameters correspond to the Information Elements hashSelectedRangeMin and hashSelectedRangeMax [RFC5477]. 4.3. Cache Class +-----------------------------------+ | Cache | +-----------------------------------+ 1 +-------------+ | name |<>----------| CacheLayout | | cacheMode | +-------------+ | maxRecords {opt.} | | activeTimeout {opt.} | 0..* 0..* +------------------+ | {except Cache Mode "immediate"} |----------->| ExportingProcess | | inactiveTimeout {opt.} | +------------------+ | {Cache Mode "timeout" only} | | activeFlows {readOnly} | | inactiveFlows {readOnly} | | cacheDataRecords {readOnly} | | cacheDiscontinuityTime {readOnly} | +-----------------------------------+ Figure 11: Cache class Figure 11 shows the Cache class that contains the configuration and state parameters of a Cache. The configuration parameters of the Cache class are as follows: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 23] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 cacheMode: Configures the Cache Mode. The following parameter values are specified by the configuration data model: * immediate: Data Records expire after the first packet * timeout: Data Records expire after active or inactive timeout * permanent: Data Records never expire, but are periodically exported with interval set by the active timeout In the case of "immediate", PSAMP Packet Reports are generated. Otherwise, IPFIX Flow Records are generated. maxRecords: Maximum number of Data Records in the Cache. If not configured by the user, the Monitoring Device sets this parameter. activeTimeout: This parameter configures the active timeout in milliseconds. It is not available for Cache Mode "immediate". The parameter value zero indicates infinity, meaning that there is no active timeout. If not configured by the user, the Monitoring Device sets this parameter. In the case of Cache Mode "timeout", the active timeout defines the time after which a Flow Record is expired even though packets matching this Flow are still received by the Cache. In the case of Cache Mode "permanent", the active timeout defines the interval for periodical export of Flow Records. inactiveTimeout: This parameter configures the inactive timeout in milliseconds. It is not available for Cache Modes "immediate" and "permanent". The parameter value zero indicates infinity, meaning that there is no inactive timeout. If not configured by the user, the Monitoring Device sets this parameter. The inactive timeout defines the time after which a Flow Record is expired if no packets matching this Flow are received by the Cache. An object of the Cache class includes an object of the CacheLayout class that defines which fields are included in the Packet Reports or Flow Records. A Cache object MAY refer to one or multiple ExportingProcess objects configuring different Exporting Processes. As state parameters, the Cache class contains the Metering Process statistics activeFlows, inactiveFlows, and cacheDataRecords that correspond to the objects of the ipfixMeteringProcessStatsTable of the IPFIX MIB module [I-D.ietf-ipfix-mib]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 24] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.3.1. CacheLayout Class +--------------+ | CacheLayout | +--------------+ 1..* +--------------------------+ | |<>------| CacheField | | | +--------------------------+ | | | name | | | | ieId/ieName | | | | ieLength {opt.} | | | | ieEnterpriseNumber[0..1] | | | | isFlowKey[0..1] | +--------------+ +--------------------------+ Figure 12: CacheLayout class A Cache generates and maintains Packet Reports or Flow Records containing information that has been extracted from the incoming stream of packets. Using the CacheField class, the CacheLayout class specifies the superset of fields that are included in the Packet Reports or Flow Records (see Figure 12). If Packet Reports are generated (i.e., if Cache Mode is "immediate"), every field specified by the Cache Layout MUST be included in the resulting Packet Report unless the corresponding Information Element is not applicable or cannot be derived from the content or treatment of the incoming packet. If Flow Records are generated (i.e., if Cache Mode is "timeout" or "permanent"), every Flow Key field specified by the Cache Layout MUST be included as Flow Key in the resulting Flow Record unless the corresponding Information Element is not applicable or cannot be derived from the content or treatment of the incoming packet. Two packets MUST be accounted by different Flow Records if different subsets of the Flow Key fields are applicable or derivable. Every non-key field specified by the Cache Layout MUST be included in the resulting Flow Record unless the corresponding Information Element is not applicable or cannot be derived for the given Flow. For example, if a non-key field specifies an Information Element whose value is determined by the first packet observed within a Flow (which is the default rule according to [RFC5102]), this field MUST be included in the resulting Flow Record if it can be determined from the first packet of the Flow. The CacheLayout class does not have any parameters. The configuration parameters of the CacheField class are as follows: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 25] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 ieId, ieName, ieEnterpriseNumber: These parameters specify a field by the combination of the Information Element identifier or name, and the Information Element enterprise number. Either ieId or ieName MUST be specified. ieEnterpriseNumber MUST be used for enterprise-specific Information Elements. If ieEnterpriseNumber is omitted or zero, this is Information Element is not enterprise- specific but registered at IANA. ieLength: This parameter specifies the length of the field in octets. A value of 65535 means that the field is encoded as variable-length Information Element. For Information Elements of integer and float type, the field length MAY be set to a smaller value than the standard length of the abstract data type if the rules of reduced size encoding are fulfilled (see [RFC5101], Section 6.2). If not configured by the user, the field length is set by the Monitoring Device. isFlowKey: If present, this field is a Flow Key. 4.4. ExportingProcess Class +--------------------+ | ExportingProcess | +--------------------+ 0..* +------------------+ | name |<>------| Destination | | | +------------------+ | | | | 0..* +------------------+ | |<>------| FileWriter | | | +------------------+ | | | | 0..* +------------------+ | |<>------| Options | | | +------------------+ | | | | 0..* +------------------+ | |<>------| TransportSession | +--------------------+ +------------------+ Figure 13: ExportingProcess class The ExportingProcess class in Figure 13 specifies export destinations and files to which the IPFIX Messages are exported using objects of the Destination class and the FileWriter, respectively. These two classes are described in Section 4.4.1 and Section 4.4.2. If not configured by the user, the Exporting Process ID is assigned by the Monitoring Device. The reporting of specific information with Options Templates is defined with objects of the Options class. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 26] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 As state data, the ExportingProcess class contains the list of Transport Sessions that originate from the Exporting Process. The TransportSession class is specified in Section 4.7. 4.4.1. Destination Class +------------------------------------------------+ | Destination | +------------------------------------------------+ | name |<>-----+ | exportMemberType = parallel | | 0..1 | ipfixVersion = 10 | | | transportProtocol | +------------+ | destinationIpAddress | | Transport- | | destinationPort = 4739|4740 | | Layer- | | sendBufferSize {opt.} | | Security | | rateLimit[0..1] | +------------+ | localIpAddress[0..*] {SCTP only} | | timedReliability = 0 {SCTP only} | | numberOfStreams {opt.} {SCTP only} | | sourceIpAddress[0..1] {UDP only} | | templateRefreshTimeout = 600 {UDP only} | | optionsTemplateRefreshTimeout = 600 {UDP only} | | templateRefreshPacket[0..1] {UDP only} | | optionsTemplateRefreshPacket[0..1] {UDP only} | +------------------------------------------------+ Figure 14: Destination class The Destination class shown in Figure 14 contains the configuration parameters of one export destination (i.e., Collector) the Exporting Process sends IPFIX Messages to. Some of the parameters are only applicable if a specific transport protocol (SCTP, UDP, or TCP) is used. The following parameters apply to all transport protocols: exportMemberType: Configures the export member type that corresponds to the ipfixTransportSessionGroupMemberType object in [I-D.ietf-ipfix-mib]. The following parameter values are specified by the configuration data model: * primary: primary target of the Exporting Process * secondary: secondary target of the Exporting Process used when the primary target is not reachable * parallel: parallel exporting to all destinations and files of the Exporting Process * loadBalancing: load-balancing between different destinations and files of the Exporting Process "parallel" is the default value if this parameter is not configured. If one destination or file is configured as "primary" Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 27] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 target, all other destinations and files must be configured as "secondary" targets. If "parallel" or "loadBalancing" is used, the same type must be configured for all destinations and File Writers of the Exporting Process. ipfixVersion: Version number of the IPFIX protocol used. If omitted, the default value is 10 (=0x000a) as specified in [RFC5101]. transportProtocol: One of "sctp", "udp", and "tcp". destinationIpAddress, destinationPort: Destination IP address and destination port number to be used. destinationIpAddress is a mandatory parameter. If destinationPort is omitted, standard port 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) is used. sendBufferSize: Size of the socket send buffer in bytes. rateLimit: Maximum number of bytes per second the Exporting Process may export to the given destination as required by [RFC5476]. The number of bytes is calculated from the lengths of the IPFIX Messages exported. If this parameter is not configured, no rate limiting is performed for this destination. The following parameters are applicable if SCTP is transport protocol: localIpAddress: This optional parameter MAY appear multiple times to specify the list of eligible local IP addresses of the SCTP association [RFC4960]. If omitted, all locally assigned IP addresses are used by the SCTP endpoint. timedReliability: Lifetime in milliseconds until an IPFIX Message containing Data Sets only is "abandoned" due to the timed reliability mechanism of PR-SCTP [RFC3758]. If this parameter is set to zero, reliable SCTP transport is used. numberOfStreams: Number of outbound streams requested for SCTP associations [RFC4960]. If not configured by the user, this parameter is set by the Monitoring Device. The following parameters are applicable if UDP is transport protocol: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 28] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 sourceIpAddress: This parameter sets the source IP address. If this parameter is omitted, the address assigned to the outgoing interface is used. templateRefreshTimeout, optionsTemplateRefreshTimeout, templateRefreshPacket, optionsTemplateRefreshPacket: Template refresh parameters when using UDP as transport protocol. templateRefreshTimeout and optionsTemplateRefreshTimeout are specified in seconds between resendings of (Options) Templates. If omitted, the default value of 600 seconds (10 minutes) is used [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket are specified in number of IPFIX Messages. If omitted, the (Options) Templates are only resent after timeout. Using the TransportLayerSecurity class, transport layer security is enabled and configured for this export destination. If the transport protocol is SCTP or UDP, transport layer security is realized using DTLS. In the case of TCP, TLS is used instead. 4.4.2. FileWriter Class +-----------------------------+ | FileWriter | +-----------------------------+ | name | | exportMemberType = parallel | | ipfixVersion = 10 | | file | +-----------------------------+ Figure 15: FileWriter classes Instead of exporting IPFIX Messages to remote destinations, the Exporting Process can write them to a file as proposed in [I-D.ietf-ipfix-file]. The FileWriter class contains the configuration parameters for writing the IPFIX Messages to a specific file: exportMemberType: Same parameter as in the Destination class. The File Writers of an Exporting Process belong to the same Transport Session group as any destination configured for the same Exporting Process. ipfixVersion: Version number of the IPFIX protocol used. If omitted, the default value is 10 (=0x000a) as specified in [RFC5101]. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 29] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 file: File name and location specified as URI. 4.4.3. Options Class +-----------------------+ | Options | +-----------------------+ | name | | optionsType | | optionsTimeout {opt.} | +-----------------------+ Figure 16: Options class The Options class in Figure 16 defines the type of specific information to be reported, such as statistics, flow keys, Sampling and Filtering parameters etc. [RFC5101] and [RFC5476] specify several types of reporting information which may be exported. The following parameter values are specified by the configuration data model: meteringStatistics: Export of Metering Process statistics using the Metering Process Statistics Options Template [RFC5101]. meteringReliability: Export of Metering Process reliability statistics using the Metering Process Reliability Statistics Options Template [RFC5101]. exportingReliability: Export of Exporting Process reliability statistics using the Exporting Process Reliability Statistics Options Template [RFC5101]. flowKeys: Export of the Flow Key specification using the Flow Keys Options Template [RFC5101]. selectionSequence: Export of Selection Sequence Report Interpretation and Selector Report Interpretation [RFC5476]. selectionStatistics: Export of Selection Sequence Statistics Report Interpretation [RFC5476]. accuracy: Export of Accuracy Report Interpretation [RFC5476]. reducingRedundancy: Export of common properties according to [RFC5473]. The Exporting Process MUST choose a template definition according to the options type and available options data. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 30] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 The optionsTimeout parameter specifies the reporting interval (in milliseconds) for periodic export of the option data. A parameter value of zero means that the export of the option data is not triggered periodically, but whenever the available option data has changed. This is the typical setting for options types flowKeys, selectionSequence, accuracy, and reducingRedundancy. If optionsTimeout is not configured by the user, it is set by the Monitoring Device. 4.5. CollectingProcess Class +-------------------+ | CollectingProcess | +-------------------+ | name | 0..* +------------------+ | |<>----------| Receiver | | | +------------------+ | | | | 0..* +------------------+ | |<>----------| FileReader | | | +------------------+ | | | | 0..* 0..* +------------------+ | |----------->| ExportingProcess | | | +------------------+ | | | | 0..* +------------------+ | |<>----------| TransportSession | +-------------------+ +------------------+ Figure 17: CollectingProcess class Figure 17 shows the CollectingProcess class that contains the configuration and state parameters of a Collecting Process. Objects of the Receiver class specify how IPFIX Messages are received from remote Exporters. The Collecting Process can also be configured as a File Reader using objects of the FileReader class. As state data, the CollectingProcess class contains the list of Transport Sessions that terminate at the Collecting Process. The TransportSession class is specified in Section 4.7. An CollectingProcess object MAY refer to one or multiple ExportingProcess objects configuring Exporting Processes that export the received data without modifications to a file or to another Collector. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 31] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.5.1. Receiver Class +--------------------------------------+ | Receiver | +--------------------------------------+ 0..1 +------------+ | name |<>------| Transport- | | transportProtocol | | Layer- | | localIpAddress[0..*] | | Security | | localPort = 4739|4740 | +------------+ | maxAllowedStreams {opt.} {SCTP only} | | templateLifetime = 1800 {UDP only} | +--------------------------------------+ Figure 18: Receiver class The Receiver class contains the configuration parameters of a listening socket of the Collecting Process. Some of the parameters are specific to the transport protocol. The parameters are as follows: transportProtocol: One of "sctp", "udp", and "tcp". localIpAddress: Local IP addresses the socket is bound to. If ipAddress is omitted, the socket is bound to all local IP addresses. In the case of SCTP, the local IP addresses correspond to the eligible local IP addresses used by the local SCTP endpoint [RFC4960]. localPort: Local port number. If omitted, standard port 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) is used. maxAllowedStreams (available if transport protocol is SCTP): Maximum number of allowed inbound streams per SCTP association. If not configured by the user, this parameter is set by the Monitoring Device. templateLifetime (available if transport protocol is UDP): Template lifetime if UDP is used as transport protocol. If not configured, the default value 1800 is used, which is three times the default Template refresh timeout (see Section 4.4) as specified in [RFC5101]. Using the TransportLayerSecurity class, transport layer security using DTLS and TLS is enabled and configured for this listening socket of the Collecting Process. If the transport protocol is SCTP or UDP, transport layer security is realized using DTLS. In the case of TCP, TLS is used instead. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 32] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.5.2. FileReader Class +------------+ | FileReader | +------------+ | name | | file | +------------+ Figure 19: FileReader classes The Collecting Process may import IPFIX Messages from a file as proposed in [I-D.ietf-ipfix-file]. The FileReader class defines the configuration parameter: file: File name and location specified as URI. 4.6. Transport Layer Security Class +--------------------------------------+ | TransportLayerSecurity | +--------------------------------------+ | localCertificationAuthorityDN[0..*] | | localSubjectDN[0..*] | | localSubjectFQDN[0..*] | | remoteCertificationAuthorityDN[0..*] | | remoteSubjectDN[0..*] | | remoteSubjectFQDN[0..*] | +--------------------------------------+ Figure 20: TransportLayerSecurity class The TransportLayerSecurity class is used in the Exporting Process's Destination class and the Collecting Process's Receiver class to enable and configure transport layer security for IPFIX. Transport layer security can be enabled without configuring any additional parameters. In this case, an empty XML element appears in the configuration. If transport layer security is enabled, the endpoint must use DTLS [RFC4347] if the transport protocol is SCTP or UDP, and TLS [RFC5246] if the transport protocol is TCP. [RFC5101] mandates strong mutual authentication of Exporting Processes and Collecting Process: "IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 33] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 client and server certificates as in [RFC3280]. To prevent man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS. Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints. The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension is given preference." In order to use transport layer security, appropriate certificates and keys have to be previously installed on the Monitoring Devices. For security reasons, the configuration data model does not offer the possibility to upload any certificates or keys on a Monitoring Device. If transport layer security is enabled on a Monitoring Device which does not dispose of appropriate certificates and keys, the configuration MUST be rejected with an error. The configuration data model allows restricting the authorization of remote endpoints to certificates issued by specific certification authorities or identifying specific fully qualified domain names for authorization. Furthermore, the configuration data model allows restricting the utilization of certificates identifying the local endpoint. This is useful if the Monitoring Device disposes of more than one certificate for the given local endpoint. The configuration parameters are defined as follows: localCertificationAuthorityDN: This parameter MAY appear one or multiple times to restrict the identification of the local endpoint during the TLS/DTLS handshake to certificates issued by the configured certification authorities. Each occurrence of this parameter contains the distinguished name of one certification authority. To identify the local endpoint, the Exporting Process or Collecting Process MUST use a certificate issued by one of the configured certification authority. Certificates issued by any other certification authority MUST NOT be sent to the remote peer Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 34] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 during TLS/DTLS handshake. If none of the certificates installed on the Monitoring Device fulfills the specified restrictions, the configuration MUST be rejected with an error. If localCertificationAuthorityDN is not configured, the choice of certificates identifying the local endpoint is not restricted with respect to the issuing certification authority. localSubjectDN, localSubjectFQDN: Each of these parameters MAY appear one or multiple times to restrict the identification of the local endpoint during the TLS/DTLS handshake to certificates issued for specific subjects or for specific fully qualified domain names. Each occurrence of localSubjectDN contains a distinguished name identifying the local endpoint. Each occurrence of localSubjectFQDN contains a fully qualified domain name which is assigned to the local endpoint. To identify the local endpoint, the Exporting Process or Collecting Process MUST use a certificate that contains either one of the configured distinguished names in the subject field or at least one of the configured fully qualified domain names in a dNSName component of the subject alternative extension field or in the most specific commonName component of the subject field. If none of the certificates installed on the Monitoring Device fulfills the specified restrictions, the configuration MUST be rejected with an error. If any of the parameters localSubjectDN and localSubjectFQDN is configured at the same time as the localCertificationAuthorityDN parameter, certificates MUST also fulfill the specified restrictions regarding the certification authority. If localSubjectDN and localSubjectFQDN are not configured, the choice of certificates identifying the local endpoint is not restricted with respect to the subject's distinguished name or fully qualified domain name. remoteCertificationAuthorityDN: This parameter MAY appear one or multiple times to restrict the authentication of remote endpoints during the TLS/DTLS handshake to certificates issued by the configured certification authorities. Each occurrence of this parameter contains the distinguished name of one certification authority. To authenticate the remote endpoint, the remote Exporting Process or Collecting Process MUST provide a certificate issued by one of the configured certification authority. Certificates issued by any other certification authority MUST be rejected during TLS/DTLS handshake. If the Monitoring Device is not able to validate certificates issued by the configured certification authorities (e.g., because of missing public keys), the configuration must be rejected with an error. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 35] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 If remoteCertificationAuthorityDN is not configured, the authorization of remote endpoints is not restricted with respect to the issuing certification authority of the delivered certificate. remoteSubjectDN, remoteSubjectFQDN: Each of these parameters MAY appear one or multiple times to restrict the authentication of remote endpoints during the TLS/DTLS handshake to certificates issued for specific subjects or for specific fully qualified domain names. Each occurrence of remoteSubjectDN contains a distinguished name identifying a remote endpoint. Each occurrence of remoteSubjectFQDN contains a fully qualified domain name which is assigned to a remote endpoint. To authenticate a remote endpoint, the remote Exporting Process or Collecting Process MUST provide a certificate that contains either one of the configured distinguished names in the subject field or at least one of the configured fully qualified domain names in a dNSName component of the subject alternative extension field or in the most specific commonName component of the subject field. Certificates not fulfilling this condition MUST be rejected during TLS/DTLS handshake. If any of the parameters remoteSubjectDN and remoteSubjectFQDN is configured at the same time as the remoteCertificationAuthorityDN parameter, certificates MUST also fulfill the specified restrictions regarding the certification authority in order to be accepted. If remoteSubjectDN and remoteSubjectFQDN are not configured, the authorization of remote endpoints is not restricted with respect to the subject's distinguished name or fully qualified domain name of the delivered certificate. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 36] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 4.7. Transport Session Class +------------------------------------------------------+ | TransportSession | +------------------------------------------------------+ | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..* | ipfixVersion {readOnly} | | | protocol {readOnly} {except File Reader/Writer} | +----------+ | sourceAddress {readOnly} {except File Reader/Writer} | | Template | | destinationAddress {readOnly} | +----------+ | {except File Reader/Writer} | | sourcePort {readOnly} {except File Reader/Writer} | | destinationPort {readOnly} | | {except File Reader/Writer} | | sctpAssocId {readOnly} {SCTP only} | | file {readOnly} {File Reader/Writer only} | | templateRefreshTimeout {readOnly} {UDP only} | | optionsTemplateRefreshTimeout {readOnly} {UDP only} | | templateRefreshPacket {readOnly} {UDP only} | | optionsTemplateRefreshPacket {readOnly} {UDP only} | | status {readOnly} | | rate {readOnly} | | packets {readOnly} | | bytes {readOnly} | | messages {readOnly} | | discardedMessages {readOnly} | | records {readOnly} | | templates {readOnly} | | optionsTemplates {readOnly} | | transportSessionDiscontinuityTime {readOnly} | +------------------------------------------------------+ Figure 21: TransportSession class The TransportSession class contains state data about Transport Sessions originating from an Exporting Process or terminating at a Collecting Process. The names and semantics of the state parameters correspond to the managed objects in the ipfixTransportSessionTable and ipfixTransportSessionStatsTable of the IPFIX MIB module [I-D.ietf-ipfix-mib]. Hence, if these state parameters are queried from the Monitoring Device, the corresponding IPFIX MIB values can be returned without any further processing. The MIB object ipfixTransportSessionDeviceMode is not included in the TransportSession class because its value can be derived from the scope in which a TransportSession object appears: exporting(1) if it belongs to an Exporting Process, collecting(2) if it belongs to a Collecting Process. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 37] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 The state parameter exportMemberType is only available if the TransportSession class is used within the ExportingProcess class. exportMemberType then contains the value of the MIB object ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB [I-D.ietf-ipfix-mib]. The TransportSession class is also used for state data of File Readers and File Writers. In this case, the "file" parameter specifies the name and location of the file as URI. To avoid ambiguities, the parameters "protocol", "sourceAddress", "destinationAddress", "sourcePort", "destinationPort", and "sctpAssocId" MUST NOT appear if the parameter "file" is present. The parameter "file" MUST NOT appear if at least one of the parameters "protocol", "sourceAddress", "destinationAddress", "sourcePort", "destinationPort", and "sctpAssocId" is present. Note that the parameter "file" is currently not included in the IPFIX MIB. 4.7.1. Template Class +--------------------------------------+ | Template | +--------------------------------------+ | observationDomainId {readOnly} |<>---+ 0..* | templateId {readOnly} | | | setId {readOnly} | | | accessTime {readOnly} | | | templateDataRecords {readOnly} | | | templateDiscontinuityTime {readOnly} | | +--------------------------------------+ | | +-------------------------------+ | Field | +-------------------------------+ | ieId {readOnly} | | ieLength {readOnly} | | ieEnterpriseNumber {readOnly} | | flags {readOnly} | +-------------------------------+ Figure 22: Template class The Template class contains state data about Templates used by an Exporting Process or received by a Collecting Process in a specific Transport Session. The Field class defines one field of the Template. The names and semantics of the state parameters correspond to the managed objects in the ipfixTemplateTable, ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the IPFIX MIB module [I-D.ietf-ipfix-mib]. Hence, if these state Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 38] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 parameters are queried from the Monitoring Device, the corresponding IPFIX MIB values can be returned without any further processing. 5. Adaptation to Device Capabilities The configuration data model standardizes a superset of common IPFIX and PSAMP configuration parameters. A typical Monitoring Device implementation will not support the entire range of possible configurations. Certain functions may not be supported, such as the Collecting Process that does not exist on a Monitoring Device conceived as Exporter only. The configuration of other functions may be subject to resource limitations. For example, the Cache size is typically limited according to the available memory on the device. YANG [I-D.ietf-netmod-yang] offers several possibilities to restrict and adapt a configuration data model. The current version of YANG defines the concepts of "features" and "deviations". The feature concept allows the modeler to make proportions of the model conditional in a manner that is controlled by the device. Devices do not have to support these conditional parts to conform to the model. Those features that are supported by a device must be announced in the message of the NETCONF protocol [RFC4741]. The configuration data model for IPFIX and PSAMP covers the configuration of Exporters, Collectors, and devices that may act as both. As Exporters and Collectors implement different functions, the corresponding proportions of the model are conditional on the following features: exporter: If this feature is supported, Exporting Processes can be configured. collector: If this feature is supported, Collecting Processes can be configured. Exporters do not necessarily implement any Selection Processes, Caches, or even Observation Points in particular cases. Therefore, the corresponding proportions of the model are conditional on the following feature: meter: If this feature is supported, Observation Points, Selection Processes, and Caches can be configured. Additional features refer to different PSAMP Sampling and Filtering methods: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 39] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 psampSampCountBased: If this feature is supported, Sampling method sampCountBased can be configured. psampSampTimeBased: If this feature is supported, Sampling method sampTimeBased can be configured. psampSampRandOutOfN: If this feature is supported, Sampling method sampRandOutOfN can be configured. psampSampUniProb: If this feature is supported, Sampling method sampUniProb can be configured. psampFilterMatch: If this feature is supported, Filtering method filterMatch can be configured. psampFilterHash: If this feature is supported, Filtering method filterHash can be configured. The following features concern the support of UDP and TCP as transport protocols and the support of File Readers and File Writers: udpTransport: If this feature is supported, UDP can be used as transport protocol by Exporting Processes and Collecting Processes. tcpTransport: If this feature is supported, TCP can be used as transport protocol by Exporting Processes and Collecting Processes. fileReader: If this feature is supported, Collecting Processes can be configured as File Readers. fileReader: If this feature is supported, Exporting Processes can be configured as File Writers. The deviation concept enables a device to announce deviations from the standard model. Deviations are typically used to specify limitations due to resource constraints. Deviations concern existing parameters of the standard model and must not be confused with model extensions that are realized with the YANG statement "augment". Just like features, deviations are announced in NETCONF's message. A usage example of deviations is given in Section 7.5. 6. YANG Module of the IPFIX/PSAMP Configuration Data Model The YANG module specification of the configuration data model is listed below. It makes use of common YANG types defined in Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 40] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 [I-D.ietf-netmod-yang-types]. module ietf-ipfix-psamp { namespace "urn:ietf:params:xml:ns:ietf-ipfix-psamp"; prefix ipfix; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IPFIX WG"; contact "muenz@net.in.tum.de"; description "IPFIX/PSAMP Configuration Data Model"; revision 2009-10-23 { description "Version of draft-ietf-ipfix-configuration-model-04 Changes in draft-ietf-ipfix-configuration-model-04: - descriptions and references added in various places, especially for state parameters - enum types cacheMode, exportMemberType, optionsType replaced by identities in order to facilitate the addition of new values using YANG deviations - Selector parameters revised: - parameter names now correspond to Information Element names - single matching value instead of range in filterMatch (which is consistent with Selector Report Interpretation) - filterHash parameters adapted to PSAMP RFCs - sampNonUniProb, sampFlowState, filterRState removed (a Selector Report Interpretation does not exist, yet) - some must statements replaced by choices, which is easier to read - orderedDelivery parameter removed, better add a parameter for activating per-sctp stream later - YANG data type timeticks replaced by uint32 and unit milliseconds - configuration of fields included in an Options Template removed because there is no real use-case - observationPointId, selectionSequenceId, and selectorId are now state parameters (i.e., not configurable any more) because there is no real use-case to configure them - meaning of configuration parameters activeTimeout and inactiveTimeout clarified - several additional must statements enforcing certain configuration restrictions Changes in draft-ietf-ipfix-configuration-model-03: - list of used or received templates now inside transport session container because templates are defined per transport Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 41] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 session - transport session: removed 'index', added missing 'protocol' - exportingProcessId removed - Transport Session state data can be used for File Readers and File Writers - module name changed - Renaming: cacheType => cacheMode, Options' type => optionsType, Destination's/FileWriter's type => exportMemberType, uri => file, optionTemplate => optionsTemplate, optionField => optionsField - transport layer security parameters added to Destination class and Receiver class - must statements ensure that Selection Processes and Caches process packets of a single Observation Domain (as long as Selection Processes are not cascaded) - replaced default value of port by description because the value differs in the case of DTLS/TLS Changes in draft-ietf-ipfix-configuration-model-02: - conformance to draft-ietf-netmod-yang-03 and draft-ietf-netmod-yang-types-01 - canonical form - observationDomainId is now mandatory parameter - usage of YANG features - renamed parameter 'idleTimeout' in 'inactiveTimeout' - state data: Selector statistics, Cache statistics, Templates, Transport Sessions - Exporting Process: new structure of destination, fileWriter - Collecting Process: new structure of receiver, fileReader - more groupings and typedefs - options configured per Exporting Process, not per destination - verified optional parameters, added default values or description clause if necessary Changes in draft-ietf-ipfix-configuration-model-01: - separation of Selectors and Selection Processes as in PSAMP documents - parameter modifications in filterMatch - new rateLimit parameter in destinations of Exporting Process - Cache Type 'normal' now called 'timeout' Changes in draft-ietf-ipfix-configuration-model-00: - Metering Process container replaced by direct reference to Selection Process - meteringProcessId parameter disappears together with the Metering Process container - concatenation of Selection Processes realize Selection Sequence - removal of premature support of Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 42] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 IPFIX Mediators/Concentrators. - more SCTP parameters in SctpReceiver and SctpExport classes - sendBufferSize parameter for all *Export classes - templateId no longer configuration parameter Changes in draft-muenz-ipfix-configuration-04: - first version in yang - Collecting Process can be configured for file import - Collecting Process can be configured to export received records without modifications (e.g., to file or other collectors) - SCTP export parameter timedReliability - parameter for eligible local IP addresses for SCTP endpoint - all tags names uncapitalized, types names etc. capitalized - CacheParameters renamed as Cache - description attribute removed Changes in -03: - Linecard and Interface classes now have direction element - sec => s (SI unit) - optional description attribute for annotations - simplifications in ExportingProcess class - new parameters: observationPointId, meteringProcessId, selectorId, exportingProcessId (note that devices do not have to support the configuration of these parameters) - new FileExport class for exporting into a file - Reporting class renamed Options Class Changes in -02: - new structure without next pointers - packet reporting and flow metering replaced by record cache - added reporting with options"; } /***************************************************************** * Features *****************************************************************/ feature exporter { description "If supported, the Monitoring Device can be used as an Exporter. Exporting Processes can be configured."; } feature collector { description "If supported, the Monitoring Device can be used as a Collector. Collecting Processes can be configured."; } feature meter { description "If supported, Observation Points, Selection Processes, and Caches can be configured."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 43] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } feature psampSampCountBased { description "If supported, the Monitoring Device supports count-based Sampling. The Selector method sampCountBased can be configured."; } feature psampSampTimeBased { description "If supported, the Monitoring Device supports time-based Sampling. The Selector method sampTimeBased can be configured."; } feature psampSampRandOutOfN { description "If supported, the Monitoring Device supports random n-out-of-N Sampling. The Selector method sampRandOutOfN can be configured."; } feature psampSampUniProb { description "If supported, the Monitoring Device supports uniform probabilistic Sampling. The Selector method sampUniProb can be configured."; } feature psampFilterMatch { description "If supported, the Monitoring Device supports property match Filtering. The Selector method filterMatch can be configured."; } feature psampFilterHash { description "If supported, the Monitoring Device supports hash-based Filtering. The Selector method filterHash can be configured."; } feature udpTransport { description "If supported, the Monitoring Device supports UDP as transport protocol."; } feature tcpTransport { description "If supported, the Monitoring Device supports TCP as transport protocol."; } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 44] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 feature fileReader { description "If supported, the Monitoring Device supports the configuration of Collecting Processes as File Readers."; } feature fileWriter { description "If supported, the Monitoring Device supports the configuration of Exporting Processes as File Writers."; } /***************************************************************** * Identities *****************************************************************/ /*** Hash function identities ***/ identity hashFunction { description "Base identity for all hash functions used for hash-based packet filtering. Identities derived from this base are used by the leaf /ipfix/selectionProcess/selector/filterHash/hashFunction."; } identity BOB { base "hashFunction"; description "BOB hash function"; reference "RFC5475, Section 6.2.4.1."; } identity IPSX { base "hashFunction"; description "IPSX hash function"; reference "RFC5475, Section 6.2.4.1."; } identity CRC { base "hashFunction"; description "CRC hash function"; reference "RFC5475, Section 6.2.4.1."; } /*** Cache mode identities ***/ identity cacheMode { description "Base identity for all Cache Modes specifying Flow expiration policies of a Cache. Identities derived from this base are used by the leaf /ipfix/cache/cacheMode."; } identity immediate { base "cacheMode"; description "Flow expiration after the first packet, generation of Packet Records."; } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 45] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 identity timeout { base "cacheMode"; description "Flow expiration after active and inactive timeout, generation of Flow Records."; } identity permanent { base "cacheMode"; description "No flow expiration, periodical export after active timeout, generation of Flow Records."; } /*** Export member type identities ***/ identity exportMemberType { description "Base identity for different usages of an export destination among all destinations of an Exporting Process. It corresponds to ipfixExportMemberType in IPFIX-MIB. Identities derived from this base are used by the leaf /ipfix/exportingProcess/destination/exportMemberType."; reference "draft-ietf-ipfix-mib-08."; } identity primary { base "exportMemberType"; description "Primary target of the Exporting Process. If 'primary' is set for one of the destinations or files of an Exporting Process, the exportMemberType of all other destinations and files of the same Exporting Process MUST be set to 'secondary'."; reference "draft-ietf-ipfix-mib-08."; } identity secondary { base "exportMemberType"; description "Secondary target of the Exporting Process. The Exporting Process will use one of the destinations or files targets specified as 'secondary' when the primary target is not reachable."; reference "draft-ietf-ipfix-mib-08."; } identity parallel { base "exportMemberType"; description "Parallel exporting to all destinations and files of the Exporting Process. 'parallel' MAY only be set simultaneously for all destinations and files of the Exporting Process."; reference "draft-ietf-ipfix-mib-08."; } identity loadBalancing { base "exportMemberType"; description "Load-balancing between the different destinations Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 46] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 and files of the Exporting Process. 'loadBalancing' MAY only be set simultaneously for all destinations and files of the Exporting Process."; reference "draft-ietf-ipfix-mib-08."; } /*** Options type identities ***/ identity optionsType { description "Base identity for report types exported with options. Identities derived from this base are used by the leaf /ipfix/exportingProcess/options/optionsType."; } identity meteringStatistics { base "optionsType"; description "Metering Process Statistics."; reference "RFC 5101, Section 4.1."; } identity meteringReliability { base "optionsType"; description "Metering Process Reliability Statistics."; reference "RFC 5101, Section 4.2."; } identity exportingReliability { base "optionsType"; description "Exporting Process Reliability Statistics."; reference "RFC 5101, Section 4.3."; } identity flowKeys { base "optionsType"; description "Flow Keys."; reference "RFC 5101, Section 4.4."; } identity selectionSequence { base "optionsType"; description "Selection Sequence and Selector Reports."; reference "RFC5476, Sections 6.5.1 and 6.5.2."; } identity selectionStatistics { base "optionsType"; description "Selection Sequence Statistics Report."; reference "RFC5476, Sections 6.5.3."; } identity accuracy { base "optionsType"; description "Accuracy Report."; reference "RFC5476, Section 6.5.4."; } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 47] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 identity reducingRedundancy { base "optionsType"; description "Application of ipfix-reducing-redundancy."; reference "RFC5473."; } /***************************************************************** * Type definitions *****************************************************************/ typedef direction { type enumeration { enum ingress { description "This value is used for monitoring incoming packets."; } enum egress { description "This value is used for monitoring outgoing packets."; } enum both { description "This value is used for monitoring incoming and outgoing packets."; } } description "Direction of packets going through an interface or linecard."; } typedef transportSessionStatus { type enumeration { enum inactive { description "This value MUST be used for Transport Sessions that are specified in the system but currently not active. The value can be used for Transport Sessions that are backup (secondary) sessions."; } enum active { description "This value MUST be used for Transport Sessions that are currently active and transmitting or receiving data."; } enum unknown { description "This value MUST be used if the status of the Transport Sessions cannot be detected by the device. This value should be avoided as far as possible."; } } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 48] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Status of a Transport Session."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionStatus)."; } typedef ipfixTransportProtocol { type enumeration { enum sctp; enum udp { description "only applicable if the feature udpTransport is supported"; } enum tcp { description "only applicable if the feature tcpTransport is supported"; } } description "Transport protocols of IPFIX."; reference "RFC5101."; } typedef templateFieldFlags { type bits { bit scope { position 0; description "This Information Element is used for scope."; } bit flowKey { position 1; description "This Information Element is a Flow Key."; } } description "Bitmask containing the attributes of a field in a Template. Possible values: 0: The Information Element is neither used for scoping nor as Flow Key. 1: The Information Element is used for scoping. 2: The Information Element is used as Flow Key. 3: This combination is not allowed."; reference "RFC5101, draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDefinitionFlags)."; } /***************************************************************** * Groupings *****************************************************************/ grouping interfaceParameters { Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 49] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Interface as input to Observation Point."; choice indexOrName { mandatory true; description "Index or name of the interface as stored in the ifTable of IF-MIB."; reference "RFC 1229."; leaf ifIndex { type uint32; } leaf ifName { type string; } } leaf direction { type direction; default both; description "Direction of packets. If not applicable (e.g., in the case of a sniffing interface in promiscuous mode), this parameter is ignored."; } } grouping linecardParameters { description "Linecard as input to Observation Point."; choice indexOrName { mandatory true; description "Index or name of the linecard as stored in the entPhysicalTable of ENTITY-MIB."; reference "RFC 4133."; leaf entPhysicalIndex { type uint32; } leaf entPhysicalName { type string; } } leaf direction { type direction; default both; description "Direction of packets. If not applicable (e.g., in the case of a sniffing interface in promiscuous mode), this parameter is ignored."; } } grouping selectorParameters { description "Configuration and state parameters of a Selector."; choice Method { mandatory true; description "Packet selection method applied by the Selector."; leaf selectAll { type empty; description "Method which selects all packets."; } container sampCountBased { if-feature psampSampCountBased; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 50] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "This container contains the configuration parameters of a Selector applying systematic count-based packet sampling to the packet stream."; reference "RFC5475, Section 5.1; RFC5476, Section 6.5.2.1."; leaf packetInterval { type uint32; units packets; mandatory true; description "The number of packets that are consecutively sampled between gaps of length packetSpace. This parameter corresponds to the Information Element samplingPacketInterval."; reference "RFC5477, Section 8.2.2."; } leaf packetSpace { type uint32; units packets; mandatory true; description "The number of unsampled packets between two sampling intervals. This parameter corresponds to the Information Element samplingPacketSpace."; reference "RFC5477, Section 8.2.3."; } } container sampTimeBased { if-feature psampSampTimeBased; description "This container contains the configuration parameters of a Selector applying systematic time-based packet sampling to the packet stream."; reference "RFC5475, Section 5.1; RFC5476, Section 6.5.2.2."; leaf timeInterval { type uint32; units microseconds; mandatory true; description "The time interval in microseconds during which all arriving packets are sampled between gaps of length timeSpace. This parameter corresponds to the Information Element samplingTimeInterval."; reference "RFC5477, Section 8.2.4."; } leaf timeSpace { type uint32; units microseconds; mandatory true; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 51] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "The time interval in microseconds during which no packets are sampled between two sampling intervals specified by timeInterval. This parameter corresponds to the Information Element samplingTimeInterval."; reference "RFC5477, Section 8.2.5."; } } container sampRandOutOfN { if-feature psampSampRandOutOfN; description "This container contains the configuration parameters of a Selector applying n-out-of-N packet sampling to the packet stream."; reference "RFC5475, Section 5.2.1; RFC5476, Section 6.5.2.3."; leaf size { type uint32; units packets; mandatory true; description "The number of elements taken from the parent population. This parameter corresponds to the Information Element samplingSize."; reference "RFC5477, Section 8.2.6."; } leaf population { type uint32; units packets; mandatory true; description "The number of elements in the parent population. This parameter corresponds to the Information Element samplingPopulation."; reference "RFC5477, Section 8.2.7."; } } container sampUniProb { if-feature psampSampUniProb; description "This container contains the configuration parameters of a Selector applying uniform probabilistic packet sampling (with equal probability per packet) to the packet stream."; reference "RFC5475, Section 5.2.2.1; RFC5476, Section 6.5.2.4."; leaf probability { type decimal64 { fraction-digits 18; range "0..1"; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 52] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } mandatory true; description "Probability that a packet is sampled, expressed as a value between 0 and 1. The probability is equal for every packet. This parameter corresponds to the Information Element samplingProbability."; reference "RFC5477, Section 8.2.8."; } } container filterMatch { if-feature psampFilterMatch; description "This container contains the configuration parameters of a Selector applying property match filtering to the packet stream."; reference "RFC5475, Section 6.1; RFC5476, Section 6.5.2.5."; choice nameOrId { mandatory true; description "The field to be matched is specified by either the name or the ID of the Information Element."; leaf ieName { type string; description "Name of the Information Element."; } leaf ieId { type uint16; description "ID of the Information Element."; } } leaf ieEnterpriseNumber { type uint32; description "If present, the Information Element is enterprise-specific. The field value configures the enterprise number. If omitted or zero, the Information Element is not enterprise-specific but registered at IANA."; } leaf value { type string; mandatory true; description "Matching value of the Information Element."; } } container filterHash { if-feature psampFilterHash; description "This container contains the configuration Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 53] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 parameters of a Selector applying hash-based filtering to the packet stream."; reference "RFC5475, Section 6.2; RFC5476, Section 6.5.2.6."; leaf hashFunction { type identityref { base "hashFunction"; } default BOB; description "Hash function to be applied. According to RFC5475, Section 6.2.4.1, 'BOB' must be used in order to be compliant with PSAMP."; } leaf ipPayloadOffset { type uint64; units octets; default 0; description "IP payload offset indicating the position of the first payload byte considered as input to the hash function. Default value 0 corresponds to the minimum offset that must be configurable according to RFC5476, Section 6.2.5.6. This parameter corresponds to the Information Element hashIPPayloadOffset."; reference "RFC5477, Section 8.3.2."; } leaf ipPayloadSize { type uint64; units octets; default 8; description "Number of IP payload bytes used as input to the hash function, counted from the payload offset. If the IP payload is shorter than the payload range, all available payload octets are used as input. Default value 8 corresponds to the minimum IP payload size that must be configurable according to RFC5476, Section 6.2.5.6. This parameter corresponds to the Information Element hashIPPayloadSize."; reference "RFC5477, Section 8.3.3."; } leaf digestOutput { type boolean; default false; description "If true, the output from this Selector is included in the Packet Report as a packet digest. Therefore, the configured Cache Layout needs to contain Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 54] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 a digestHashValue field. This parameter corresponds to the Information Element hashDigestOutput."; reference "RFC5477, Section 8.3.8."; } leaf initialiserValue { type uint64; description "Initializer value to the hash function. If not configured by the user, the Monitoring Device arbitrarily chooses an initializer value."; reference "RFC5477, Section 8.3.9."; } list selectedRange { key name; min-elements 1; leaf name { type string; } leaf min { type uint64; description "Beginning of the hash function's selected range. This parameter corresponds to the Information Element hashSelectedRangeMin."; reference "RFC5477, Section 8.3.6."; } leaf max { type uint64; description "End of the hash function's selected range. This parameter corresponds to the Information Element hashSelectedRangeMax."; reference "RFC5477, Section 8.3.7."; } } } } leaf packetsObserved { type yang:counter64; config false; description "The number of packets observed at the input of the Selector. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of selectorDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixSelectorStatsPacketsObserved)."; } leaf packetsDropped { type yang:counter64; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 55] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 config false; description "The number of packets discarded by the Selector. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of selectorDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixSelectorStatsPacketsDropped)."; } leaf selectorDiscontinuityTime { type yang:date-and-time; config false; description "The value of sysUpTime at the most recent occasion at which one or more of the Selector counters suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixSelectionProcessStatsDiscontinuityTime)."; } } grouping cacheLayoutParameters { description "Fields of a Cache Layout."; list cacheField { key name; min-elements 1; leaf name { type string; } choice nameOrId { mandatory true; description "Name or ID of the Information Element."; reference "RFC5102."; leaf ieName { type string; } leaf ieId { type uint16; } } leaf ieLength { type uint16; units octets; description "Length of the field in which the Information Element is encoded. A value of 65535 specifies a variable-length Information Element. For Information Elements of integer and float type, the field length MAY be set to a smaller value than the standard length of the abstract data type if the rules of reduced size encoding are fulfilled. If not configured by the user, this parameter is set by the Monitoring Device."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 56] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 reference "RFC5101, Section 6.2; RFC5102."; } leaf ieEnterpriseNumber { type uint32; description "If present, the Information Element is enterprise-specific. The field value configures the enterprise number. If omitted or zero, the Information Element is not enterprise-specific but registered at IANA."; reference "RFC5101; RFC5102."; } leaf isFlowKey { type empty; description "If present, this is a flow key."; } } } grouping destinationParameters { description "Parameters specifying an export destination."; leaf exportMemberType { type identityref { base "exportMemberType"; } default parallel; description "Member type within the Transport Session group which is composed of all destinations and fileWriters of the Exporting Process."; } leaf ipfixVersion { type int16; default 10; description "IPFIX version number."; } leaf transportProtocol { type ipfixTransportProtocol; mandatory true; } leaf destinationIpAddress { type inet:ip-address; mandatory true; } leaf destinationPort { type inet:port-number; description "If not configured by the user, the Monitoring Device uses the default port number for IPFIX, which is 4739 without transport layer security and 4740 if transport layer security is activated."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 57] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } leaf sendBufferSize { type uint32; units bytes; description "Size of the socket send buffer. If not configured by the user, this parameter is set by the Monitoring Device."; } leaf rateLimit { type uint32; units "bytes per second"; description "Maximum number of bytes per second the Exporting Process may export to the given destination. The number of bytes is calculated from the lengths of the IPFIX Messages exported. If not configured, no rate limiting is performed."; reference "RFC5476, Section 6.3."; } choice protocolSpecificParameters { case sctp { when "transportProtocol='sctp'"; leaf-list localIpAddress { type inet:ip-address; description "List of eligible local IP addresses to be used by the SCTP endpoint. If not configured, all locally assigned IP addresses are used by the local endpoint."; reference "RFC 3758; RFC 4960."; } leaf timedReliability { type uint32; units milliseconds; default 0; description "PR-SCTP lifetime for IPFIX Messages containing Data Sets only. Zero means reliable transport."; reference "RFC 3758; RFC 4960."; } leaf numberOfStreams { type uint16; description "Number of outbound streams requested for the SCTP association. If not configured by the user, this parameter is set by the Monitoring Device."; reference "RFC 3758; RFC 4960."; } } case udp { when "transportProtocol='udp'"; leaf sourceIpAddress { type inet:ip-address; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 58] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Sets source IP address if UDP is transport protocol. If not configured, the IP address assigned to the outgoing interface is used."; } leaf templateRefreshTimeout { type uint32; units seconds; default 600; description "Sets time after which Templates are resent if UDP is transport protocol."; reference "RFC5101."; } leaf optionsTemplateRefreshTimeout { type uint32; units seconds; default 600; description "Sets time after which Options Templates are resent if UDP is transport protocol."; reference "RFC5101."; } leaf templateRefreshPacket { type uint32; units "IPFIX Messages"; description "Sets number of IPFIX Messages after which Templates are resent if UDP is transport protocol. If omitted, Templates are only resent after timeout."; reference "RFC5101."; } leaf optionsTemplateRefreshPacket { type uint32; units "IPFIX Messages"; description "Sets number of IPFIX Messages after which Options Templates are resent if UDP is transport protocol. If omitted, Templates are only resent after timeout."; reference "RFC5101."; } } } container transportLayerSecurity { presence "If transportLayerSecurity is present, DTLS is enabled if the transport protocol is SCTP or UDP, and TLS is enabled if the transport protocol is TCP."; uses transportLayerSecurityParameters; } } grouping optionsParameters { Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 59] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Parameters specifying the data export using an Options Template."; leaf optionsType { type identityref { base "optionsType"; } mandatory true; } leaf optionsTimeout { type uint32; units milliseconds; description "Time interval for periodic export of the options data. If set to zero, the export is triggered when the options data has changed. If not configured by the user, this parameter is set by the Monitoring Device."; } } grouping receiverParameters { leaf transportProtocol { type ipfixTransportProtocol; mandatory true; } leaf-list localIpAddress { type inet:ip-address; description "List of local IP addresses on which the Collecting Process listens for IPFIX Messages. If not configured, all locally assigned IP addresses are used. In the case of SCTP, these IP addresses correspond to the eligible local IP addresses to be used by the SCTP endpoint."; reference "RFC 4960."; } leaf localPort { type inet:port-number; description "If not configured, the Monitoring Device uses the default port number for IPFIX, which is 4739 without transport layer security and 4740 if transport layer security is activated."; } choice protocolSpecificParameters { case sctp { when "transportProtocol='sctp'"; leaf maxAllowedStreams { type uint16; description "Maximum number of allowed inbound streams per SCTP association. If not configured by the user, this parameter is set by Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 60] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 the Monitoring Device."; } } case udp { when "transportProtocol='udp'"; leaf templateLifetime { type uint32; units seconds; default 1800; description "Template lifetime if UDP is transport protocol."; reference "RFC5101, Section 10.3.7."; } } } container transportLayerSecurity { presence "If transportLayerSecurity is present, DTLS is enabled if the transport protocol is SCTP or UDP, and TLS is enabled if the transport protocol is TCP."; uses transportLayerSecurityParameters; } } grouping fileWriterParameters { description "File Writer parameters."; leaf exportMemberType { type identityref { base "exportMemberType"; } default parallel; description "Member type within the Transport Session group which is composed of all destinations and fileWriters of the Exporting Process."; } leaf ipfixVersion { type int16; default 10; description "IPFIX version number."; } leaf file { type inet:uri; mandatory true; description "URI specifying the location of the file."; } } grouping fileReaderParameters { description "File Reader parameters."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 61] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 leaf file { type inet:uri; mandatory true; description "URI specifying the location of the file."; } } grouping transportLayerSecurityParameters { description "Transport layer security parameters."; leaf-list localCertificationAuthorityDN { type string; description "Distinguished names of certification authorities whose certificates may be used to identify the local endpoint."; } leaf-list localSubjectDN { type string; description "Distinguished names which may be used in the certificates to identify the local endpoint."; } leaf-list localSubjectFQDN { type inet:domain-name; description "Fully qualified domain names which may be used to in the certificates to identify the local endpoint."; } leaf-list remoteCertificationAuthorityDN { type string; description "Distinguished names of certification authorities whose certificates are accepted to authorize remote endpoints."; } leaf-list remoteSubjectDN { type string; description "Distinguished names which are accepted in certificates to authorize remote endpoints."; } leaf-list remoteSubjectFQDN { type inet:domain-name; description "Fully qualified domain name which are accepted in certificates to authorize remote endpoints."; } } grouping templateParameters { description "State parameters of a Template used by an Exporting Process or received by a Collecting Process in a specific Transport Session. Parameter names and semantics correspond to the managed objects in IPFIX-MIB"; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 62] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 reference "RFC5101; draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateEntry, ipfixTemplateDefinitionEntry, ipfixTemplateStatsEntry)"; leaf observationDomainId { type uint32; description "The ID of the Observation Domain for which this Template is defined."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateObservationDomainId)."; } leaf templateId { type uint16; description "This number indicates the Template Id in the IPFIX message. Values from 0 to 255 are not allowed for Template Ids."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateId)."; } leaf setId { type uint16; description "This number indicates the Set ID of the Template. Currently, there are two values defined. The value 2 is used for Sets containing Template definitions. The value 3 is used for Sets containing Options Template definitions."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateSetId)."; } leaf accessTime { type yang:date-and-time; description "Used for Exporting Processes, this parameter contains the time when this (Options) Template was last sent to the Collector(s). Used for Collecting Processes, this parameter contains the time when this (Options) Template was last received from the Exporter."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateAccessTime)."; } leaf templateDataRecords { type yang:counter64; description "The number of transmitted or received Data Records defined by this (Options) Template. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of templateDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDataRecords)."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 63] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } leaf templateDiscontinuityTime { type yang:date-and-time; description "The value of sysUpTime at the most recent occasion at which templateDataRecords suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDiscontinuityTime)."; } list field { description "This list contains the (Options) Template fields of which the (Options) Template is defined. The order of the list corresponds to the order of the fields in the (Option) Template Record."; leaf ieId { type uint16; description "This parameter indicates the Information Element Id of the field."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDefinitionIeId); RFC5102."; } leaf ieLength { type uint16; units octets; description "This parameter indicates the length of the Information Element of the field."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDefinitionIeLength); RFC5102."; } leaf ieEnterpriseNumber { type uint32; description "This parameter indicates the IANA enterprise number of the authority defining the Information Element Id. If the Information Element is not enterprise-specific, this parameter is omitted or zero."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDefinitionIeEnterpriseNumber)."; } leaf flags { type templateFieldFlags; description "This parameter indicates special attributes of the field."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTemplateDefinitionFlags)."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 64] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } } } grouping transportSessionParameters { description "State parameters of a Transport Session originating from an Exporting or terminating at a Collecting Process. Parameter names and semantics correspond to the managed objects in IPFIX-MIB. The additional file parameter, which does not exist in IPFIX-MIB, allows describing a Transport Session terminating or originating in a file."; reference "RFC5101, draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionEntry, ipfixTransportSessionStatsEntry, ipfixExportEntry)"; leaf ipfixVersion { type int16; description "Used for Exporting Processes, this parameter contains the version number of the IPFIX Protocol that the Exporter uses to export its data in this Transport Session. Used for Collecting Processes, this parameter contains the version number of the IPFIX Protocol it receives for this Transport Session."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionIpfixVersion)."; } choice transportOrFile { description "If the Transport Session terminates or originates in a file, the location of the file is specified instead of transport protocol, addresses, ports etc."; case transport { leaf protocol { type int32; description "The transport protocol used for receiving or transmitting IPFIX Messages. Protocol numbers are assigned by IANA. A current list of all assignments is available from ."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionProtocol)."; } leaf sourceAddress { type inet:ip-address; description "The source address of the Exporter of the IPFIX Transport Session. This parameter is used with protocols (specified in protocol) like TCP(6) and UDP(17) that have the notion of addresses. SCTP(132) should use sctpAssocId instead. If SCTP(132) or any other protocol without the notion of addresses is used, this parameter is omitted."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 65] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionSourceAddressType, ipfixTransportSessionSourceAddress)."; } leaf destinationAddress { type inet:ip-address; description "The destination address of the Collector of the IPFIX Transport Session. This parameter is used with protocols (specified in protocol) like TCP(6) and UDP(17) that have the notion of addresses. SCTP(132) should use sctpAssocId instead. If SCTP(132) or any other protocol without the notion of addresses is used, this parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionDestinationAddressType, ipfixTransportSessionDestinationAddress)."; } leaf sourcePort { type inet:port-number; description "The transport protocol port number of the Exporter of the IPFIX Transport Session."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionSourcePort)."; } leaf destinationPort { type inet:port-number; description "The transport protocol port number of the Collector of the IPFIX Transport Session."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionDestinationPort)."; } leaf sctpAssocId { when "../protocol = 132"; type uint32; description "The association id used for the SCTP session between the Exporter and the Collector of the IPFIX Transport Session. It is equal to the sctpAssocId entry in the sctpAssocTable defined in the SCTP-MIB. This parameter is only used if protocol has the value 132 (SCTP). In all other cases, the parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionSctpAssocId), RFC3871"; } leaf templateRefreshTimeout { when "../protocol = 17"; type uint32; units seconds; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 66] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Used for Exporting Processes, this parameter contains the time in seconds after which Templates MUST be resent by the Exporter. Used for Collecting Processes, this parameter contains the lifetime in seconds after which a Template becomes invalid when it is not received again within this lifetime. This parameter is only used if protocol has the value 17 (UDP). In all other cases, the parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionTemplateRefreshTimeout)."; } leaf optionsTemplateRefreshTimeout { when "../protocol = 17"; type uint32; units seconds; description "Used for Exporting Processes, this parameter contains the time in seconds after which Options Templates MUST be resent by the Exporter. Used for Collecting Processes, this parameter contains the lifetime in seconds after which a Template becomes invalid when it is not received again within this lifetime. This parameter is only used if protocol has the value 17 (UDP). In all other cases, the parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionOptionsTemplateRefreshTimeout)."; } leaf templateRefreshPacket { when "../protocol = 17"; type uint32; units "IPFIX Messages"; description "Used for Exporting Processes, this parameter contains the number of exported IPFIX Messages after which Templates MUST be resent by the Exporter. Used on Collecting Processes, this parameter contains the lifetime in number of exported IPFIX Messages after which an Template becomes invalid when it is not received again within this lifetime. This parameter is only used if protocol has the value 17 (UDP). In all other cases, the parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionTemplateRefreshPacket)."; } leaf optionsTemplateRefreshPacket { when "../protocol = 17"; type uint32; units "IPFIX Messages"; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 67] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "Used for Exporting Processes, this parameter contains the number of exported IPFIX Messages after which Options Templates MUST be resent by the Exporter. Used on Collecting Processes, this parameter contains the lifetime in number of exported IPFIX Messages after which an Option Template becomes invalid when it is not received again within this lifetime. This parameter is only used if protocol has the value 17 (UDP). In all other cases, the parameter is omitted."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionOptionsTemplateRefreshPacket)."; } } case file { leaf file { type inet:uri; description "URI specifying the location of the file when this Transport Session is originating from or terminating in a file."; } } } leaf status { type transportSessionStatus; description "Status of the Transport Session."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionStatus)."; } leaf rate { type int32; units "bytes per second"; description "The number of bytes per second transmitted by the Exporting Process or received by the Collecting Process. This parameter is updated every second."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionRate)."; } leaf packets { type yang:counter64; units packets; description "The number of packets transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionPackets)."; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 68] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } leaf bytes { type yang:counter64; units bytes; description "The number of bytes transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionBytes)."; } leaf messages { type yang:counter64; units "IPFIX Messages"; description "The number of messages transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionMessages)."; } leaf discardedMessages { type yang:counter64; units "IPFIX Messages"; description "Used for Exporting Processes, this parameter indicates the number of messages that could not be sent due to internal buffer overflows, network congestion, routing issues, etc. Used for Collecting Process, this parameter indicates the number of received IPFIX Message that are malformed, cannot be decoded, are received in the wrong order or are missing according to the sequence number. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionDiscardedMessages)."; } leaf records { type yang:counter64; units "Data Records"; description "The number of Data Records transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 69] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionRecords)."; } leaf templates { type yang:counter32; units "Templates"; description "The number of Templates transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionTemplates)."; } leaf optionsTemplates { type yang:counter32; units "Options Templates"; description "The number of Option Templates transmitted by the Exporting Process or received by the Collecting Process. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of transportSessionDiscontinuityTime."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionOptionsTemplates)."; } leaf transportSessionDiscontinuityTime { type yang:date-and-time; description "The value of sysUpTime at the most recent occasion at which one or more of the Transport Session counters suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixTransportSessionDiscontinuityTime)."; } list template { description "This list contains the Templates and Options Templates that are transmitted by the Exporting Process or received by the Collecting Process. Withdrawn or invalidated (Options) Template Exporter MUST be removed from this list."; uses templateParameters; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 70] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 } } /***************************************************************** * Main container *****************************************************************/ container ipfix { list collectingProcess { if-feature collector; key name; description "Parameters of a Collecting Process."; leaf name { type string; } list receiver { key name; description "List of receivers (sockets) on which the Collecting Process receives IPFIX Messages."; leaf name { type string; } uses receiverParameters; } list fileReader { if-feature fileReader; key name; description "List of File Readers from which the Collecting Process reads IPFIX Messages."; leaf name { type string; } uses fileReaderParameters; } leaf-list exportingProcess { type leafref { path "/ipfix/exportingProcess/name"; } description "Export of received records without any modifications. Records are processed by all Exporting Processes in the list."; } list transportSession { config false; description "This list contains the currently established Transport Sessions terminating at this Collecting Process."; uses transportSessionParameters; } } list observationPoint { if-feature meter; key name; description "Parameters of an Observation Point."; leaf name { type string; } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 71] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 leaf observationPointId { type uint32; config false; description "Observation Point ID (i.e., the value of the Information Element observationPointId) assigned by the Monitoring Device."; reference "RFC5102, Section 5.1.10."; } leaf observationDomainId { type uint32; mandatory true; description "The Observation Domain ID associates the Observation Point to an Observation Domain. Observation Points with identical Observation Domain ID belong to the same Observation Domain."; reference "RFC5101."; } choice OPType { mandatory true; container interface { uses interfaceParameters; } container linecard { uses linecardParameters; } } leaf-list selectionProcess { type leafref { path "/ipfix/selectionProcess/name"; } description "Selection Processes in this list process packets in parallel."; } } list selectionProcess { if-feature meter; must "not( /ipfix/observationPoint[selectionProcess = current()/name] /observationDomainId[1] != /ipfix/observationPoint[selectionProcess = current()/name] /observationDomainId ) and count(/ipfix/selectionProcess[name = /ipfix/observationPoint[observationDomainId = /ipfix/observationPoint[selectionProcess = current()/name]/observationDomainId]/selectionProcess] [selectionSequenceId = current()/selectionSequenceId]) = 1)" { description "If the input of this Selection Process is an Observed Packet Stream originating from different Observation Points, the first part of the must statement Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 72] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 ensures that all Observation Points belong to the same Observation Domain. The second part of the must statement ensures that the Selection Sequence ID is unique within the Observation Domain. The must statement verifies these conditions correctly for Selection Processes whose input originates from Observation Points only. The conditions are not verified if the input originates from other Selection Processes because XPath does not allow specifying this in a simple way."; } key name; description "Parameters of a Selection Process."; leaf name { type string; } leaf selectionSequenceId { type uint64; config false; description "The Selection Sequence ID is assigned by the Monitoring Device. It must be unique within the Observation Domain."; reference "RFC5477."; } list selector { key name; unique "selectorId"; min-elements 1; ordered-by user; description "List of Selectors that define the action of the Selection Process on a single packet. The Selectors are serially invoked in the same order as they appear in this list."; leaf name { type string; } leaf selectorId { type uint16; config false; description "The Selector ID is assigned by the Monitoring Device. It must be unique within the Observation Domain."; reference "RFC5477."; } uses selectorParameters; } leaf-list selectionProcess { type leafref { path "/ipfix/selectionProcess/name"; } description "Selection Processes in this list receive the selected packets in parallel."; } Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 73] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 leaf-list cache { type leafref { path "/ipfix/cache/name"; } description "Caches in this list receive the selected packets in parallel."; } } list cache { if-feature meter; must "not( /ipfix/observationPoint[selectionProcess = /ipfix/selectionProcess[cache = current()/name]/name] /observationDomainId[1] != /ipfix/observationPoint[selectionProcess = /ipfix/selectionProcess[cache = current()/name]/name] /observationDomainId )" { description "For configurations where there are no cascaded Selection Processes between Observation Points and this Cache, the must statement ensures that all Observation Points belong to the same Observation Domain. Note that this must statement does not ensure that cascaded Selection Processes between the Observation Points and this Cache process packets from a single Observation Domain."; } key name; description "Parameters of a Cache."; leaf name { type string; } leaf cacheMode { type identityref { base "cacheMode"; } mandatory true; } leaf maxRecords { type uint32; description "Maximum number of Data Records in the Cache. If not configured by the user, this parameter is set by the Monitoring Device."; } leaf activeTimeout { when "not(../cacheMode = 'immediate')"; type uint32; units milliseconds; description "This parameter configures the active timeout. The parameter value zero indicates infinity, meaning that Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 74] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 there is no active timeout. In the case of Cache Mode 'timeout', the active timeout defines the time after which a Flow Record is expired even though packets matching this Flow are still received by the Cache. In the case of Cache Mode 'permanent', the active timeout defines the interval for periodical export of Flow Records. If not configured by the user, the Monitoring Device sets this parameter."; } leaf inactiveTimeout { when "not( ../cacheMode = 'immediate' or ../cacheMode = 'permanent' )"; type uint32; units milliseconds; description "This parameter configures the inactive timeout in milliseconds. The parameter value zero indicates infinity, meaning that there is no inactive timeout. The inactive timeout defines the time after which a Flow Record is expired if no packets matching this Flow are received by the Cache. If not configured by the user, the Monitoring Device sets this parameter."; } container cacheLayout { description "Definition of the Cache Layout."; uses cacheLayoutParameters; } leaf-list exportingProcess { type leafref { path "/ipfix/exportingProcess/name"; } description "Records are exported by all Exporting Processes in the list."; } leaf activeFlows { type uint32; units flows; config false; description "The number of Flows currently active in this cache."; reference "ietf-draft-ipfix-mib-08, Section 8 (ipfixMeteringProcessCacheActiveFlows)."; } leaf inactiveFlows { type uint32; units flows; config false; Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 75] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 description "The number of Flows currently inactive in this cache."; reference "ietf-draft-ipfix-mib-08, Section 8 (ipfixMeteringProcessCacheInactiveFlows)."; } leaf cacheDataRecords { type yang:counter64; units "Data Records"; config false; description "The number of Data Records generated by this Cache. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of templateDiscontinuityTime."; reference "ietf-draft-ipfix-mib-08, Section 8 (ipfixMeteringProcessDataRecords)."; } leaf cacheDiscontinuityTime { type yang:date-and-time; config false; description "The value of sysUpTime at the most recent occasion at which cacheDataRecords suffered a discontinuity. A value of zero indicates no such discontinuity has occurred since the last re-initialization of the local management subsystem."; reference "ietf-draft-ipfix-mib-08, Section 8 (ipfixMeteringProcessDiscontinuityTime)."; } } list exportingProcess { if-feature exporter; must "not( (current()/destination/exportMemberType = 'parallel' or current()/fileWriter/exportMemberType = 'parallel') and (current()/destination/exportMemberType != 'parallel' or current()/fileWriter/exportMemberType != 'parallel') ) and not( (current()/destination/exportMemberType = 'loadBalancing' or current()/fileWriter/exportMemberType = 'loadBalancing') and Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 76] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 (current()/destination/exportMemberType != 'loadBalancing' or current()/fileWriter/exportMemberType != 'loadBalancing') ) and not( count(current()/destination/exportMemberType = 'primary') + count(current()/fileWriter/exportMemberType = 'primary') > 1 ) " { description "This must statement ensures that the following: - If one exportMemberType parameter is set to 'parallel' or 'loadBalancing, all exportMemberType parameters of the Exporting Process are set to the same value. - A maximum of one destination or file can be configured with exportMemberType set to 'primary'."; } key name; description "Parameters of an Exporting Process."; leaf name { type string; } list destination { key name; leaf name { type string; } uses destinationParameters; } list fileWriter { if-feature fileWriter; key name; leaf name { type string; } uses fileWriterParameters; } list options { key name; leaf name { type string; } uses optionsParameters; } list transportSession { config false; description "This list contains the currently established Transport Sessions originating from this Exporting Process."; leaf exportMemberType { type uint16; description "This parameter indicates the member type of this Transport Session within the Transport Session group originating from the Exporting Process. The following values are currently defined in IPFIX-MIB: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 77] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 unknown(0): This value MUST be used if the status of the group membership cannot be detected by the equipment. This value should be avoided as far as possible. primary(1): This value is used for a group member that is used as the primary target of an Exporting Process. Other group members of the same Exporting or Collecting Process MUST NOT have the value primary(1) but MUST have the value secondary(2). secondary(2) This value is used for a group member that is used as a secondary target of an Exporting Process. The Exporting Process will use one of the targets specified as secondary(2) within the same Transport Session group when the primary target is not reachable. parallel(3) This value is used for a group member that is used for duplicate exporting. The Exporting Process is exporting the same Data Records in parallel to all group members in parallel. This implies that all group members MUST have the same membertype parallel(3). loadBalancing(4) This value is used for a group member that is used as one target for load-balancing. This means that a Data Record is sent to one of the group members in this group. This implies that all group members MUST have the same membertype load-balancing(4)."; reference "draft-ietf-ipfix-mib-08, Section 8 (ipfixExportMemberType)."; } uses transportSessionParameters; } } } } 7. Examples This section shows example configurations conforming to the YANG module specified in Section 6. 7.1. PSAMP Device This configuration example contains two Selection Processes configured for the same Observation Point. The first Selection Process implements two Selectors: a filter for UDP packets and a Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 78] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 random sampler. The second Selection Process implements an ICMP filter. The outputs of both Selection Processes enter the same Cache. The Cache Mode is "immediate" resulting in the creation of a PSAMP Packet Report for every selected packet. The associated Exporting Process exports to one Collector using PR- SCTP and DTLS. The transport layer security parameters specify that the collector must supply a certificate for the fully qualified domain name collector.example.net. Valid certificates from any certification authority will be accepted. As the destination transport port is omitted, the standard IPFIX-over-DTLS port 4740 is used. Exporting Process reliability statistics are reported every five minutes. OP at linecard 3 1 12345 3 Sampled UDP packets ICMP packets Sampled UDP packets 1 UDP filter 1 4 17 10-out-of-100 sampler 2 10 100 PSAMP cache Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 79] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 ICMP packets 2 ICMP filter 3 4 1 PSAMP cache PSAMP cache immediate 512 Field 1 313 64 Field 2 154 The only exporter The only exporter PR-SCTP collector primary sctp 192.0.2.1 1000000 500 1 collector.example.net Options 1 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 80] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 exportingReliability 300000 7.2. IPFIX Device This configuration example demonstrates the shared usage of a Cache for maintaining Flow Records from two different Observation Points. Packets are selected using different Sampling techniques: count-based Sampling for the first Observation Point and selection of all packets for the second Observation Point. Note that both Observation Points belong to the same Observation Domain, as required. The Exporting Process sends the Flow Records to a primary destination using SCTP. A UDP Collector is specified as secondary destination. Exporting Process reliability statistics [RFC5101] are exported periodically every minute (60000 milliseconds). Selection Sequence Report Interpretation and Selector Report Interpretation [RFC5476] are exported once after configuration of the Selection Processes has been made. OP at eth0 (ingress) 123 eth0 ingress Count-based packet selection OP at eth1 123 eth1 All packet selection Count-based packet selection Count-based sampler Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 81] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 1 99 Flow cache All packet selection Select all Flow cache Flow cache timeout 4096 5000 10000 Field 1 sourceIPv4Address Field 2 destinationIPv4Address Field 3 transportProtocol Field 4 sourceTransportPort Field 5 destinationTransportPort Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 82] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 Field 6 flowStartMilliSeconds Field 7 flowEndSeconds Field 8 octetDeltaCount Field 9 packetDeltaCount SCTP export with UDP backup SCTP export with UDP backup SCTP destination primary sctp 192.0.2.1 4739 UDP destination secondary udp 192.0.2.2 4739 300 300 Options 1 selectionSequence 0 Options 2 exportingReliability 60000 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 83] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 7.3. Export of Flow Records and Packet Reports This configuration example demonstrates the combined export of Flow Records and Packet Reports for a single Observation Point. A Selection Process (Selection Sequence ID = 1) applies random Sampling to the stream of observed packets. The output is passed to a Cache generating Flow Records. In parallel, the output is passed to a second Selection Process (Selection Sequence ID = 2) which discards all non-ICMP packets. A second Cache generates Packet Reports of the retained ICMP packets. The output of both caches is exported to a single Collector using SCTP. OP at linecard 3 9876 4 ingress Sampling Sampling 1 Random sampler 1 0.01 ICMP Flow cache ICMP 2 ICMP filter Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 84] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 2 4 1 Packet cache Flow cache timeout 4096 5 10 Field 1 sourceIPv4Address Field 2 destinationIPv4Address Field 6 flowStartMilliSeconds Field 7 flowEndSeconds Field 8 octetDeltaCount Field 9 packetDeltaCount Export Packet cache Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 85] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 immediate 512 Field 1 313 64 Field 2 154 Export Export SCTP collector sctp 192.0.2.1 0 2 The Observed Packet Stream at the input of the Selection Process "ICMP" originates from the Selection Process "Sampling", which thus constitutes a pseudo Observation Point. In order to inform the Collector about the cascaded Selection Processes, the Exporting Process exports two Selection Sequence Report Interpretations as defined in [RFC5476], section 6.5.1, including the following fields: Selection Process "Sampling": Scope: selectionSequenceId = 1 Non-scope: ingressInterface = 4 selectorId = 1 Selection Process "ICMP": Scope: selectionSequenceId = 2 Non-scope: selectionSequenceId = 1 selectorId = 2 Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 86] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 One possibility to link the Selection Sequence Report Interpretation of Selection Process "Sampling" to the Flow Record generated by the Cache named "Flow cache" is to include a field selectionSequenceId = 1 to each Data Record. Similarly, the Selection Sequence Report Interpretation of Selection Process "ICMP" can be linked to the Packet Reports generated by the Cache named "Packet cache" by including a field selectionSequenceId = 2 to each Data Record. The following modifications lead to a similar but not identical configuration of the Monitoring Device: Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 87] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 ... OP at linecard 3 3 Sampling Sampled ICMP packets ... Sampling Random sampler 0.01 Flow cache Sampled ICMP packets Random sampler 0.01 ICMP filter 4 1 Packet cache ... In this case, the random sampler is implemented in two different Selection Processes, leading to different sets of selected packets. As a consequence, the set of packets accounted in the Flow Cache is not identical to the set of packets from which the ICMP Packet Reports are generated. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 88] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 7.4. Collector and File Writer This configuration example configures a Collector which writes the received data to a file. SCTP collector Listening port 4739 sctp 192.0.2.1 4739 64 File writer File writer Write to /tmp folder primary file://tmp/collected-records.ipfix 7.5. Deviations Assume that a Monitoring Device does not support the configuration of Observation Domain ID and Observation Point ID. It supports a single Observation Domain with ID=1 to which two interfaces can be assigned. The Observation Point ID is identical to the ifIndex. Linecards are not installed. The following YANG module specifies these deviations. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 89] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 module my-ipfix-psamp-deviation { namespace "urn:my-company:xml:ns:ietf-ipfix-psamp"; prefix my; import ietf-ipfix-psamp { prefix ipfix; } deviation /ipfix:ipfix/ipfix:observationPoint/ipfix:OPType/ipfix:linecard { deviate not-supported; } deviation /ipfix:ipfix/ipfix:observationPoint { deviate add { must "ipfix:observationDomainId=1"; } deviate add { must "ipfix:interface/ipfix:ifIndex=1 or ipfix:interface/ipfix:ifIndex=2"; } } deviation /ipfix:ipfix/ipfix:observationPoint/ipfix:observationPointId { deviate add { must "current()=../ipfix:interface/ipfix:ifIndex"; } } } 8. Security Considerations The IPFIX/PSAMP configuration data model does not introduce security issues. Configuration data encoded according to the configuration data model may contain sensitive information. Therefore, if configuration data is transmitted, the underlying protocol must apply appropriate procedures to guarantee the integrity and confidentiality of the data. Particularly, if the NETCONF protocol is used to configure Monitoring Devices, the security considerations of the NETCONF protocol apply [RFC4741]. 9. IANA Considerations This document has no actions for IANA. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 90] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 Appendix A. Acknowledgements The authors thank Martin Bjorklund, Andy Bierman, and Ladislav Lhotka for helping specifying the configuration data model in YANG. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009. [I-D.ietf-netmod-yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-ietf-netmod-yang-08 (work in progress), October 2009. [I-D.ietf-netmod-yang-types] Schoenwaelder, J., "Common YANG Data Types", draft-ietf-netmod-yang-types-03 (work in progress), May 2009. [UML] "OMG Unified Modeling Language (OMG UML), Superstructure, V2.2", OMG formal/2009-02-02, February 2009. 10.2. Informative References [W3C.REC-xml-20040204] Yergeau, F., Maler, E., Sperberg-McQueen, C., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204, February 2004, Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 91] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 . [W3C.REC-xmlschema-0-20041028] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, . [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [W3C.REC-soap12-part1-20070427] Karmarkar, A., Nielsen, H., Hadley, M., Mendelsohn, N., Lafon, Y., Moreau, J., and M. Gudgin, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, . [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. [I-D.ietf-ipfix-mib] Dietz, T., Kobayashi, A., and B. Claise, "Definitions of Managed Objects for IP Flow Information Export", draft-ietf-ipfix-mib-07 (work in progress), July 2009. [I-D.ietf-ipfix-file] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IPFIX File Format", draft-ietf-ipfix-file-05 (work in progress), August 2009. [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 92] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009. [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. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [YANG-WEB] Bjoerklund, M., "YANG WebHome", Homepage http://www.yang-central.org, March 2009. Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 93] Internet-Draft IPFIX/PSAMP Configuration Data Model October 2009 Authors' Addresses Gerhard Muenz Technische Universitaet Muenchen Department of Informatics Chair for Network Architectures and Services (I8) Boltzmannstr. 3 Garching D-85748 Germany Phone: +49 89 289-18008 Email: muenz@net.in.tum.de URI: http://www.net.in.tum.de/~muenz Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh EH6 6LX United Kingdom Phone: +44 131 561 3616 Email: paitken@cisco.com Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page 94]