Skip to content. Skip to navigation

Portal flowmon

Sections
Personal tools
You are here: Home → FlowMon Probe → Development → Configuration → XML Schema of FlowMon Configuration Data and Statistics
Document Actions

XML Schema of FlowMon Configuration Data and Statistics

by Ladislav Lhotka — last modified 2008-05-08 18:27

This is version 3 of the annotated RELAX NG schema describing the model of FlowMon configuration data and statistics.

This RELAX NG schema defines the data model for configuration data and available statistics of the FlowMon probe. The schema and corresponding XML document instances are supposed to be used in the NETCONF framework. The schema thus follows the requirements and recommendations of the NETCONF drafts where possible. In particular, mixed content (elements interwoven with text) is never used and attributes are reserved for metadata. It is also worth noting that in most cases the order of sibling elements is arbitrary – children within a parent element may appear in any order.

A sample document conforming to this schema is available here: http://www.flowmon.org/flowmon-probe/devel/config/sample-config/

Two namespaces are introduced for target document elements in order to clearly separate device configuration from statistics:

http://cesnet.cz/ns/netopeer/flowmon/3.0

This namespace is used for read-write configuration parameters and enclosing elements.

http://cesnet.cz/ns/netopeer/flowmon/3.0/stats

This namespace marks read-only statistics such as numbers of packets received on an interface and flow records exported to a given collector.

The schema also contains special attributes called hints intended primarily for frontends as an additional information about the data model and semantics. These hints are distinguished by a special namespace with the h prefix. The set of hints is work in progress defined in a separate document

<grammar
    ns="http://cesnet.cz/ns/netopeer/flowmon/3.0"
    datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
    xmlns:h="http://www.liberouter.org/ns/netopeer/hints/1.0"
    xmlns:a="http://www.cesnet.cz/ns/rngrest-annotations/1.0"
    xmlns:st="http://flowmon.org/ns/flowmon/3.0/stats"
    xmlns="http://relaxng.org/ns/structure/1.0">

start

The root element is flowmon. It contains an optional description of the probe and other information that is described below.

<start>
  <element name="flowmon" h:hide="true">
    <ref name="flowmon-content"/>
  </element>
</start>

flowmon-content

At the uppermost level, the data is divided into four parts that are all optional:

  1. The systemInformation element provides basic information about the system in its subelements.
  2. The global element contains global parameters and statistics.
  3. The interfaces element contains configuration of probe interfaces.
  4. Communication with individual collector is configured under the collectors wrapper element.

The pattern is referenced by:

<define name="flowmon-content">
  <interleave>
    <optional>
      <element name="systemInformation">
        <ref name="systemInformation-content"/>
      </element>
    </optional>
    <optional>
      <element name="global">
        <ref name="global-content"/>
      </element>
    </optional>
    <optional>
      <element name="interfaces" h:role="wrapper">
        <zeroOrMore>
          <element name="interface">
            <ref name="interface-content"/>
          </element>
        </zeroOrMore>
      </element>
    </optional>
    <optional>
      <element name="collectors" h:role="wrapper">
        <zeroOrMore>
          <element name="collector">
            <ref name="collector-content"/>
          </element>
        </zeroOrMore>
      </element>
    </optional>
  </interleave>
</define>

systemInformation-content

This element contains optional SNMP-like data providing basic information about the system and also a free-text description.

The pattern is referenced by:

<define name="systemInformation-content">
  <interleave>
    <optional>
      <ref name="description-element"/>
    </optional>
    <optional>
      <ref name="sysName-element"/>
    </optional>
    <optional>
      <ref name="sysContact-element"/>
    </optional>
    <optional>
      <ref name="sysLocation-element"/>
    </optional>
    <optional>
      <ref name="sysUpTime-element"/>
    </optional>
  </interleave>
</define>

sysName-element

This element contains the name of the probe.

The pattern is referenced by:

<define name="sysName-element">
  <element name="sysName">
    <data type="string"/>
  </element>
</define>

sysContact-element

This element identifies the contact person for the probe, typically his or her name and email address.

The pattern is referenced by:

<define name="sysContact-element">
  <element name="sysContact">
    <data type="string"/>
  </element>
</define>

sysLocation-element

This element describes the physical location of the probe.

The pattern is referenced by:

<define name="sysLocation-element">
  <element name="sysLocation">
    <data type="string"/>
  </element>
</define>

sysUpTime-element

This element contains system uptime, i.e., the number of seconds since the probe was last reinitialised.

The pattern is referenced by:

<define name="sysUpTime-element">
  <element name="st:sysUpTime">
    <data type="unsignedInt"/>
  </element>
</define>

global-content

Global section allows for configuring various parameters and operation modes that apply to the probe as a whole. Two of the global parameters – inactive timeout and sample-and-hold rate – may either be set explicitly or left to the experimental adaptive control software. The global content also includes logging options and important firmware and driver statistics.

The pattern is referenced by:

<define name="global-content">
  <interleave>
    <choice>
      <element name="adaptiveControl" h:status="experimental">
        <ref name="adaptiveControl-content"/>
      </element>
      <interleave>
        <optional>
          <ref name="inactiveTimeout-element"/>
        </optional>
        <optional>
          <element name="sampleAndHoldRate" h:status="experimental">
            <ref name="samplingRate-content"/>
          </element>
        </optional>
      </interleave>
    </choice>
    <optional>
      <ref name="activeTimeout-element"/>
    </optional>
    <optional>
      <element name="logging">
        <ref name="logging-content"/>
      </element>
    </optional>
    <optional>
      <ref name="flowsInCache-element"/>
    </optional>
    <optional>
      <ref name="recGenerated-element"/>
    </optional>
    <optional>
      <ref name="recUploaded-element"/>
    </optional>
    <optional>
      <ref name="recOverwritten-element"/>
    </optional>
  </interleave>
</define>

adaptiveControl-content

Adaptive control is an experimental mode in which two parameters – inactive timeout and sample-and-hold rate – are controlled by the probe software with the goal of keeping the two most important operational characteristics below certain limits that are specified here:

  1. Cache occupancy: fraction of the flow cache capacity in percent
  2. Arrival rate of new flows per second: rate with which new entries in the flow cache are being created. In steady state, this is equal to the rate of exported flow records.

The pattern is referenced by:

<define name="adaptiveControl-content">
  <interleave>
    <element name="cacheOccupancyThreshold">
      <data type="positiveInteger"/>
    </element>
    <element name="newFlowRateThreshold">
      <data type="positiveInteger"/>
    </element>
  </interleave>
</define>

activeTimeout-element

This element specifies the active timeout, i.e., the time period after which any flow that is still classified as active must be exported in order to keep the collectors informed about the flow. Active timeout is given in seconds and can be between zero and 1200 (20 min). The default value is 300 (5 minutes).

The pattern is referenced by:

<define name="activeTimeout-element">
  <element name="activeTimeout">
    <data type="nonNegativeInteger">
      <param name="maxInclusive">1200</param>
    </data>
  </element>
</define>

inactiveTimeout-element

This element specifies the inactive timeout in seconds, i.e., the amount of time after which a flow is classified as terminated and exported if no traffic has been seen for that interval. The value is an integer between 0 and 60 and the default is 10 sec.

The pattern is referenced by:

<define name="inactiveTimeout-element">
  <element name="inactiveTimeout">
    <data type="nonNegativeInteger">
      <param name="maxInclusive">60</param>
    </data>
  </element>
</define>

flowsInCache-element

This element gives the current number of entries in the flow cache.

The pattern is referenced by:

<define name="flowsInCache-element">
  <element name="st:flowsInCache">
    <data type="unsignedInt"/>
  </element>
</define>

recGenerated-element

This element gives the number of flow records that were generated by the firmware and offered to the device driver.

The pattern is referenced by:

<define name="recGenerated-element">
  <element name="st:recGenerated">
    <data type="unsignedInt"/>
  </element>
</define>

recUploaded-element

This element gives the number of flow records that were uploaded by the device driver from the firmware buffer.

The pattern is referenced by:

<define name="recUploaded-element">
  <element name="st:recUploaded">
    <data type="unsignedInt"/>
  </element>
</define>

recOverwritten-element

This element gives the number of flow records that the applications (exporters) were not able to take from the driver's circular buffer and that were later overwritten by new flows and thus lost.

The pattern is referenced by:

<define name="recOverwritten-element">
  <element name="st:recOverwritten">
    <data type="nonNegativeInteger">
      <param name="maxInclusive">16384</param>
    </data>
  </element>
</define>

logging-content

The destination for the logging output and the level of detail for the logging messages is also specified here. Previously configured logging can also be explicitly disabled by setting the disabled subelement to true (default is false).

The pattern is referenced by:

<define name="logging-content">
  <interleave>
    <optional>
      <ref name="disabled-element"/>
    </optional>
    <optional>
      <element name="logDestination" h:display="Destination">
        <ref name="logDestination-content"/>
      </element>
    </optional>
    <optional>
      <element name="logLevel" h:display="Level">
        <ref name="logLevel-content"/>
      </element>
    </optional>
  </interleave>
</define>

logDestination-content

The default destination for logging messages is the system console. Alternatively, logging messages can be written to a given file or sent via syslog to a specified host.

The pattern is referenced by:

<define name="logDestination-content">
  <choice>
    <value>console</value>
    <element name="file">
      <ref name="file-name-content"/>
    </element>
    <element name="syslogHost">
      <ref name="ip-or-name-content"/>
    </element>
  </choice>
</define>

logLevel-content

This element specifies the available levels of logging messages that are given below with decreasing severity. Each level also automatically includes all higher levels.

The pattern is referenced by:

<define name="logLevel-content">
  <choice>
    <value>emerg</value>
    <value>alert</value>
    <value>crit</value>
    <value>err</value>
    <value>warn</value>
    <value>notice</value>
    <value>info</value>
    <value>debug</value>
  </choice>
</define>

interface-content

The FlowMon probe has two types of interfaces: 0 and 1 are monitoring interfaces that also act as an Ethernet repeater. The remaining two interfaces – 2 and 3 – may be used for optional traffic mirroring. Packets received on interface 0 are then sent not only to interface 1 (this is the standard repeater function), but also to interface 2. Similarly, traffic arriving on interface 1 can be mirrored to interface 3.

The pattern is referenced by:

<define name="interface-content">
  <interleave>
    <choice>
        <ref name="monitoring-interface-content"/>
        <ref name="mirroring-interface-content"/>
    </choice>
  </interleave>
</define>

monitoring-interface-content

Monitoring interfaces 0 and 1 can be disabled by setting the value of the disabled element to true (by default it is false). Further, sampling parameters can be specified. Per interface packet statistics are also available.

The pattern is referenced by:

<define name="monitoring-interface-content">
  <interleave>
    <ref name="ifNumber-monitoring-element"/>
    <ref name="common-interface-content"/>
    <optional>
      <element name="inputSampling">
        <ref name="inputSampling-content"/>
      </element>
    </optional>
    <optional>
      <ref name="ifInPackets-element"/>
    </optional>
    <optional>
      <ref name="ifInErrors-element"/>
    </optional>
    <optional>
      <ref name="ifInDiscards-element"/>
    </optional>
  </interleave>
</define>

mirroring-interface-content

Content for mirroring interfaces 2 and 3. As opposed to the monitoring interfaces 0 and 1, the default value for disabled-element is true, i.e., no mirroring.

The pattern is referenced by:

<define name="mirroring-interface-content">
  <ref name="ifNumber-mirroring-element"/>
  <ref name="common-interface-content"/>
</define>

ifNumber-monitoring-element

Probe interfaces 0 and 1 are used for traffic monitoring.

The pattern is referenced by:

<define name="ifNumber-monitoring-element">
  <element name="ifNumber">
    <choice>
      <value>0</value>
      <value>1</value>
    </choice>
  </element>
</define>

ifNumber-mirroring-element

Probe interfaces 2 and 3 can be configured to mirror the traffic from monitoring interfaces 0 and 1, respectively.

The pattern is referenced by:

<define name="ifNumber-mirroring-element">
  <element name="ifNumber">
    <choice>
      <value>2</value>
      <value>3</value>
    </choice>
  </element>
</define>

common-interface-content

Common content for monitoring and mirroring interfaces.

The pattern is referenced by:

<define name="common-interface-content">
  <interleave>
    <optional>
      <ref name="disabled-element"/>
    </optional>
    <optional>
      <ref name="linkRate-element"/>
    </optional>
    <optional>
      <ref name="ifOperStatus-element"/>
    </optional>
  </interleave>
</define>

disabled-element

The value of this element determines whether the parent object or feature is disabled.

The pattern is referenced by:

<define name="disabled-element">
  <element name="disabled">
    <data type="boolean"/>
  </element>
</define>

inputSampling-content

Two parameters for input sampling can be configured: sampling method and sampling rate.

The pattern is referenced by:

<define name="inputSampling-content">
  <optional>
    <ref name="samplingMethod-element"/>
  </optional>
  <element name="samplingRate">
    <ref name="samplingRate-content"/>
  </element>
</define>

samplingMethod-element

One of the following two methods for input sampling can be selected (r is the input sampling rate):

regular
Every r-th packet is selected from the input stream.
statistical
Each packet is selected with probability 1/r.

The pattern is referenced by:

<define name="samplingMethod-element">
  <element name="samplingMethod">
    <choice>
      <value>regular</value>
      <value>statistical</value>
    </choice>
  </element>
</define>

linkRate-element

This element specifies the link rate in megabits per second. By default, the link rate is auto-negotiated.

The pattern is referenced by:

<define name="linkRate-element">
  <element name="linkRate">
    <choice>
      <value>10</value>
      <value>100</value>
      <value>1000</value>
      <value>10000</value>
    </choice>
  </element>
</define>

ifOperStatus-element

This element indicates whether the parent interface is operational.

The pattern is referenced by:

<define name="ifOperStatus-element">
  <element name="st:ifOperStatus">
    <choice>
      <value>up</value>
      <value>down</value>
    </choice>
  </element>
</define>

ifInPackets-element

This element gives the number of packets that the input buffer passed to the flow classification engine.

The pattern is referenced by:

<define name="ifInPackets-element">
  <element name="st:ifInPackets">
    <data type="unsignedInt"/>
  </element>
</define>

ifInErrors-element

This element gives the number of inbound packets that contained errors.

The pattern is referenced by:

<define name="ifInErrors-element">
  <element name="st:ifInErrors">
    <data type="unsignedInt"/>
  </element>
</define>

ifInDiscards-element

This element number of inbound packets that were discarded even though no error was detected, either due to input sampling or input buffer overflow.

The pattern is referenced by:

<define name="ifInDiscards-element">
  <element name="st:ifInDiscards">
    <data type="unsignedInt"/>
  </element>
</define>

samplingRate-content

This pattern specifies the sampling rate for hardware sampling. It is used either for statistical sampling that is configured separately for each input interface, or for sample-and-hold that is configured globally. In the latter case the flows that are present in the flow cache are protected from sampling – only packets belonging to "unknown" flows are sampled with the configured rate.

Sampling rate must be an integer between 1 and 65535. The default is 1 (no sampling).

The pattern is referenced by:

<define name="samplingRate-content">
  <data type="positiveInteger">
      <param name="maxInclusive">65535</param>
    </data>
</define>

collector-content

Every collector must be identified by its IP address or hostname and UDP port for receiving flow record packets. The other subelements are optional.

Note that the group element enclosing the host and udpPort element patterns has two hint attributes:

  • h:role="key" indicates that the values of both host and udpPort are to be used as a unique key identifying the collector.
  • h:join=":" specifies that the values of host and udpPort should be rendered together, separated by a colon.

Further, the export protocol must be specified.

For each collector, flowFilter element can be used to restrict the flow records that are sent to the collector based on several criteria. By default, i.e., when the flowFilter element is not included, all flows are sent to the collector.

Anonymisation changes one or both IP addresses in the exported flows (typically for privacy reasons). One of the two supported algorithms for address mangling may be specified under the anonymisation element.

Per-collector statistics of exported records are also available.

Finally, a short description of the collector can be included in the description element.

The pattern is referenced by:

<define name="collector-content">
  <interleave>
    <group h:role="key" h:join=":">
      <element name="host">
        <ref name="ip-or-name-content"/>
      </element>
      <element name="udpPort" h:display="UDP port">
        <data type="positiveInteger">
          <param name="maxInclusive">65535</param>
        </data>
      </element>
    </group>
    <ref name="exportProtocol-choice"/>
    <optional>
      <element name="flowFilter">
        <ref name="flowFilter-content"/>
      </element>
    </optional>
    <optional>
      <element name="anonymisation">
        <ref name="anonymisation-content"/>
      </element>
    </optional>
    <optional>
      <ref name="recExported-element"/>
    </optional>
    <optional>
      <ref name="description-element"/>
    </optional>
  </interleave>
</define>

recExported-element

This element gives the number of flow records exported to a given collector.

The pattern is referenced by:

<define name="recExported-element">
  <element name="st:recExported">
    <data type="unsignedInt"/>
  </element>
</define>

exportProtocol-choice

Three export protocols are currently supported – Cisco NetFlow versions 5 and 9, and IPFIX. For NetFlow v9 and IPFIX, additional parameters can be specified.

The pattern is referenced by:

<define name="exportProtocol-choice">
  <choice>
    <element name="exportProtocol">
      <value type="token">netflow-v5</value>
    </element>
    <interleave>
      <element name="exportProtocol">
        <choice>
          <value type="token">netflow-v9</value>
          <value type="token">ipfix</value>
        </choice>
      </element>
      <ref name="v9-and-ipfix-content"/>
    </interleave>
  </choice>
</define>

v9-and-ipfix-content

Netflow v9 and IPFIX exporters must periodically send the templates to the collectors. The templateSendPeriod element defines the period in seconds. The default is 60 (1 minute).

The pattern is referenced by:

<define name="v9-and-ipfix-content">
  <optional>
    <element name="templateSendPeriod" h:display="Template timeout">
      <data type="nonNegativeInteger"/>
    </element>
  </optional>
</define>

anonymisation-content

Addresses may be anonymised using one of the following approaches:

  1. Simple rewrite changes high-order bits in the IP address to a given prefix.
  2. AES Encryption modifies selected fields in the IP header using the AES block cipher.

Method 2 can be used for both IPv4 and IPv6, whereas 1 is limited to IPv4.

The pattern is referenced by:

<define name="anonymisation-content">
  <choice>
    <element name="simpleRewrite">
      <ref name="simpleRewrite-content"/>
    </element>
    <element name="encryptAES">
      <ref name="encryptAES-content"/>
    </element>
  </choice>
</define>

simpleRewrite-content

The maskPrefix element gives the IP prefix that will replace corresponding high-order bits in the anonymised address. The default is 192.168.0.0/16. The applyTo element specifies whether anonymisation is to be applied to the source or destination address, or both addresses (default).

The pattern is referenced by:

<define name="simpleRewrite-content">
  <interleave>
    <element name="maskPrefix">
      <ref name="prefix-content"/>
    </element>
    <optional>
      <element name="applyTo">
        <ref name="address-choice"/>
      </element>
    </optional>
  </interleave>
</define>

encryptAES-content

The initialisation element specifies how the AES cipher should be initialised. If it is absent, no initialisation is performed. The applyTo element selects the fields in the IP header that will be encrypted. By default, both IP addresses are encrypted.

The pattern is referenced by:

<define name="encryptAES-content">
  <interleave>
    <optional>
      <element name="initialisation">
        <ref name="initialisation-content"/>
      </element>
    </optional>
    <optional>
      <element name="applyTo">
        <ref name="AES-applyTo-content"/>
      </element>
    </optional>
  </interleave>
</define>

initialisation-content

The AES algorithm can be initialised from the system clock, or left uninitialised.

The pattern is referenced by:

<define name="initialisation-content">
  <choice>
    <value>clock</value>
    <value>none</value>
  </choice>
</define>

AES-applyTo-content

Any subset of the following four IP header fields may be selected for AES encryption: source IP address, destination IP address, source port and destination port.

The pattern is referenced by:

<define name="AES-applyTo-content">
  <interleave>
    <optional>
      <element name="sourceIpAddress">
        <empty/>
      </element>
    </optional>
    <optional>
      <element name="destinationIpAddress">
        <empty/>
      </element>
    </optional>
    <optional>
      <element name="sourcePort">
        <empty/>
      </element>
    </optional>
    <optional>
      <element name="destinationPort">
        <empty/>
      </element>
    </optional>
  </interleave>
</define>

flowFilter-content

A flow filter consists of a sequence of conditions. Every flow is checked against these conditions and must satisfy at least one of them in order to be exported to the particular collector. If no conditions are specified, no flows are exported.

The pattern is referenced by:

<define name="flowFilter-content">
  <zeroOrMore>
    <element name="filterCondition">
      <ref name="filterCondition-content"/>
    </element>
  </zeroOrMore>
</define>

filterCondition-content

A filter condition may specify any of the following two criteria. Both of them must be satisfied (if both are specified), otherwise the flow record is dropped.

  1. Either IP version or IP address range: In the former case, flow must be of the given IP version. In the latter case, flow's source or destination address (or both) must fall into the given address range (IP version is implied in this case).
  2. Input interface: packets belonging to the flow must have arrived from the given (monitoring) interface.

The pattern is referenced by:

<define name="filterCondition-content">
  <interleave>
    <optional>
      <choice>
      <ref name="ipVersion-element"/>
      <element name="addressRange">
        <ref name="addressRange-content"/>
      </element>
      </choice>
    </optional>
    <optional>
      <ref name="ifNumber-monitoring-element"/>
    </optional>
  </interleave>
</define>

ipVersion-element

The pattern is referenced by:

<define name="ipVersion-element">
  <element name="ipVersion">
    <choice>
      <value>4</value>
      <value>6</value>
    </choice>
  </element>
</define>

addressRange-content

The subset of flows to be included is defined by a contiguous range of IP addresses. The first address in the range is given by the startAddress and the last one by endAddress.

The optional matchAgainst element determines whether source or destination IP address, or both addresses are matched against the address range.

If the matchAgainst element is omitted, both addresses are matched by default.

The pattern is referenced by:

<define name="addressRange-content">
  <interleave>
    <element name="startAddress" h:display="Start">
      <ref name="ip-address-content"/>
    </element>
    <element name="endAddress" h:display="End">
      <ref name="ip-address-content"/>
    </element>
    <optional>
      <element name="matchAgainst">
        <ref name="address-choice"/>
      </element>
    </optional>
  </interleave>
</define>

address-choice

This pattern allows to specify source or destination IP address, or both.

The pattern is referenced by:

<define name="address-choice">
  <interleave>
    <optional>
      <element name="sourceIpAddress">
        <empty/>
      </element>
    </optional>
    <optional>
      <element name="destinationIpAddress">
        <empty/>
      </element>
    </optional>
  </interleave>
</define>

description-element

This element contains free text description of its parent object.

The pattern is referenced by:

<define name="description-element">
  <optional>
    <element name="description">
      <text/>
    </element>
  </optional>
</define>

file-name-content

Data type for file names. Some structure can be added later.

The pattern is referenced by:

<define name="file-name-content">
  <data type="token"/>
</define>

domain-name-content

This data type represents a DNS domain name as per RFC 1034 and 1123.

The pattern is referenced by:

<define name="domain-name-content">
  <data type="token">
    <param name="maxLength">255</param>
    <param name="pattern">([A-Za-z0-9]([-A-Za-z0-9]{0,61}[A-Za-z0-9])?\.)*[A-Za-z0-9]([-A-Za-z0-9]{0,61}[A-Za-z0-9])?\.?</param>
  </data>
</define>

ipv4-address-content

This data type defines the IPv4 address in the usual dotted quad notation using a regular expression pattern.

The pattern is referenced by:

<define name="ipv4-address-content">
  <data type="token">
    <param name="pattern">((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])</param>
  </data>
</define>

ipv6-address-content

This data type represents the IPv6 address in one of the three textual formats defined in RFC 4291 (full, shortened and mixed).

The pattern is referenced by:

<define name="ipv6-address-content">
  <choice>
    <data type="token">
      <param name="pattern">([0-9a-fA-F]{0,4}:){0,7}[0-9a-fA-F]{0,4}</param>
      <param name="pattern">(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?</param>
    </data>
    <data type="token">
      <param name="pattern">([0-9a-fA-F]{0,4}:){0,6}((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9]).){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])</param>
      <param name="pattern">(([0-9a-fA-F]+:){6}|(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::([0-9a-fA-F]+:)*)((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9]).){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])</param>
    </data>
  </choice>
</define>

ip-address-content

This data type allows an IP address of either IPv4 or IPv6.

The pattern is referenced by:

<define name="ip-address-content">
  <choice>
    <group>
      <attribute name="content-type">
        <value>ipv4</value>
      </attribute>
      <ref name="ipv4-address-content"/>
    </group>
    <group>
      <attribute name="content-type">
        <value>ipv6</value>
      </attribute>
      <ref name="ipv6-address-content"/>
    </group>
  </choice>
</define>

prefix-content

This data type represents and IP prefix, i.e., a block of high-order bits taken from IPaddress. The number of bits in the block is given by length.

The pattern is referenced by:

<define name="prefix-content">
  <group h:join="/">
    <element name="IpAddress">
      <ref name="ip-address-content"/>
    </element>
    <optional>
      <element name="length">
        <data type="nonNegativeInteger"/>
      </element>
    </optional>
    </group>
</define>

ip-or-name-content

This data type allows either a DNS host name or IP address (v4 or v6).

The pattern is referenced by:

<define name="ip-or-name-content">
  <choice>
    <group>
      <attribute name="content-type">
        <value>ipv4</value>
      </attribute>
      <ref name="ipv4-address-content"/>
    </group>
    <group>
      <attribute name="content-type">
        <value>ipv6</value>
      </attribute>
      <ref name="ipv6-address-content"/>
    </group>
    <group>
      <attribute name="content-type">
        <value>name</value>
      </attribute>
      <ref name="domain-name-content"/>
    </group>
  </choice>
</define>