IP Flow Information Export WG G. Muenz Internet-Draft University of Tuebingen Intended status: Standards Track B. Claise Expires:May 22,August 23, 2008 Cisco Systems, Inc.November 19, 2007February 20, 2008 Configuration Data Model for IPFIX and PSAMP<draft-muenz-ipfix-configuration-03><draft-muenz-ipfix-configuration-04> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onMay 22,August 23, 2008. Copyright Notice Copyright (C) The IETF Trust(2007).(2008). Abstract This document specifies a data model for the configuration of metering processes, exporting processes, and collecting processes for IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language(XML), according(XML). The structure of the data model is specified as a YANG module to ensure compatibility with the Netconf protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definitionpresented in this document.of the data model. Table of Contents 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 4 2.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . .54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Structure of the Configuration Data Model . . . . . . . . . . 5 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 9 5.1. ObservationPoint Class . . . . . . . . . . . . . . . . . . 10 5.2. MeteringProcess Class . . . . . . . . . . . . . . . . . . 11 5.3. SelectionProcess Class . . . . . . . . . . . . . . . . . .1211 5.3.1. Sampler Classes . . . . . . . . . . . . . . . . . . .1312 5.3.2. Filter Classes . . . . . . . . . . . . . . . . . . . .1312 5.4.CacheParametersCache Class . . . . . . . . . . . . . . . . . .14. . . . . 13 5.4.1. Template Class . . . . . . . . . . . . . . . . . . . .1513 5.5. ExportingProcess Class . . . . . . . . . . . . . . . . . .1614 5.5.1. Destination Class . . . . . . . . . . . . . . . . . .1615 5.5.2. Export Parameters Classes . . . . . . . . . . . . . .1715 5.5.3. Option Class . . . . . . . . . . . . . . . . . . . . .1817 5.5.4. OptionTemplate Class . . . . . . . . . . . . . . . . .1918 5.6. CollectingProcess Class and Receiver Class . . . . . . . . 19 6.XML Schema Specification . . . . . . . . . . . . . . . .YANG Module of the IPFIX/PSAMP Configuration Data Model . . . 20 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .3332 7.1. PSAMP Monitoring Device . . . . . . . . . . . . . . . . .3332 7.2. IPFIX Monitoring Device . . . . . . . . . . . . . . . . . 35 7.3. Collector Monitoring Device . . . . . . . . . . . . . . . 38 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . .3839 9.1. Normative References . . . . . . . . . . . . . . . . . . .3839 9.2. Informative References . . . . . . . . . . . . . . . . . .3940 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .4142 Intellectual Property and Copyright Statements . . . . . . . . . .4243 1. Open IssuesGeneral issues: o Find a consensus of common configuration parameters.All open issues have been addressed. Solved issues and answers to reviewer comments: oWhatSCTP timed reliability parameter configures lifetime before an IPFIX Message isthe relationship to the Netconf protocol? Recommend Netconf as preferred configuration protocol? Make it mandatory? Netconf related issues:"abandoned". o Netconfcompliance? o Extend model for reporting device capabilities, error messages etc.? Specific issues: o Which are the common SCTP specific export parameters?compliance: ensured by using YANG instead of XSD. oAllow only "ingress" and "egress" for directionDirection attribute oflinecard and interface? o Check if current configuration data model is inline with PSAMP viewinterface/linecard can be on ofSelection Process, Selection Sequence, Selector etc. Solved issues and answers to reviewer comments:"ingress", "egress", or "both". o observationPointId, meteringProcessId, exportingProcessId, and selectorId have been added as optional configuration parameters, setting the values of the corresponding Information Elements. Note that monitoring device implementations are not obliged to support the configuration of these ids, but may set them dynamically. Currently not included is selectionSequenceId. o Request for additional parameters concerning the composition of IPFIXmessagesMessages at the exporter, e.g. how long may the exporter wait until an expired record is exported? Waiting may be useful in order to fill up IPFIXmessages.Messages. We (the authors) decided not to add such parameters for the following reasons: 1) the composition of IPFIXmessagesMessages has not been described as configurable or managable in any other IPFIX document, and 2) today's configuration possibilities depend very much on the device or manufacturer. We propose to use device or manufacturer-dependent extensions of the configuration data model. 2. Introduction IPFIX and PSAMP compliant monitoring devices (routers, switches, monitoring probes, mediators, collectors etc.) offer various configuration possibilities that allow adapting network monitoring to the goals and purposes of the application, e.g. accounting and charging, traffic analysis, performance monitoring, security monitoring etc. The use of a common device-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 device-independent configuration data model helps storing and managing the configuration data of monitoring devices in a consistent format. On the other hand, it can also 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. An appropriate transport protocol is needed in the case of remote configuration. The purpose of this document is the specification of a device- independent configuration data model that covers the commonly available configuration parameters of Metering Processes, Exporting Processes, and Collecting Processes. The data model isspecifiedencoded in Extensible Markup Language (XML)[W3C.REC-xml-20040204] using XML Schema language [W3C.REC-xmlschema-0-20041028].[W3C.REC-xml-20040204]. An XML document conforming tothis XML Schema Definitionthe configuration data model contains the configuration data of oneor multiplemonitoringdevices. The usage of XML enables easy extensiondevice. In order to ensure compatibility with the Netconf protocol [RFC4741], YANG [I-D.bjorklund-netconf-yang] is used as modeling language. If required, the YANG specification of the configuration data modelwith additional device-specific parameters. Furthermore, optional parameters not supported by a particular monitoring device implementationcan besimply omitted in theconverted into using XMLdocument. However, for the creation and manipulation of configuration data for a specific monitoring device, any restrictions and extensions ofSchema language [W3C.REC-xmlschema-0-20041028] using thedata model should be known. This ispyang tool [YANG-WEB]. YANG provides mechanisms toavoidaugment thegeneration of unsupportedconfiguration dataand to profit from extended device capabilities. Note that the description of monitoring device capabilities is currently out of scope of this document.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.There are various candidate protocols, likeThe configuration data model is compatible with theNetwork Configuration Protocol (Netconf) [RFC4741] orNetconf protocol [RFC4741]. However, alternative protocols, such as the Simple Object Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427],thatare also suitable for transferring XML data from a network management system to a monitoring device.However, the current specification of the configuration data model is not specific to any of these.2.1. IPFIX Documents Overview The IPFIX protocol[I-D.ietf-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 [I-D.ietf-ipfix-architecture], per the requirements defined in [RFC3917]. This document 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[I-D.ietf-ipfix-info].[RFC5102]. [I-D.ietf-ipfix-mib] specifies the IPFIX Management Information Base. Finally [I-D.ietf-ipfix-as] 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. 2.2. PSAMP Documents Overview The document "A Framework for Packet Selection and Reporting" [I-D.ietf-psamp-framework] describes the PSAMP framework for 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) supported by PSAMP are described in "Sampling and Filtering Techniques for IP Packet Selection" [I-D.ietf-psamp-sample-tech]. The PSAMP protocol [I-D.ietf-psamp-protocol] specifies the export of packet information from a PSAMP exporting process to a PSAMP collecting process. 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 [I-D.ietf-psamp-info]. Finally [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base. 3. Terminology This document adopts the terminologies used in[I-D.ietf-ipfix-protocol][RFC5101] and [I-D.ietf-psamp-protocol]. As in[I-D.ietf-ipfix-protocol],[RFC5101], these specific terms have the first letter of a word capitalized when used in this document.[TODO: copy terminology section]4. Structure of the Configuration Data Model The IPFIX reference model in [I-D.ietf-ipfix-architecture] specifies the role and function of Metering Processes, Exporting Processes, and Collecting Processes. In [I-D.ietf-psamp-framework], the corresponding information is specified for the PSAMP architecture. IPFIX and PSAMP compliant monitoring device implementations usually maintain the separation of Metering Processes, Exporting Processes, and Collecting Processes (although they do not necessarily implement all of them). Furthermore, they provide various configuration possibilities; some of them arerequiredspecified as mandatory by the IPFIX protocol[I-D.ietf-ipfix-protocol].[RFC5101]. The configuration data model enables the setting of commonly available configuration parameters for Metering Processes, Exporting Processes, and Collecting Processes. In addition, it allows specifying the composition of Metering Processes, Exporting Processes, and Collecting Processes within a monitoring device configuration. The selection of commonly available configuration parameters is based on configuration issues discussed in the IPFIX and PSAMP documents [RFC3917],[I-D.ietf-ipfix-protocol],[RFC5101], [I-D.ietf-ipfix-architecture], [I-D.ietf-psamp-protocol], [I-D.ietf-psamp-framework], and [I-D.ietf-psamp-sample-tech]. 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] were 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. In the following, we use Unified Modeling Language (UML) class diagrams to explain the structure of the configuration data model. According to UML, different arrow types are used to distinguish two different types of relationship between UML classes: aggregation and association. +---+ 0..* +---+ +---+ 0..* +---+ | A |<>------| B | | A |------->| B | +---+ +---+ +---+ +---+ (a) Aggregation (b) Unidirectional association Aggregation means that one class is part of theother, e.g.other. As an example, class B is part of class A in example (a). An association is a reference to an instance of another class. In example (b), class A contains a reference to an instance of class B. The indicated numbers define the multiplicity: "1": one only "0..*": zero or more "1..*": one or more Inorder to identify a specific instance, aUML class diagrams, all classes that occur with multiplicity greater than one in an aggregation relationship, and all classes that are referenced in associations must have a key which allows distinguishing different instances of the class. This key must beidentifiable by an identifier, i.e.unique within the given scope. Regarding example (a), all instances of class Bin example (b)belonging to the same instance of class A mustbe identifiable. Inhave keys; theconfiguration data model, identifiers are string attributes named "id". These "id" attributes are not displayed inscope is local to theUMLgiven instance of classdiagrams. Arbitrary annotationsA. In example (b), all instance of class B must have unique keys as they can beassigned to the main classesreferenced by multiple instances of class A (i.e., thedata model using string attributes named "description". Valuesscope is global). In YANG, there exists a corresponding rule which mandates the existence ofthis attribute have no effect ona key for all elements which appear in lists [I-D.bjorklund-netconf-yang]. In the configurationand purely serve to provide some context information todata model, the(human) reader.key is a string parameter called "name" for all classes. Figure 1 shows the main classes the configuration data model. The role of the classes can be briefly summarized as follows: o The ObservationPoint classidentifiesspecifies an Observation Point (e.g. interface) of the monitoring device which is used for traffic monitoring. Furthermore, itspecifiesconfigures Metering Processes that process the observed packets. o The MeteringProcess class represents a Metering Process. A Metering Process requires a record cache which is represented by an instance of theCacheParametersCache class. In order to enable the usage ofathe same record cachewithinin multiple Metering Processes, the MeteringProcess class contains only a reference to an instance of theCacheParametersCache class. Note that the usage of the samerecordcache implies that the Template defining the record format is identical for the corresponding Metering Processes.Similarly,Additionally, the MeteringProcess class contains optional references to instances of the SelectionProcess class forming a Selection Sequence. Only those packets passing the sequence of Selection Processes enter the record cache. If no references to instances of the SelectionProcess class are specified, all observed packets enter the record cache. o The SelectionProcess class contains the configuration parameters of a Selection Process,i.e. sampling and filtering parameters.which is a Primitive Selector (i.e., sampler or filter). An instance of the SelectionProcess class can be referred from multiple Metering Processes, which allows theusageapplication of the same Selection Process in different Metering Processes. o TheCacheParametersCache class contains configuration parameters of a cache which stores the records in the monitoring device. Configuration parameters of theCacheParametersCache class specify the record format (Template), expiration parameters, and cache size. In addition, references to one or multiple Exporting Processes can be included. An instance of theCacheParametersCache class can be referred from multiple Metering Processes, enabling the shared usage of the same record cache in different Metering Processes. As the Template is defined in theCacheParametersCache class, using the same record cache implies that the record format is identical. Also, the same Exporting Processes will be used, as these are linked to the record cache. o The ExportingProcess class contains configuration parameters of an Exporting Process. It defines the export parameters and destinations. An instance of the ExportingProcess class can be referred from multiple instances of theCacheParametersCache class. +------------------+ 0..* +-----------------+ | ObservationPoint |<>------| MeteringProcess | +------------------+ +-----------------+ | | | | | | 0..* | V | +------------------+ | | SelectionProcess | | +------------------+ | | | 1 +------------------+ +-->|CacheParametersCache | +------------------+ | | | 0..* V +------------------+ | ExportingProcess | +------------------+ Figure 1: Main classes of the configuration data model As can be seen in Figure 1, the MeteringProcess class defines references to instances of the SelectionProcess class and theCacheParametersCache class. It acts as an envelope element specifying a series of Selection Processes, forming a Selection Sequence, and a record cache. The order in which the user specifies Selection Processesare specifiedin the XML document corresponds to the order in which they are applied.Thus,Hence, by using UML associations instead of aggregation relationships, the same Selection Processes and record caches can be deployed in different Metering Processes. An example is given in Section 7.1. The MeteringProcess class itself is not instantiated, but specified as part of the ObservationPoint class. Using the same Metering Process with different Observation Points is achieved by referring to the same instances of the SelectionProcess class and theCacheParametersCache class. Considering Selection Processes and Cache Parameters as instances (and not the complete Metering Process) corresponds to the common practice to implement Selection Processes and record caches as independent modules. TheCacheParametersCache class refers to instances of the ExportingProcess class, which enables using the same Exporting Process for different Metering Processes. The CollectingProcess class is depicted in Figure 2. Itdefinesconfigures one or multiplereceivinglistening ports or input files using the Receiver class. If the monitoring device acts as a mediator or concentrator, the MeteringProcess class is specified as part of theCollectingProcess.CollectingProcess class. However, the CollectingProcess class also allows referring to instances of the ExportingProcess class to export the received records without modifications to a file or another collector. +-------------------+ 1..* +---------------+ | |<>------| Receiver | | CollectingProcess | +---------------+ | | | | 0..* +-----------------+ | |<>------| MeteringProcess |+-------------------+| | +-----------------+ | | | | | | | | | | | | 0..* | | | V | | | +------------------+ | | | | SelectionProcess | | | | +------------------+ | | | | | | | | | 1 +------------------+ | | +-->|CacheParametersCache | | | +------------------+ | | | | | | | | | 0..* | | V | | 0..* +------------------+ | |------->| ExportingProcess | +-------------------+ +------------------+ Figure 2: CollectingProcess class Each of the presented classes contains specific configuration parameters which are specified in the next section. Theimplementationformal definition of the configuration data model inXMLYANG isspecified in XML Schema language [W3C.REC-xmlschema-0-20041028]given in Section6 and illustrated6. Section 7 illustrates the usage of the model withexamplesexample configurations inSection 7.XML. 5. Configuration Parameters This section specifies the configuration parameters of the configuration data model separately for each class. Parameters serving as keys are depicted in brackets. 5.1. ObservationPoint Class +---------------------+ | ObservationPoint | +---------------------+ 1 +--------------------+ |observationPointId[name] |<>--------| Interface/Linecard | |observationDomainIdobservationPointId | +--------------------+ | observationDomainId | | | 0..* +--------------------+ | |<>--------| MeteringProcess | +---------------------+ +--------------------+ +------------------++------------------++----------------------------------+ | Interface | | Linecard | +------------------++------------------++----------------------------------+ |ifIndexifIndex/ifName | |entPhysicalIndex | | ifName | | entPhysicalNameentPhysicalIndex/entPhysicalName | | direction | | direction | +------------------++------------------++----------------------------------+ Figure 3: ObservationPoint class The ObservationPoint class identifies an Observation Point of the monitoring device,i.e.which is either an interface or a linecard. The ObservationPoint class may specify the Observation Domain ID if the monitoring device implementation supports this configuration. If supported, the ObservationPoint class may also set the value of the Information Element observationPointId[I-D.ietf-ipfix-info].[RFC5102]. The configuration parameters to identify an interface or a linecard are as follows: oifIndex, ifName: Index andifIndex/ifName: Either the index or name of the interface must be specified according to corresponding objects in theIF-MIB. Only one of them must be specified to identify the interface.IF-MIB [RFC2863]. oentPhysicalIndex, entPhysicalName: Index andentPhysicalIndex/entPhysicalName: Either the index or name of the linecard must be specified according tothecorresponding objects in theENTITY-MIB.ENTITY-MIB [RFC4133]. o direction:SpecifiesThis parameter specifies if ingress traffic, egress traffic, or both, ingress and egress traffic is captured.[DISCUSS: Allow only "ingress" and "egress"?]If not applicable (e.g., in the case of a sniffing interface in promiscuous mode), this parameter is omitted. The ObservationPoint class mayspecifyconfigure one or multiple MeteringProcesses.Processes which process the observed packets in parallel. 5.2. MeteringProcess Class +-------------------+ | MeteringProcess | +-------------------+ 0..* +------------------+ |meteringProcessId[name] |------>| SelectionProcess | | meteringProcessId | +------------------+ | | | | 1 +------------------+ | |------>|CacheParametersCache | +-------------------+ +------------------+ Figure 4: MeteringProcess class The MeteringProcess class represents a Metering Process. It refers to one instance of theCacheParametersCache class that specifies a record cache in the monitoring device. In addition, the MeteringProcess class may refer to one or multiple instances of the SelectionProcess class which specify sampling and filtering methods applied to the packets before entering the record cache. The order of the Selection Processes references in the XML document corresponds to the sequence in which they are applied. If no SelectionProcess is specified, all observed packets are selected. If supported by the monitoring device implementation, the MeteringProcess class may set the value of the Information Element meteringProcessId[I-D.ietf-ipfix-info].[RFC5102]. 5.3. SelectionProcess Class +------------------+ | SelectionProcess | +------------------+0..* +----------------+1 +-----------------+ |selectorId[name] |<>------+SampCountBased | | | +----------------+SampCountBased/ | |0..* +----------------+selectorId ||<>------| SampTimeBased| SampTimeBased/ | |+----------------+| |0..* +----------------+SampRandOutOfN/ ||<>------| SampRandOutOfN| | |+----------------+SampUniProb/ | |0..* +----------------+||<>------| SampUniProb| SampNonUniProb/ | |+----------------+| |0..* +----------------+SampFlowState/ ||<>------| SampNonUniProb| | |+----------------+ | | 0..* +----------------+ | |<>------| SampFlowState | |FilterMatch/ |+----------------+ | | 0..* +----------------+||<>------| FilterMatch| | FilterHash/ |+----------------+| |0..* +----------------+||<>------| FilterHashFilterRState | +------------------++----------------++-----------------+ Figure 5: SelectionProcess class The SelectionProcess class contains the configuration parameters of a Selection Process.AIn the configuration data model, a Selection Processis composed ofimplements a Primitive Selector according to [I-D.ietf-psamp-protocol]. Standardized PSAMP samplingand/orand filtering methodsasare described in [I-D.ietf-psamp-sample-tech]. The configuration parameters ofan individual sampling or filteringeach method are specified in a corresponding sampler (Samp*) or filter (Filter*) class.If more thanThe SelectionProcess class contains exactly onemethod is specified, the order in the XML document corresponds toof these classes, depending on thesequence in which they are applied.applied method. If supported by the monitoring device implementation, the SelectionProcess class may set the value of the Information Element selectorId[I-D.ietf-ipfix-info]. In the XML document, each instance of the SelectionProcess class must be assigned a unique value of the "id" attribute, which allows deploying the Selection Process in different Metering Processes.[RFC5102]. 5.3.1. Sampler Classes +----------------+ +----------------+ +----------------+ | SampCountBased | | SampTimeBased | | SampRandOutOfN | +----------------+ +----------------+ +----------------+ | interval | | interval | | population | | spacing | | spacing | | sample | +----------------+ +----------------+ +----------------+ +----------------+ +----------------+ +----------------+ | SampUniProb | | SampNonUniProb | | SampFlowState | +----------------+ +----------------+ +----------------+ | probability | | function | | func | | | | funcParam | | funcParam | +----------------+ +----------------+ +----------------+ Figure 6: Sampler classes The names and semantic of the configuration parameters correspond to the managed objects in the PSAMP MIB module [I-D.ietf-psamp-mib]. 5.3.2. Filter Classes +----------------+ +----------------+ +----------------+ | FilterMatch | | FilterHash | | FilterRState | +----------------+ +----------------+ +----------------+ |infoElementIdfieldId | | addrType | | function | | startValue | | headerBits | | negate | | stopValue | | payloadBytes | | ifIndex | | mask | | payloadBits | | startAS | | | | function | | stopAS | | | | inputBits | | vendorFunc | | | | outputBits | | | | | | outputMask | | | | | | selection | | | +----------------+ +----------------+ +----------------+ Figure 7: Filter classes The names and semantic of the configuration parameters correspond to the managed objects in the PSAMP MIB module [I-D.ietf-psamp-mib]. 5.4.CacheParametersCache Class +-----------------+ |CacheParametersCache | +-----------------+ 1 +------------------+ |cacheType[name] |<>------| Template | |cacheSizecacheType | +------------------+ |activeTimeoutcacheSize | |idleTimeoutactiveTimeout | 0..* +------------------+ | idleTimeout |------->| ExportingProcess | +-----------------+ +------------------+ Figure 8:CacheParametersCache class TheCacheParametersCache class contains the configuration parameters of a record cache. The configuration parameters of theCacheParametersCache class are as follows: o cacheType: "normal", "immediate", or "permanent". o cacheSize:Maximummaximum number of records in the cache. o activeTimeout:Timeouttimeout after which an active Flow is timed outanyway,anyway even if there is still a continuous flow of packets. o idleTimeout: A Flow is considered to be timed out if no packets belonging to the Flow have been observed for the amount of time specified by this parameter. TheCacheParametersCache class contains a Template definition which specifies the record format. Furthermore, it may refer to one or multiple instances of the ExportingProcess class, specifying the export parameters and destinations.In the XML document, each instance of the CacheParameters class must be assigned a unique value of the "id" attribute, which allows using the same record cache in different Metering Processes.5.4.1. Template Class +------------+ | Template | +------------+ 0..* +------------------+ | templateId |<>------|FlowKeyFieldField | | | +------------------+ | | |ieId[name] | | | |ieNameieId/ieName | | | |lengthieLength | | | | enterpriseNumber | | |+------------------+ | | | | 0..* +------------------+ | |<>------| NonFlowKeyField | | | +------------------+ | | | ieId | | | | ieName | ||| length | | | | enterpriseNumberisFlowKey | +------------+ +------------------+ Figure 9: Template class The Template class specifies theFlow Key fields and non-Flow Keyfields of a Template using theFlowKeyField class and the NonFlowKeyField class respectively.Field class. The configuration parameters of the Templateclass, the FlowKeyField class,class and theNonFlowKeyFieldField class are as follows: o templateId:OptionalThis is an optional parameter which allows specifying a Template ID value for the Template. As specified in the IPFIX protocol[I-D.ietf-ipfix-protocol],[RFC5101], the Template ID must be locally unique per Observation Domain and Transport Session, which restricts the usage of identical values for multiple Template definitions within the same monitoring device configuration. If this parameter is omitted, the Template ID will be assigned automatically by the monitoring device. o ieId, ieName,length,ieLength, enterpriseNumber:Identifier,These parameters specify a template field by identifier, name, length, and enterprise number of an Information Element.At least,Either ieId orIeNameieName must be specified.If length is not specified, theieLength can be omitted if a default lengthforexists of the specified InformationElement is used.Element. enterpriseNumber must only be inserted for enterprise-specific Information Elements. o isFlowKey: If present, this field is a Flow Key. The order of the fields in the XML document corresponds to the order in the Template. 5.5. ExportingProcess Class +--------------------+ | ExportingProcess | +--------------------+ 0..* +-------------+ |exportingProcessId[name] |<>------| Destination |+--------------------+| exportingProcessId | +-------------+ +--------------------+ Figure 10: ExportingProcess class The ExportingProcess class specifies a list of destinations to which the measurement data are exported. If supported by the monitoring device implementation, the ExportingProcess class may set the value of the Information Element exportingProcessId[I-D.ietf-ipfix-info]. In the XML document, each instance of the ExportingProcess class must be assigned a unique value of the "id" attribute, which allows referring to the same Exporting Process from different instances of the CacheParameters class.[RFC5102]. 5.5.1. Destination Class +-----------------+ | Destination | +-----------------+ 1 +-----------------------+ |type[name] |<>------| SctpExport/UdpExport/ | | type | | TcpExport/FileExport | | | +-----------------------+ | | | | 0..* +-----------------------+ | |<>------| Option | +-----------------+ +-----------------------+ Figure 11: Destination class The Destination class specifies one export destination of an Exporting Process. The type parameter determines the Transport Session type (primary, secondary,orduplicate, loadbalancing)balancing, or unused) and corresponds to the ipfixTransportSessionGroupMemberType object in [I-D.ietf-ipfix-mib]. The Destination class contains further configuration parameters that are specific to the transport protocol used (SCTP, UDP, or TCP). It is also possible to export the measurement data to a file as proposed in[I-D.trammell-ipfix-file].[I-D.ietf-ipfix-file]. Optionally, the ExportingProcess class specifies the report of additional information with Option Templates, using the Option class. 5.5.2. Export Parameters Classes +--------------------------+ +--------------------------+ | SctpExport | | TcpExport | +--------------------------+ +--------------------------+ |ipAddressType | | ipAddressType | |destinationIpAddress | | destinationIpAddress | | destinationTransportPort | | destinationTransportPort | |reliabilitysourceIpAddress* | | | | timedReliability | | | +--------------------------+ +--------------------------+ +------------------------------+ +-------------+ | UdpExport | | FileExport | +------------------------------+ +-------------+ |ipAddressTypedestinationIpAddress | | uri | |destinationIpAddress | +-------------+ |destinationTransportPort | +-------------+ | sourceIpAddress | | templateRefreshTimeout | | templateRefreshPacket | | optionTemplateRefreshTimeout | | optionTemplateRefreshPacket | +------------------------------+ Figure 12: Export parameters classes The configuration parameters of the export parameters classes are: oipAddressType,destinationIpAddress, destinationTransportPort:IP address type,destination IPaddress,address and destination transport to be used for export with SCTP, UDP, or TCP. oreliability: Reliability level when using SCTP as transport protocol.timedReliability: lifetime until an IPFIX Message is "abandoned" due to the timed reliability mechanism of PR-SCTP [RFC3758]. o sourceIpAddress:SourceIn the case of UdpExport, this optional parameter may appear once to set the source IPaddress when using UDP as transport protocol.address. If this parameter is omitted, the address assigned to the outgoing interface is used. In the case of SctpExport, 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. o templateRefreshTimeout, templateRefreshPacket, optionTemplateRefreshTimeout, optionTemplateRefreshPacket: Template refresh parameters when using UDP as transport protocol. o uri:Filefile name and location encoded as URI if the measurement data is exported to a file. 5.5.3. Option Class +-----------+ | Option | +-----------+ 0..1 +----------------+ |type[name] |<>------| OptionTemplate | |timeouttype | +----------------+ | timeout | +-----------+ Figure 13: Option class The Option class defines the type of additional information to be reported, such as statistics, flow keys, sampling and filtering parameters etc.[I-D.ietf-ipfix-protocol][RFC5101] and [I-D.ietf-psamp-protocol] specify several types of reporting information which may be exported. The type can be one of the following:metering-statistics: ExportmeteringStatistics: export of Metering Process statistics using the Metering Process Statistics Option Template[I-D.ietf-ipfix-protocol]. metering-reliability: Export[RFC5101]. meteringReliability: export of Metering Process reliability statistics using the Metering Process Reliability Statistics Option Template[I-D.ietf-ipfix-protocol]. exporting-reliability: Export[RFC5101]. exportingReliability: export of Exporting Process reliability statistics using the Exporting Process Reliability Statistics Option Template[I-D.ietf-ipfix-protocol]. flow-keys: Export[RFC5101]. flowKeys: export of the Flow Key specification using the Flow Keys Option Template[I-D.ietf-ipfix-protocol]. selection-sequence: Export[RFC5101]. selectionSequence: export oftheSelection Sequence and Selector Report Interpretation [I-D.ietf-psamp-protocol].selector-reports: ExportselectionStatistics: export ofthe SelectorSelection Sequence Statistics Report Interpretation [I-D.ietf-psamp-protocol].reducing-redundancy: Exportaccuracy: export of Accuracy Report Interpretation [I-D.ietf-psamp-protocol]. reducingRedundancy: export of common properties according to [I-D.ietf-ipfix-reducing-redundancy]. The Option Template can be specified manually, using the OptionTemplate class. If no Option Template is specified, the Exporter chooses a template definition automatically according to the option type and availableinformation.option data. The timeout parameter specifies the reporting interval. If the reporting timeout is zero, the corresponding reporting information will be exported only once. Otherwise, the information is exported periodically. 5.5.4. OptionTemplate Class +----------------+ | OptionTemplate | +----------------+ 0..* +------------------+ | templateId |<>------|ScopeFieldOptionField | | | +------------------+ | | |ieId[name] | | | |ieName | | | | length | | | | enterpriseNumber | | | +------------------+ | | | | 0..* +------------------+ | |<>------| NonScopeField | |ieId |+------------------+| | |ieIdieName | | | |ieNameieLength | | | |lengthenterpriseNumber | | | |enterpriseNumberisScope | +----------------+ +------------------+ Figure 14: OptionTemplate class The Option Template class specifies thescope fields and non-scopefields of an Option Template using theScopeField class and the NonScopeField class respectively.OptionField class. The configuration parameters are the same as for theTemplate, FlowKeyField,Template andNonFlowKeyFieldField classes (see Section 5.4.1). If the parameter isScope is present, the field is a scope field. 5.6. CollectingProcess Class and Receiver Class+---------------------++-------------------+ | CollectingProcess |+---------------------++-------------------+ | [name] | 1..*+-------------------------++------------------+ ||<>--------||<>-------| Receiver | | |+-------------------------++------------------+ 1 +---------------+ | | |ipAddressType[name] |<>----| SctpReceiver/ | | | +------------------+ |ipAddressUdpReceiver/ | | | | TcpReceiver/ | | | 0..* +------------------+ | FileImport | | |<>-------| MeteringProcess | +---------------+ | | +------------------+ | | | | 0..* +------------------+ | |-------->| ExportingProcess | +-------------------+ +------------------+ +----------------+ +----------------+ | SctpReceiver | | TcpReceiver | +----------------+ +----------------+ |transportProtocolipAddress* | | ipAddress | | transportPort | | transportPort | +----------------+ +----------------+ +-------------------------+ +------------+ |defaultTemplateLifetimeUdpReceiver | | FileImport | +-------------------------+ +------------+ | ipAddress | | uri |0..* +-----------------+||<>--------| MeteringProcesstransportPort |+---------------------+ +-----------------++------------+ | defaultTemplateLifetime | +-------------------------+ Figure 15: CollectingProcess class and Receiver Class The CollectingProcess class contains one or multiple receivers specified with the Receiver class.Each receiver configures a port on the monitoring deviceThe Receiver class contains further configuration parameters that are specific toreceive measurementthe transport protocol used (SCTP, UDP, or TCP). Instead of receiving dataexported by other monitoring devices usingfrom theIPFIX Protocol and/or PSAMP Protocol.network, it is possible to import it from a file to which it as been exported as proposed in [I-D.ietf-ipfix-file]. The CollectingProcess class and theReceiver classSctpReceiver, UdpReceiver, TcpReceiver, and FileImport classes contain the following parameters: oipAddressType,ipAddress,transportProtocol,transportPort: IP addresstype, IP address, transport protocoland port number of the receiving port. If ipAddress is omitted, the Collecting Process receives data sent to any local IP address. In the case of SctpReceiver, multiple IP addresses can be specified as a list of eligible local IP addresses to be used for the local SCTP endpoint [RFC4960]. o defaultTemplateLifetime:Defaultdefault template lifetime if UDP is used as transport protocol, ignored otherwise. o uri: file name and location encoded as URI if the measurement data is imported from a file. If the monitoring device isaan IPFIX mediator or concentrator as described in [I-D.kobayashi-ipfix-mediator-model] and [I-D.dressler-ipfix-aggregation], the CollectingProcess class specifies one or multiple Metering Processes. The CollectingProcess class may refer to one or multiple instances of the ExportingProcess class in order to export received records without modifications to a file or another collector. 6.XML Schema Specification XML Schema DefinitionYANG Module of the IPFIX/PSAMP Configuration Data Model The YANG module specification of the configuration data model is specified as follows:<?xml version="1.0" encoding="UTF-8" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:ipfix-psamp-config" xmlns="urn:ietf:params:xml:ns:ipfix-psamp-config" elementFormDefault="qualified" version="3.0"> <xsd:annotation> <xsd:documentation xml:lang="en"> IPFIX/PSAMPmodule ipfix-psamp { namespace "urn:ietf:params:xml:ns:ipfix-psamp-config"; prefix ipfix; import yang-types { prefix yang; } import inet-types { prefix inet; } import IF-MIB { prefix if; } import ENTITY-MIB { prefix ent; } organization "IPFIX WG"; contact "muenz@informatik.uni-tuebingen.de"; description "IPFIX/PSAMP Configuration DataModel Version 3.0Model"; revision 2008-02-20 { description "Version of draft-muenz-ipfix-configuration-04 Changes in -04: - first version3.0: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 Option Class Changes inversion 2.0:-02: - new structure without next pointers - packet reporting and flow metering replaced by record cache - added reporting withoptions </xsd:documentation> </xsd:annotation> <!-- Generic Type: Information Element --> <xsd:complexType name="infoElement_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type is used to specifyoptions"; } grouping InformationElement { description "Parameters of an InformationElementElement."; leaf ieEnterpriseNumber { description "Omitted infilters and templates. - Insteadthe case ofieId,an IETF specified Information Elements."; type uint32; } choice NameOrId { mandatory true; leaf ieName { type string; } leaf ieId { type uint16; } } leaf ieLength { description "Length can beused as specified ipfix-info. - If length is omitted, theomitted if a default lengthis used. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="enterpriseNumber" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="ieName" type="xsd:string" minOccurs="0" /> <xsd:element name="ieId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="length" type="xsd:unsignedInt" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <!-- Generic Type: Reference --> <xsd:complexType name="reference_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisexists for the specified Information Element."; typeis used to specify a referenceuint16; } } typedef Direction { description "Direction of packets going through an interface or linecard."; type enumeration { enum ingress; enum egress; enum both; } } grouping Interface { description "Interface as input toa Selection Process, record cache,Observation Point."; choice IndexOrName { description "Index orExporting Process identified byname of theid attribute. </xsd:documentation> </xsd:annotation> <xsd:attribute name="id" type="xsd:IDREF" use="required" /> </xsd:complexType> <!-- Generic Type: Time --> <xsd:complexType name="time_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisinterface as stored in the ifTable of IF-MIB."; reference "RFC 1229."; mandatory true; leaf ifIndex { typeis used for defaultTemplateLifetime, activeTimeout idleTimeout, templateRefreshTimemout, and optionTemplateRefreshTimeout. </xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:extension base="xsd:unsignedInt"> <xsd:attribute name="unit" use="optional" default="s"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="min" /> <xsd:enumeration value="s" /> <xsd:enumeration value="ms" /> <xsd:enumeration value="us" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <!-- Generic Type: Direction --> <xsd:simpleType name="direction_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisuint32; } leaf ifName { typeis usedstring; } } leaf direction { description "Direction of packets. If not applicable (e.g., inInterface class and Linecard class. </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ingress" /> <xsd:enumeration value="egress" /> <xsd:enumeration value="both" /> </xsd:restriction> </xsd:simpleType> <!-- Generic Type: Description --> <xsd:complexType name="description_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisthe case of a sniffing interface in promiscuous mode), this parameter is omitted"; typeprovides anDirection; } } grouping Linecard { descriptionattribute for optional annotations for"Linecard as input to ObservationPoints, Selection Processes, Cache Parameters, Exporting Processes, and Collecting Processes. The valuePoint."; choice IndexOrName { description "Index or name ofthis attribute has no effect onthedevice configuration. </xsd:documentation> </xsd:annotation> <xsd:attribute name="description" type="xsd:string" use="optional" /> </xsd:complexType> <!-- Observation Point --> <xsd:complexType name="observationPoint_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thislinecard as stored in the entPhysicalTable of ENTITY-MIB."; reference "RFC 4133."; mandatory true; leaf entPhysicalIndex { typeidentifies an Observation Point. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="description_type"> <xsd:sequence> <xsd:element name="observationPointId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="observationDomainId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:choice> <xsd:element name="Interface" type="interface_type" /> <xsd:element name="Linecard" type="linecard_type" /> </xsd:choice> <xsd:element name="MeteringProcess" type="meteringProcess_type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="interface_type"> <xsd:sequence> <xsd:choice> <xsd:element name="ifIndex" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="ifName" type="xsd:string" minOccurs="0" /> </xsd:choice> <xsd:element name="direction" type="direction_type" minOccurs="0" default="both" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="linecard_type"> <xsd:sequence> <xsd:choice> <xsd:element name="entPhysicalIndex" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="entPhysicalName" type="xsd:string" minOccurs="0" /> </xsd:choice> <xsd:element name="direction" type="direction_type" minOccurs="0" default="both" /> </xsd:sequence> </xsd:complexType> <!-- Metering Process --> <xsd:complexType name="meteringProcess_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisuint32; } leaf entPhysicalName { type string; } } leaf direction { description "Direction of packets. If not applicable (e.g., in the case of a sniffing interface in promiscuous mode), this parameter isused to specifyomitted"; type Direction; } } grouping MeteringProcess { description "Selection Processes and Record Cache of a MeteringProcess. There must be at least a reference to a record cache. If specified, SelectionProcess."; leaf meteringProcessId { description "If omitted, the Metering Process ID is assigned by the monitoring device."; type uint32; } leaf-list selectionProcess { description "Selection Processes are applied in the order of their appearance. If no SelectionProcesses areProcess is specified, allobservedpackets areselected. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="meteringProcessId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="SelectionProcess" type="reference_type" minOccurs="0" maxOccurs="unbounded" /> <xsd:element name="CacheParameters" type="reference_type" /> </xsd:sequence> </xsd:complexType> <!-- Selection Process --> <xsd:complexType name="selectionProcess_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisselected."; ordered-by user; typeis used to specifykeyref { path "/ipfix/selectionProcess/name"; } } leaf cache { mandatory true; type keyref { path "/ipfix/cache/name"; } } } container ipfix { list collectingProcess { description "Parameters of aSelection Process.Collecting Process."; key name; leaf name { description "Arbitrary but unique name of the Collecting Process."; type string; } list receiver { description "Receiver parameters."; key name; leaf name { type string; } choice TransportProtocol { mandatory true; container sctpReceiver { description "SCTP receiver parameters."; reference "RFC 4960."; leaf-list ipAddress { description "List of eligible local IP addresses to be used by the SCTP endpoint. Ifmore than one selection method is specified, theyomitted, all locally assigned IP addresses areappliedused by the SCTP endpoint."; type inet:ip-address; } leaf transportPort { mandatory true; type inet:port-number; } } container udpReceiver { description "UDP receiver parameters."; leaf ipAddress { description "If omitted, all locally assigned IP addresses are used by the UDP endpoint."; type inet:ip-address; } leaf transportPort { mandatory true; type inet:port-number; } leaf defaultTemplateLifetime { type uint32; } } container tcpReceiver { description "TCP receiver parameters."; leaf ipAddress { description "If omitted, all locally assigned IP addresses are used by the TCP endpoint."; type inet:ip-address; } leaf transportPort { mandatory true; type inet:port-number; } } container fileImport { description "File import parameters."; leaf uri { mandatory true; type yang:uri; } } } } list meteringProcess { description "Metering Processes process received records in parallel. Monitoring device acts as IPFIX mediator/concentrator."; key name; leaf name { description "Arbitrary but unique name of theorderMonitoring Process."; type string; } uses MeteringProcess; } leaf-list exportingProcess { description "Export oftheir appearance. Seereceived records without any modifications. Records are exported by all Exporting Processes in the list."; type keyref { path "/ipfix/exportingProcess/name"; } } } list observationPoint { description "Parameters of an Observation Point."; key name; leaf name { description "Arbitrary but unique name of the Observation Point."; type string; } leaf observationPointId { description "If omitted, the Observation Point ID is assigned by the monitoring device."; type uint32; } leaf observationDomainId { description "If omitted, the Observation Domain ID is assigned by the monitoring device."; type uint32; } choice OPType { mandatory true; container interface { uses Interface; } container linecard { uses Linecard; } } list meteringProcess { description "Metering Processes process packets in parallel."; key name; leaf name { description "Arbitrary but unique name of the Monitoring Process."; type string; } uses MeteringProcess; } } list selectionProcess { description "Parameters of a Selection Process (i.e., Primitive Selector)."; key name; leaf name { description "Arbitrary but unique name of the Selection Process."; type string; } leaf selectorId { description "If omitted, the Selector ID is assigned by the monitoring device."; type uint32; } choice Method { description "See PSAMP-MIB for details about the selection methods and theirparameters. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="description_type"> <xsd:sequence> <xsd:element name="selectorId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element name="SampCountBased" type="sampCountBased_type" /> <xsd:element name="SampTimeBased" type="sampTimeBased_type" /> <xsd:element name="SampRandOutOfN" type="sampRandOutOfN_type" /> <xsd:element name="SampUniProb" type="sampUniProb_type" /> <xsd:element name="SampNonUniProb" type="sampNonUniProb_type" /> <xsd:element name="SampFlowState" type="sampFlowState_type" /> <xsd:element name="FilterMatch" type="filterMatch_type" /> <xsd:element name="FilterHash" type="filterHash_type" /> <xsd:element name="FilterRState" type="filterRState_type" /> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="required" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="sampCountBased_type"> <xsd:sequence> <xsd:element name="interval" type="xsd:unsignedInt" /> <xsd:element name="spacing" type="xsd:unsignedInt" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sampTimeBased_type"> <xsd:sequence> <xsd:element name="interval" type="xsd:unsignedInt" /> <xsd:element name="spacing" type="xsd:unsignedInt" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sampRandOutOfN_type"> <xsd:sequence> <xsd:element name="population" type="xsd:unsignedInt" /> <xsd:element name="sample" type="xsd:unsignedInt" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sampUniProb_type"> <xsd:sequence> <xsd:element name="probability" type="xsd:unsignedInt"> <xsd:annotation> <xsd:documentation xml:lang="en"> Theparameters."; reference "draft-ietf-psamp-mib-06."; mandatory true; container sampCountBased { leaf interval { type uint32; } leaf spacing { type uint32; } } container sampTimeBased { leaf interval { type uint32; } leaf spacing { type uint32; } } container sampRandOutOfN { leaf population { type uint32; } leaf sample { type uint32; } } container sampUniProb { leaf probability { description "The given value must be divided by4294967295 </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sampNonUniProb_type" mixed="true"> <xsd:sequence> <xsd:element name="function" type="xsd:string" /> <xsd:element name="funcParam" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="sampFlowState_type" mixed="true"> <xsd:sequence> <xsd:element name="function" type="xsd:string" /> <xsd:element name="funcParam" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="filterMatch_type"> <xsd:sequence> <xsd:element name="infoElementId" type="xsd:unsignedInt" /> <xsd:element name="startValue" type="xsd:unsignedInt" /> <xsd:element name="stopValue" type="xsd:unsignedInt" /> <xsd:element name="mask" type="xsd:unsignedInt" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="filterHash_type"> <xsd:sequence> <xsd:element name="addrType" type="xsd:unsignedInt" /> <xsd:element name="headerBits" type="xsd:string" /> <xsd:element name="payloadBytes" type="xsd:unsignedInt" /> <xsd:element name="payloadBits" type="xsd:string" /> <xsd:element name="function" type="xsd:string" /> <xsd:element name="funcParam" type="xsd:string" /> <xsd:element name="inputBits" type="xsd:unsignedInt" /> <xsd:element name="outputBits" type="xsd:unsignedInt" /> <xsd:element name="outputMask" type="xsd:string" /> <xsd:element name="selection" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="filterRState_type"> <xsd:sequence> <xsd:element name="function" type="xsd:string" /> <xsd:element name="negate" type="xsd:boolean" /> <xsd:element name="ifIndex" type="xsd:unsignedInt" /> <xsd:element name="startAS" type="xsd:unsignedInt" /> <xsd:element name="endAS" type="xsd:unsignedInt" /> <xsd:element name="vendorFunc" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <!-- Cache Parameters --> <xsd:complexType name="cacheParameters_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> This4294967295."; typespecifiesuint32; } } container sampNonUniProb { description "In PSAMP-MIB, these are OIDs."; leaf function { type string; } leaf funcParam { type string; } } container sampFlowState { description "In PSAMP-MIB, these are OIDs."; leaf function { type string; } leaf funcParam { type string; } } container filterMatch { leaf fieldId { type uint32; } leaf startValue { type string; } leaf stopValue { type string; } leaf mask { type string; } } container filterHash { description "In PSAMP-MIB, function and funcParam are OIDs."; leaf addrType { type inet:ip-version; } leaf headerBits { type string; } leaf payloadBytes { type uint32; } leaf payloadBits { type string; } leaf function { type string; } leaf funcParam { type string; } leaf inputBits { type uint32; } leaf outputBits { type uint32; } leaf outputMask { type string; } leaf selection { type string; } } container filterRState { description "In PSAMP-MIB, vendorFunc is OID."; leaf function { type int32; } leaf negate { type boolean; } leaf ifIndex { description "Index of theparametersinterface as stored in the ifTable of IF-MIB."; reference "RFC 2863."; type uint32; } leaf startAS { type inet:asn; } leaf stopAS { type inet:asn; } leaf vendorFunc { type string; } } } } list cache { description "Parameters of arecord cache. At least, a Template must be specified. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="description_type"> <xsd:sequence> <xsd:element name="cacheType" type="cacheType_type" minOccurs="0" default="normal" /> <xsd:element name="cacheSize" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="activeTimeout" type="time_type" minOccurs="0" /> <xsd:element name="idleTimeout" type="time_type" minOccurs="0" /> <xsd:element name="Template" type="template_type" /> <xsd:element name="ExportingProcess" type="reference_type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="required" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:simpleType name="cacheType_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Cache types: - normal: flowcache."; key name; leaf name { description "Arbitrary but unique name of the cache."; type string; } leaf cacheType { type enumeration { enum normal { description "Flow expiration after active and idletimeout - immediate:timeout."; } enum immediate { description "Flow expiration after the first packet (PSAMPexport) - permanent: flows never expire,export)."; } enum permanent { description "No flow expiration, periodical export after activetimeout </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:enumeration value="normal" /> <xsd:enumeration value="immediate" /> <xsd:enumeration value="permanent" /> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="template_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thistimeout."; } } } leaf cacheSize { typeis used to specify a Template. Ifuint32; } leaf activeTimeout { type yang:timeticks; } leaf idleTimeout { type yang:timeticks; } container template { leaf templateIdis{ description "If omitted, the Template ID is assigned by the monitoringdevice. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="templateId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:choice minOccurs="0" maxOccurs="unbounded" > <xsd:element name="FlowKeyField" type="infoElement_type" /> <xsd:element name="NonFlowKeyField" type="infoElement_type" /> </xsd:choice> </xsd:sequence> </xsd:complexType> <!-- Exporting Process --> <xsd:complexType name="exportingProcess_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisdevice."; typespecifiesuint16; } list field { key name; ordered-by user; leaf name { type string; } uses InformationElement; leaf isFlowKey { type empty; } } } leaf-list exportingProcess { description "Records are exported by all Exporting Processes in theparameterslist."; type keyref { path "/ipfix/exportingProcess/name"; } } } list exportingProcess { description "Parameters of an ExportingProcess. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="description_type"> <xsd:sequence> <xsd:element name="exportingProcessId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="Destination" type="destination_type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="required" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="destination_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type specifies one destinationProcess."; key name; leaf name { description "Arbitrary but unique name ofanthe ExportingProcess. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="type" type="transportSessionType_type" minOccurs="0" default="primary" /> <xsd:choice> <xsd:element name="SctpExport" type="sctpExport_type" /> <xsd:element name="UdpExport" type="udpExport_type" /> <xsd:element name="TcpExport" type="tcpExport_type" /> <xsd:element name="FileExport" type="fileExport_type" /> </xsd:choice> <xsd:element name="Option" type="option_type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="transportSessionType_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> TransportProcess."; type string; } leaf exportingProcessId { description "If omitted, the Exporting Process ID is assigned by the monitoring device."; type uint32; } list destination { key name; leaf name { type string; } leaf type { description "Transport Sessiontypestype according toIPFIX-MIB. </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:enumeration value="primary" /> <xsd:enumeration value="secondary" /> <xsd:enumeration value="loadBalancing" /> <xsd:enumeration value="unused" /> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="sctpExport_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> ThisIPFIX-MIB"; reference "draft-ietf-ipfix-mib-02."; typecomprises parameters forenumeration { enum primary; enum secondary; enum duplicate; enum loadBalancing; enum unused; } } choice TransportProtocol { mandatory true; container sctpExport { description "SCTP export parameters."; reference "RFC 3758, RFC 4960."; leaf destinationIpAddress { mandatory true; type inet:ip-address; } leaf destinationTransportPort { mandatory true; type inet:port-number; } leaf-list sourceIpAddress { description "List of eligible local IP addresses to be used by the SCTPexport. [TODO: whichendpoint. If omitted, all locally assigned IP addresses areSCTP specific parameters?] </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="ipAddressType" type="xsd:unsignedInt" /> <xsd:element name="destinationIpAddress" type="xsd:string" /> <xsd:element name="destinationTransportPort" type="xsd:unsignedInt" /> <xsd:element name="reliability" type="xsd:string" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="udpExport_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisused by the local endpoint."; typecomprises parameters for UDP export. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="ipAddressType" type="xsd:unsignedInt" /> <xsd:element name="destinationIpAddress" type="xsd:string" /> <xsd:element name="destinationTransportPort" type="xsd:unsignedInt" /> <xsd:element name="sourceIpAddress" type="xsd:string" minOccurs="0" /> <xsd:element name="templateRefreshTimeout" type="time_type" minOccurs="0" /> <xsd:element name="templateRefreshPacket" type="xsd:unsignedInt" minOccurs="0" /> <xsd:element name="optionTemplateRefreshTimeout" type="time_type" minOccurs="0" /> <xsd:element name="optionTemplateRefreshPacket" type="xsd:unsignedInt" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="tcpExport_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisinet:ip-address; } leaf timedReliability { typecomprises parameters for TCP export. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="ipAddressType" type="xsd:unsignedInt" /> <xsd:element name="destinationIpAddress" type="xsd:string" /> <xsd:element name="destinationTransportPort" type="xsd:unsignedInt" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="fileExport_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisyang:timeticks; } } container udpExport { description "UDP export parameters."; leaf destinationIpAddress { mandatory true; typecomprises parameters for file export. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="uri" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="option_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisinet:ip-address; } leaf destinationTransportPort { mandatory true; typeis usedinet:port-number; } leaf sourceIpAddress { description "Source IP address. If omitted, the address assigned toactivate reportingthe outgoing interface is used."; type inet:ip-address; } leaf templateRefreshTimeout { type yang:timeticks; } leaf templateRefreshPacket { type uint32; } leaf optionTemplateRefreshTimeout { type yang:timeticks; } leaf optionTemplateRefreshPacket { type uint32; } } container tcpExport { description "TCP export parameters."; leaf destinationIpAddress { mandatory true; type inet:ip-address; } leaf destinationTransportPort { mandatory true; type inet:port-number; } } container fileExport { description "File export parameters."; leaf uri { mandatory true; type yang:uri; } } } list optiondata. The{ key name; leaf name { typedetermines the reported information. Thestring; } leaf type { mandatory true; type enumeration { enum "meteringStatistics" { description "Metering Process Statistics."; reference "RFC 5101, section 4.1."; } enum "meteringReliability" { description "Metering Process Reliability Statistics."; reference "RFC 5101, section 4.2."; } enum "exportingReliability" { description "Exporting Process Reliability Statistics."; reference "RFC 5101, section 4.3."; } enum "flowKeys" { description "Flow Keys."; reference "RFC 5101, section 4.4."; } enum "selectionSequence" { description "Selection Sequence and Selector Reports."; reference "draft-ietf-psamp-protocol-09, section 6.5.1 and 6.5.2."; } enum "selectionStatistics" { description "Selection Sequence Statistics Report."; reference "draft-ietf-psamp-protocol-09, section 6.5.3."; } enum "accuracy" { description "Accuracy Report."; reference "draft-ietf-psamp-protocol-09, section 6.5.4."; } enum "reducingRedundancy" { description "Application of ipfix-reducing-redundancy."; } } } leaf timeoutspecifies the time{ description "Time interval for exportingtheoptiondata. The specification of the Option Template is optional. Ifdata."; type yang:timeticks; } container optionTemplate { description "If no Option Template isdefined,specified, the Exporterchoosesdefines a templatedefinitionaccording tothe available information. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="type" type="optionType_type" /> <xsd:element name="timeout" type="time_type" minOccurs="0" /> <xsd:element name="OptionTemplate" type="optionTemplate_type" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="optionType_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Types of optional information to be exported. </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:enumeration value="metering-statistics" /> <xsd:enumeration value="metering-reliability" /> <xsd:enumeration value="exporting-reliability" /> <xsd:enumeration value="flow-keys" /> <xsd:enumeration value="selection-sequence" /> <xsd:enumeration value="selector-reports" /> <xsd:enumeration value="reducing-redundancy" /> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="optionTemplate_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type is used to specify an Option Template. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="templateId" type="xsd:unsignedInt" minOccurs="0" /> <xsd:choice minOccurs="0" maxOccurs="unbounded" > <xsd:element name="ScopeField" type="infoElement_type" /> <xsd:element name="NonScopeField" type="infoElement_type" /> </xsd:choice> </xsd:sequence> </xsd:complexType> <!-- Collecting Process --> <xsd:complexType name="collectingProcess_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> This type comprises the parameter of a Collecting Process. </xsd:documentation> </xsd:annotation> <xsd:complexContent> <xsd:extension base="description_type"> <xsd:sequence> <xsd:element name="Receiver" type="receiver_type" minOccurs="1" maxOccurs="unbounded" /> <xsd:element name="MeteringProcess" type="reference_type" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="receiver_type"> <xsd:annotation> <xsd:documentation xml:lang="en"> Thisoption typecontains IP address, transport protocol,andport number of an IPFIX collector. defaultTemplateLifetimeavailable option data."; leaf templateId { description "If omitted, the Template ID isonly used for UDP. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="ipAddressType" type="xsd:unsignedInt" /> <xsd:element name="ipAddress" type="xsd:string" /> <xsd:element name="transportProtocol" type="xsd:unsignedInt" /> <xsd:element name="transportPort" type="xsd:unsignedInt" /> <xsd:element name="defaultTemplateLifetime" type="time_type" minOccurs="0" /> </xsd:sequence> </xsd:complexType> <!-- Root Element --> <xsd:element name="ConfigData"> <xsd:annotation> <xsd:documentation xml:lang="en"> Root element ofassigned by theIPFIX/PSAMP configuration data model </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice minOccurs="0" maxOccurs="unbounded" > <xsd:element name="CollectingProcess" type="collectingProcess_type" /> <xsd:element name="ObservationPoint" type="observationPoint_type" /> <xsd:element name="SelectionProcess" type="selectionProcess_type" /> <xsd:element name="CacheParameters" type="cacheParameters_type" /> <xsd:element name="ExportingProcess" type="exportingProcess_type" /> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:schema>monitoring device."; type uint16; } list optionField { key name; ordered-by user; leaf name { type string; } uses InformationElement; leaf isScope { type empty; } } } } } } } } 7. Examples This section shows example configurations conforming to theXML SchemaYANG module specified in Section 6. 7.1. PSAMP Monitoring Device This exampledemonstratesshows two PSAMP Metering Processes configured for theconfigurationsame Observation Point. The first Metering Process consists of a Selection Sequence out of two Selection Processes, arandom samplerfilter for UDP packets and a random sampler, the second is just an ICMP filter. The two Metering Processes deploy the same cache. The configuration assumes that the monitoring device supports the configuration of values for observationPointId, meteringProcessId, selectorId, and exportingProcessId. Exporter statistics are reported using a manually specified Option Template.<ConfigData<ipfix xmlns="urn:ietf:params:xml:ns:ipfix-psamp-config"><ObservationPoint description="Traffic<observationPoint> <name>OP at linecard3">3</name> <observationPointId>1</observationPointId> <observationDomainId>12345</observationDomainId><Linecard><linecard> <entPhysicalIndex>3</entPhysicalIndex></Linecard> <MeteringProcess></linecard> <meteringProcess> <name>Reports of sampled UDP packets</name> <meteringProcessId>1</meteringProcessId><SelectionProcess id="my_sampler" /> <SelectionProcess id="my_filter" /> <CacheParameters id="my_cache" /> </MeteringProcess> </ObservationPoint> <SelectionProcess id="my_sampler" description="10-out-of-100 random packet sampler"><selectionProcess>UDP filter</selectionProcess> <selectionProcess>10-out-of-100 sampler</selectionProcess> <cache>PSAMP cache</cache> </meteringProcess> <meteringProcess> <name>Reports of ICMP packets</name> <meteringProcessId>2</meteringProcessId> <selectionProcess>ICMP filter</selectionProcess> <cache>PSAMP cache</cache> </meteringProcess> </observationPoint> <selectionProcess> <name>UDP filter</name> <selectorId>1</selectorId><SampRandOutOfN> <population>100</population> <sample>10</sample> </SampRandOutOfN> </SelectionProcess> <SelectionProcess id="my_filter" description="UDP filter"> <selectorId>2</selectorId> <FilterMatch> <infoElementId>4</infoElementId><filterMatch> <fieldId>4</fieldId> <startValue>17</startValue> <stopValue>17</stopValue></FilterMatch> </SelectionProcess> <CacheParameters id="my_cache" description="Packet cache with immediate expiration"></filterMatch> </selectionProcess> <selectionProcess> <name>ICMP filter</name> <selectorId>2</selectorId> <filterMatch> <fieldId>4</fieldId> <startValue>1</startValue> <stopValue>1</stopValue> </filterMatch> </selectionProcess> <selectionProcess> <name>10-out-of-100 sampler</name> <selectorId>3</selectorId> <sampRandOutOfN> <population>100</population> <sample>10</sample> </sampRandOutOfN> </selectionProcess> <cache> <name>PSAMP cache</name> <cacheType>immediate</cacheType> <cacheSize>512</cacheSize><Template> <FlowKeyField><template> <field> <name>Field 1</name> <ieId>313</ieId><length>64</length> </FlowKeyField> <NonFlowKeyField><ieLength>64</ieLength> </field> <field> <name>Field 2</name> <ieName>154</ieName></NonFlowKeyField> </Template> <ExportingProcess id="my_exporter" /> </CacheParameters> <ExportingProcess id="my_exporter" description="PR-SCTP exporter"></field> </template> <exportingProcess>The only exporter</exportingProcess> </cache> <exportingProcess> <name>The only exporter</name> <exportingProcessId>1</exportingProcessId><Destination><destination> <name>PR-SCTP collector</name> <type>primary</type><SctpExport> <ipAddressType>4</ipAddressType><sctpExport> <destinationIpAddress>192.0.2.1</destinationIpAddress> <destinationTransportPort>4739</destinationTransportPort><reliability>partially-reliable</reliability> </SctpExport> <Option> <type>exporting-reliability</type> <timeout unit="min">5</timeout> <OptionTemplate> <ScopeField><timedReliability>200</timedReliability> </sctpExport> <option> <name>Option 1</name> <type>exportingReliability</type> <timeout>30000</timeout> <optionTemplate> <optionField> <name>Field 1</name> <ieName>exportingProcessId</ieName></ScopeField> <NonScopeField><isScope/> </optionField> <optionField> <name>Field 2</name> <ieName>notSentPacketTotalCount</ieName></NonScopeField> </OptionTemplate> </Option> </Destination> </ExportingProcess> </ConfigData></optionField> </optionTemplate> </option> </destination> </exportingProcess> </ipfix> 7.2. IPFIX Monitoring Device This example demonstrates the shared usage of a record cache in two different Metering Processes. Packets observed at two different Observation Points are selected using different sampling techniques. Selected packets from both Observation Points enter the same record cache. The Exporting Process sends the records to a primary destination using SCTP. A UDP Collector is specified as secondary, i.e. backup destination.<ConfigData<ipfix xmlns="urn:ietf:params:xml:ns:ipfix-psamp-config"><ObservationPoint description="Ingress traffic<observationPoint> <name>OP ateth0">eth0 (ingress)</name> <observationDomainId>12345</observationDomainId><Interface><interface> <ifName>eth0</ifName> <direction>ingress</direction></Interface> <MeteringProcess> <SelectionProcess id="my_first_sampler" /> <CacheParameters id="my_cache" /> </MeteringProcess> </ObservationPoint> <ObservationPoint description="All traffic</interface> <meteringProcess> <name>Flows of sampled packets</name> <selectionProcess>Count-based sampler</selectionProcess> <cache>Flow cache</cache> </meteringProcess> </observationPoint> <observationPoint> <name>OP ateth1">eth1</name> <observationDomainId>12346</observationDomainId><Interface><interface> <ifName>eth1</ifName></Interface> <MeteringProcess> <SelectionProcess id="my_second_sampler" /> <CacheParameters id="my_cache" /> </MeteringProcess> </ObservationPoint> <SelectionProcess id="my_first_sampler" description="Count-based packet sampler"> <SampCountBased></interface> <meteringProcess> <name>Flows of sampled packets</name> <selectionProcess>Time-based sampler</selectionProcess> <cache>Flow Cache</cache> </meteringProcess> </observationPoint> <selectionProcess> <name>Count-based sampler</name> <sampCountBased> <interval>1</interval> <spacing>99</spacing></SampCountBased> </SelectionProcess> <SelectionProcess id="my_second_sampler" description="Time-based packet sampler"> <SampCountBased></sampCountBased> </selectionProcess> <selectionProcess> <name>Time-based sampler</name> <sampCountBased> <interval>20</interval> <spacing>980</spacing></SampCountBased> </SelectionProcess> <CacheParameters id="my_cache" description="Flow cache"></sampCountBased> </selectionProcess> <cache> <name>Flow cache</name> <cacheType>normal</cacheType> <cacheSize>4096</cacheSize><activeTimeout unit="s">5</activeTimeout> <idleTimeout unit="s">10</idleTimeout> <Template> <FlowKeyField><activeTimeout>5</activeTimeout> <idleTimeout>10</idleTimeout> <template> <field> <name>Field 1</name> <ieName>sourceIPv4Address</ieName></FlowKeyField> <FlowKeyField><isFlowKey/> </field> <field> <name>Field 2</name> <ieName>destinationIPv4Address</ieName></FlowKeyField> <FlowKeyField><isFlowKey/> </field> <field> <name>Field 3</name> <ieName>transportProtocol</ieName></FlowKeyField> <FlowKeyField><isFlowKey/> </field> <field> <name>Field 4</name> <ieName>sourceTransportPort</ieName></FlowKeyField> <FlowKeyField><isFlowKey/> </field> <field> <name>Field 5</name> <ieName>destinationTransportPort</ieName></FlowKeyField> <NonFlowKeyField><isFlowKey/> </field> <field> <name>Field 6</name> <ieName>flowStartMilliSeconds</ieName></NonFlowKeyField> <NonFlowKeyField></field> <field> <name>Field 7</name> <ieName>flowEndSeconds</ieName></NonFlowKeyField> <NonFlowKeyField></field> <field> <name>Field 8</name> <ieName>octetDeltaCount</ieName></NonFlowKeyField> <NonFlowKeyField></field> <field> <name>Field 9</name> <ieName>packetDeltaCount</ieName></NonFlowKeyField> </Template> <ExportingProcess id="my_exporter" /> </CacheParameters> <ExportingProcess id="my_exporter" description="SCTP Exporter</field> </template> <exportingProcess>SCTP export with UDPbackup destination"> <Destination>backup</exportingProcess> </cache> <exportingProcess> <name>SCTP export with UDP backup</name> <destination> <name>SCTP destination</name> <type>primary</type><SctpExport> <ipAddressType>4</ipAddressType><sctpExport> <destinationIpAddress>192.0.2.1</destinationIpAddress> <destinationTransportPort>4739</destinationTransportPort><reliability>fully-reliable</reliability> </SctpExport> <Option> <type>selection-sequence</type> <timeout unit="s">0</timeout> </Option> <Option> <type>exporting-reliability</type> <timeout unit="min">5</timeout> </Option> </Destination> <Destination></sctpExport> <option> <name>Option 1</name> <type>selectionSequence</type> <timeout>0</timeout> </option> <option> <name>Option 2</name> <type>exportingReliability</type> <timeout>6000</timeout> </option> </destination> <destination> <name>UDP destination</name> <type>secondary</type><UdpExport> <ipAddressType>4</ipAddressType><udpExport> <destinationIpAddress>192.0.2.2</destinationIpAddress> <destinationTransportPort>4739</destinationTransportPort> <sourceIpAddress>127.0.0.1</sourceIpAddress><templateRefreshTimeout unit="s">60</templateRefreshTimeout> <optionTemplateRefreshTimeout unit="s">60 </optionTemplateRefreshTimeout> </UdpExport> <Option> <type>selection-sequence</type> <timeout unit="min">5</timeout> </Option> </Destination> </ExportingProcess> </ConfigData><templateRefreshTimeout>6000</templateRefreshTimeout> <optionTemplateRefreshTimeout>6000</optionTemplateRefreshTimeout> </udpExport> <option> <name>Option 1</name> <type>selectionSequence</type> <timeout>30000</timeout> </option> </destination> </exportingProcess> </ipfix> 7.3. Collector Monitoring Device<ConfigDataThis example configures a collector which writes the received records to a file. <ipfix xmlns="urn:ietf:params:xml:ns:ipfix-psamp-config"><CollectingProcess description="SCTP collector"> <Receiver> <ipAddressType>4</ipAddressType><collectingProcess> <name>SCTP collector</name> <receiver> <name>Listening port 4739</name> <sctpReceiver> <ipAddress>192.0.2.1</ipAddress><transportProtocol>132</transportProtocol><transportPort>4739</transportPort></Receiver> </CollectingProcess> </ConfigData></sctpReceiver> </receiver> <exportingProcess>File writer</exportingProcess> </collectingProcess> <exportingProcess> <name>File writer</name> <destination> <name>File destination</name> <type>primary</type> <fileExport> <uri>file://tmp/collected-records.ipfix</uri> </fileExport> </destination> </exportingProcess> </ipfix> 8. Security Considerations The XML Schema Definition of the configuration data model has been conceived to enable its usage with different device implementations. In order to keep the XML Schema Definition simple and flexible, no precautions have been made to ensure that only complete and meaningful configurations can be specified. For example, most of the elements are declared optional. Furthermore, the necessary communication of device capabilities to the network management system and the corresponding limitations and adaptations of the configuration data model are not specified in this document. Hence, the XML Schema Definition does not ensure that conforming XML documents describe configurations that are both complete and supported by a given device. Users should make sure that configuration data is validated and checked against the capabilities of the device before configuring it. If configuration data is incomplete, invalid or unsupported, it must be rejected by the device and the previous configuration should remain active. In addition, an error message should be returned specifying the reason for the error of any failed configuration attempt. Appendix A. Acknowledgements The authors thank Martin Bjorklund for helping specifying the configuration data model in YANG. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[I-D.ietf-ipfix-protocol][RFC5101] Claise, B., "Specification of theIPFIXIP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information",draft-ietf-ipfix-protocol-26 (work in progress), September 2007. [I-D.ietf-ipfix-info]RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export",draft-ietf-ipfix-info-15 (work in progress), February 2007.RFC 5102, January 2008. [I-D.ietf-psamp-protocol] Claise, B., "Packet Sampling (PSAMP) Protocol Specifications",draft-ietf-psamp-protocol-08draft-ietf-psamp-protocol-09 (work in progress),JuneDecember 2007. [I-D.ietf-psamp-info] Dietz, T., Dressler, F., Carle, G., Claise, B., and P. Aitken, "Information Model for Packet Sampling Exports", draft-ietf-psamp-info-07 (work in progress), October 2007.9.2. Informative References[W3C.REC-xml-20040204]Maler, E.,Bray, T.,Paoli, J.,Maler, E., Yergeau, F., Sperberg-McQueen, C., andF. Yergeau,J. Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>. [I-D.bjorklund-netconf-yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-bjorklund-netconf-yang-02 (work in progress), February 2008. 9.2. Informative References [W3C.REC-xmlschema-0-20041028]Walmsley, P. and D.Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [W3C.REC-soap12-part1-20070427]Mendelsohn, N., Karmarkar, A., Moreau, J.,Nielsen, H., Lafon, Y., Hadley, M.,and M.Mendelsohn, N., Moreau, J., Gudgin, M., and A. Karmarkar, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium RecommendationREC-soap12-part1-20070427,REC-soap12-part1- 20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>. [I-D.ietf-ipfix-as] Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12 (work in progress), July 2007. [I-D.ietf-ipfix-architecture] Sadasivan, G., "Architecture for IP Flow Information Export", draft-ietf-ipfix-architecture-12 (work in progress), September 2006. [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-01draft-ietf-ipfix-mib-02 (work in progress),JulyDecember 2007.[I-D.trammell-ipfix-file][I-D.ietf-ipfix-file] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "An IPFIX-Based File Format",draft-trammell-ipfix-file-05draft-ietf-ipfix-file-00 (work in progress),November 2007.January 2008. [I-D.ietf-ipfix-reducing-redundancy] Boschi, E., "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", draft-ietf-ipfix-reducing-redundancy-04 (work in progress), May 2007. [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. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [I-D.dressler-ipfix-aggregation] Dressler, F., Sommer, C., Muenz, G., and A. Kobayashi, "IPFIX Flow Aggregation", draft-dressler-ipfix-aggregation-04 (work in progress), November 2007. [I-D.kobayashi-ipfix-mediator-model] Kobayashi, A., Ishibashi, K., Tsuyoshi, K., and D. Matsubara, "Reference Model for IPFIX Mediators", draft-kobayashi-ipfix-mediator-model-01 (work in progress), November 2007. [I-D.ietf-psamp-framework] Duffield, N., "A Framework for Packet Selection and Reporting", draft-ietf-psamp-framework-12 (work in progress), June 2007. [I-D.ietf-psamp-mib] Dietz, T. and B. Claise, "Definitions of Managed Objects for Packet Sampling", draft-ietf-psamp-mib-06 (work in progress), June 2006. [I-D.ietf-psamp-sample-tech] Zseby, T., "Sampling and Filtering Techniques for IP Packet Selection", draft-ietf-psamp-sample-tech-10 (work in progress), June 2007. [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. [YANG-WEB] Bjoerklund, M., "YANG WebHome", Homepage http://www.yang-central.org, February 2008. Authors' Addresses Gerhard Muenz University of Tuebingen Computer Networks and Internet Sand 13 Tuebingen D-72076 DE Phone: +49 7071 29-70534 Email: muenz@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~muenz Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Full Copyright Statement Copyright (C) The IETF Trust(2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).