Internet DRAFT - draft-irtf-nmrg-location-ipfix
draft-irtf-nmrg-location-ipfix
Network Management Research Group O. Festor
Internet-Draft Inria
Intended Status: Informational A. Lahmadi
Expires: May 3, 2017 University of Lorraine - LORIA
R. Hofstede
A. Pras
University of Twente
October 30, 2016
Extending IP Flow-Based Network Monitoring with Location Information
draft-irtf-nmrg-location-ipfix-07
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 3, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
FESTOR, et al. Expires May 3, 2017 [Page 1]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Abstract
IP Flow-based monitoring lacks a mechanism to associate measured IP
Flow information with the geographic location of the device where the
IP Flows have been observed. This document defines a set of
guidelines and best practices to extend IP Flow monitoring protocols
with location information of the device (both fixed and mobile) that
acts as an IP Flow metering process.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Relationships with IPFIX and GEOPRIV . . . . . . . . . . . . . 4
3. Location Information specifications . . . . . . . . . . . . . . 5
3.1. Geospatial Location Information . . . . . . . . . . . . . . 5
3.2. Civic Location Information . . . . . . . . . . . . . . . . 5
4. Extending Metering Processes with Location Information . . . . 6
4.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Enabling Location Extensions . . . . . . . . . . . . . . . . 7
4.3 Flow Expiration Management . . . . . . . . . . . . . . . . . 8
4.4 The Collecting Process's Side . . . . . . . . . . . . . . . 8
5. Security and Privacy Considerations . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Location method numeric values . . . . . . . . . . . . . . . 9
6.2 Location Information Elements . . . . . . . . . . . . . . . 10
Appendix A. IPFIX Location Information Elements . . . . . . . . . 11
A.1. geospatialLocationCRSCode . . . . . . . . . . . . . . . . . 11
A.2. geospatialLocationLat . . . . . . . . . . . . . . . . . . . 11
A.3. geospatialLocationLng . . . . . . . . . . . . . . . . . . . 11
A.4. geospatialLocationAlt . . . . . . . . . . . . . . . . . . . 11
A.5. geospatialLocationRadius . . . . . . . . . . . . . . . . . 12
A.6. civicLocationType . . . . . . . . . . . . . . . . . . . . . 12
A.7. civicLocationValue . . . . . . . . . . . . . . . . . . . . 12
A.8. locationMethod . . . . . . . . . . . . . . . . . . . . . . 12
A.9. locationTime . . . . . . . . . . . . . . . . . . . . . . . 13
A.10. deviceId . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Recommended IPFIX Templates for Location Export . . . 14
B.1. Geospatial Point Location Template . . . . . . . . . . . . 14
B.2. Geospatial Circle Location Template . . . . . . . . . . . . 15
B.3. Geospatial List Template . . . . . . . . . . . . . . . . . 16
B.4. Civic Location Template . . . . . . . . . . . . . . . . . . 17
B.5. Compound Location Template . . . . . . . . . . . . . . . . 19
Appendix C. Example Implementation . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . . . . 22
Informative References . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 24
FESTOR, et al. Expires May 3, 2017 [Page 2]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The importance of geographic location information on the Internet is
growing rapidly. It can be used for business advertisements,
admission control and security analysis, for example. Most mobile
devices, such as smart phones, tablets and sensors, have capabilities
for determining and exposing their geographic location. Besides that,
they are accountable for an increasing share of the overall network
traffic. In contrast to fixed devices, which usually have their
physical location configured in a static manner, mobile devices can
exploit several location systems for obtaining their location. This
type of information is already used by a wide range of applications
and services, such as navigation systems and friend finder services.
Relating the location information of a device to this network traffic
can be beneficial to many network management and measurement
applications, including traffic profiling, anomaly detection and
provider-independent network measurements. Hence, exporting location
information associated to traffic Flows is desirable in various
situations.
Several IP Flow-based monitoring protocols such as the IPFIX protocol
[RFC7011] have been designed for the purpose of exporting IP traffic
Flows based on Information Elements. This document defines a set of
guidelines that provide a means for Metering Processes to encapsulate
location information within exported Flows. This will be done by
relying on existing location information formats, as they have been
developed in other standardization areas for encoding civic
locations, geographic coordinates, etc. Several examples including
the required set of Information Elements and templates for the IPFIX
protocol are given that are suitable for encapsulating pre-existing
location information data.
1.1. Motivation
A typical IP Flow Metering Process is used for aggregating IP traffic
and related measurement data into Flow Records at a fixed Observation
Point. After expiration, Flow Records are sent to a Flow Collector
for storage and analysis. The collected information is typically
represented in a purely time-based manner, which means that Flow
Records provide an aggregated view on network traffic over time.
However, when Metering Processes are running on devices with a
(frequently) changing physical location, data analysis applications
may need to be aware of these movements since they are likely to
affect the behavior of the network in terms of routing, throughput,
etc. An example scenario is a virtualized environment, where virtual
FESTOR, et al. Expires May 3, 2017 [Page 3]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
machines change location during migration from one server to another,
or even between data centers. Thus, a location-aware metering process
will be able to associate their Flows to their current locations.
In fact, we are not dealing anymore with Flows associated to a fixed
Observation Point, but with a multitude of sub-Flows for which the
Observation Point locations have to be reported. To facilitate this,
location information needs to be obtained and processed by the
Metering Process in an IP Flow Exporter. In the end, it will be
beneficial when network management applications are able to relate
service quality parameters to location changes, instead of assuming a
single location for all observed parameters.
1.2. Terminology
This document relies on on the definitions of IP The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
2. Relationships with IPFIX and GEOPRIV
The IPFIX protocol [RFC7011] and its information model [RFC7012] are
the IETF standards for IP Flow-based network monitoring, developed by
the IPFIX working group to transfer IP flow data from exporters to
collectors. In this document, we rely on the IPFIX terminology and
its information model to illustrate how to export location
information of a Metering Process to Collecting Process. Within the
IPFIX architecture as defined in [RFC5470], in this document we are
providing guidelines for developers to extend Metering Processes with
capabilities to include location information in data records to be
passed to an Exporting Process before being sent to a Collecting
Process.
Associating geographic location information with network traffic on
the Internet has been addressed by the GEOPRIV working group. There,
a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option
containing civic address information has been specified in [RFC4776].
A similar option for geospatial information has been defined in
[RFC6225]. The group has also defined a set of requirements to be
respected when collecting and using Location Objects related to a
specific user [RFC3693]. These requirements include usage policies
and privacy preferences associated to the Location Object as
expressed by a user. All the security and privacy requirements
defined in [RFC3693] concern location data collection, and usage MAY
be applied to the IPFIX protocol when conveying location information.
The GEOPRIV working group has extended the XML-based Presence
FESTOR, et al. Expires May 3, 2017 [Page 4]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Information Data Format in [RFC5491], to allow the encapsulation of
location information within a presence document.
3. Location Information specifications
The location of a device can generally be defined in two ways, namely
by geospatial location coordinates and civic location information.
Geospatial location coordinates are made up of latitude, longitude
and altitude coordinates, while civic location information
encompasses abstract notions of a location, such as "in the kitchen",
"in Bakerstreet" or "in a train approaching Nancy, France". The usage
of these two types of location representations are addressed by the
GEOPRIV group in [RFC5491] and [RFC5139], respectively. This document
assumes that devices use one or more existing mechanisms for the
purpose of retrieving location information and therefore does not
define any new mechanisms for location retrieval.
3.1. Geospatial Location Information
To obtain geospatial location information, one needs to rely on a
numeric coordinate system. Such systems provide location information
either in two dimensions (latitude and longitude) or three dimensions
(latitude, longitude and altitude). Relying on a single point of
location is normally not considered sufficient, since an area or
volume of uncertainty SHALL be specified. In theory, this area or
volume represents a coverage in which the device has a high
probability of being found, and the point is the centroid for the
area or volume. In [GeoShape] a set of geometric areas and volumes
has been specified to define a location with uncertainty. A standard
set of Coordinate Reference Systems (CRS) and units of measure are
also specified in [GeoShape]. Implementations MUST specify distances
and heights in meters as defined in EPSG 9001. Angular measures MUST
be specified using degrees as identified by the EPSG 9102 code. The
values of EPSG codes can be resolved by using the CRS Registry
Service operated by the Oil and Gas Producers Association [OGP].
3.2. Civic Location Information
In contrast to geospatial location information, which relies on
numeric data formats, the civic location format conveys pure textual
information. It is applicable to device locations in buildings, for
example. It MAY be a civic address closely related to a postal
address, commonly used by local postal services for delivering mail.
It MAY also be some approximated information, such as "living room",
"Office 123 in Building 2". The civic location information format has
been addressed in [RFC4776], where a set of parameters are provided
to describe civic locations. In contrast to geospatial location
FESTOR, et al. Expires May 3, 2017 [Page 5]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
information, which is the geospatial location of the device as a set
of latitude, longitude and altitude coordinates represented by a CRS,
civic location information can often be interpreted even if
incomplete. For example, while geospatial information is not
available inside buildings, civic location information can still
provide an estimation of a device's location.
4. Extending Metering Processes with Location Information
This section specifies how to carry the location information of the
device acting as an IP Flow Exporter from the Metering Process to the
Collecting Process, to associate the IP Flow information with the
location where the flows are measured. The provided specifications
SHALL be used by developers to extend a Metering Process for
constructing and sending template and data records including location
information to a Collecting Process.
4.1 Applicability
Extending Metering Processes to include location information in data
records with respect to a certain template is applicable to cases
where management applications require knowing the location of the
device acting as an IP Flow Exporter. A typical example is a mobile
device changing its location while exporting IP Flow records. This
method requires that the Metering Process is able to obtain location
information of the device using one or several localization methods
(GPS, Network, Cell, DHPCP, etc.), as defined in section 6.
Associating location information with measured IP Flow information is
an interesting feature for several network management applications
(e.g., accounting, traffic profiling, traffic engineering, QoS
monitoring, attack/intrusion detection) as specified in [RFC3917].
Location data records provide space dimension to these applications,
in addition to the traditional time and volume dimensions provided by
IP Flow measurements. Currently, usage-based accounting for IP
services relies on time or volume. Besides that, accounting can be
performed per location when enabling location information in Metering
Processes. For the case of traffic profiling, providing the location
of traffic measurements is useful for network planning, dimensioning
activities and traffic engineering methods, for example. Typically,
the traffic distribution is characterized by using parameters of
flows in a specific location. Associating Flow information with their
measurement geographic locations will also enable security
applications to detect anomalous activities. In the case of mobile
devices, the characterization of communication patterns using only
time and volume is not enough to detect unusual location-related
communication patterns. For example, a mobile device has a specific
communication pattern at each location and when the location changes
FESTOR, et al. Expires May 3, 2017 [Page 6]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
the communication pattern changes also. If the device is attacked the
communication pattern in respect with the device location is unusual
that will be easily detected by the security monitoring application.
However, this unusual communication pattern over device locations
becomes usual over time since it has been observed before. QoS
monitoring applications will also benefit from the availability of
location information provided by the Metering Process since it will
allow them correlating quality parameters of IP Flows with respect to
their measurement location. Thus, fine-grained QoS parameters can be
validated and analyzed. For example, a QoS monitoring application
will be able to correlate IP Flow, their delays and their locations.
4.2 Enabling Location Extensions
Before enabling location extensions in data records, the Metering
Process SHOULD check if a localization method that provides location
information is available on the device. The available location
information MUST describe a discrete location defined as a place,
point or area in which a Metering Process (i.e., IPFIX Flow Exporter)
can be found. In situations where a discrete location can be
described in multiple ways, each location SHOULD be described by
means of a separate Template following the terminology specified in
[RFC7012]. A compound Template containing a subTemplateMultiList
field as specified in [RFC6313] SHOULD be used in which each top-
level element corresponds to a different location Template. For
example, the location of a device being at the fifth floor of a
particular building can be described using both a geospatial point
(the geographic location of the building) and civic information
(fifth floor of a building). Exporting more than one location in a
Flow Record MUST only be done if the different location descriptions
refer to different places. Each time a different type of location
data is available to the Metering Process and needed to be sent, the
Flow Exporter MUST send the template of the new location format to
the Collecting Process.
When several localization methods are available on the device, the
Metering Process SHALL select one or several among them. If the
available methods provide the same type of location information, it
selects only a single method. The selected method is the one with the
highest accuracy. According to the accuracy of the method, the
Metering Process MUST use the appropriate template and the
Information Elements from the set of recommended templates and
Information Elements specified in Appendixes A and B. We have to note
that other criteria MAY be used to select the localization method.
For example, in a mobile device where saving energy is important (due
to power constraints, for example), the Metering Process MAY select
FESTOR, et al. Expires May 3, 2017 [Page 7]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
the less power-consuming method. Specifically, a network-based method
is typically less power-consuming than a GPS-based localization
method. Configuration options MAY also be available on the Metering
Process to configure the location method to be used according to the
requirements of the management application.
When one or several localization methods are selected and activated,
the Metering process is able to include location information in data
records. When an IP Flow is observed by the Metering Process,
location information is derived and included in a data record using
an appropriate template that SHOULD be sent to the Collecting Process
before sending the location data records. The Metering process should
be configured to associate a single or multiple location information
to each observed IP Flow.
A single location information is derived by the Metering Process
either at the time of the first observed packet of the IP Flow or at
the time of the last observed packet of the IP Flow. Then, a location
data record containing a single location information is built and
passed to the Exporting Process. Multiple location information are
derived by the Metering Process during the time interval of the
observation of the IP Flow. The multiple location information MAY be
derived at different time scales. Metering Processes MAY associate
two location information, one at the starting time of the observed
Flow and the second at the ending time of the Flow. It MAY also
sample several information location to be associated with the
observed IP Flow.
4.3 Flow Expiration Management
With the current IPFIX specifications, the Metering Process expires
active Flows under several conditions as described in Section 5.1.1
of [RFC5470]. When the Metering Process enables location information
to be associated to observed IP flows and according to the management
application requirements, it MAY consider location or distance
information for determining whether a flow has to be expired. For
example, a Metering Process MAY expire Flows when the device changes
its location. For long-running Flows, the Metering Process may use a
distance-based expiration policy, such as expiring a Flow upon a
configured distance value in meters. In case location information
becomes unavailable on the device, the Metering Process SHOULD expire
all running Flows to be able to resend the set of templates as
described in Section 4.4.
4.4 The Collecting Process's Side
As specified in [RFC5101], the Exporting Process SHOULD transmit the
required set of templates specific to location information in advance
FESTOR, et al. Expires May 3, 2017 [Page 8]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
to the Collecting Process, before sending any data records including
location data. When the Metering Process is not able to access a
localization method or no method is available to obtain such
information, it MUST stop resending to the Collection Process
location related templates.
5. Security and Privacy Considerations
This document proposes a set of Information Elements and guidelines
for exporting location information using the IPFIX protocol. We
recognize the privacy sensitivity of exporting such information and
advocate the use of measures to protect individual's privacy. Several
documents have addressed security and privacy in the context of the
Internet in general and IPFIX in particular. First, the use of
location information has been discussed in "GeoPriv Requirements"
[RFC3693], while threats facing protocols that carry location
information are detailed in [RFC3694]. Second, when carrying location
information in IPFIX Information Elements, all Messages exchanged
between Exporting and Collecting Processes SHOULD be signed and
encrypted using Transport Layer Security (TLS) or Datagram Transport
Layer Security (DTLS) protocols, as specified in [RFC7011]. Another
approach is the use of a secure, underlying communication channel for
transporting IPFIX Messages in case the aforementioned transports are
unavailable. Third, support for Flow Record anonymization, as
expressed in [RFC6235], is strongly recommended, since the
dissemination of Flow Records including location information raises
greater privacy issues than the dissemination of regular Flow
Records.
Preserving the privacy of users SHOULD be addressed by applications
using collected monitoring data. We note that collecting and
exporting location information associated with information that is
able to identify individual by means of their IP addresses, may be
illegal or require special clearance in certain jurisdictions.
6. IANA Considerations
This document specifies several new IPFIX Information Elements and
types that need to be registered with IANA.
6.1 Location method numeric values
This document requests that the IANA adds a new column to its
registry for location 'method' tokens defined in [RFC4119] (Section
6.1), to facilitate the association of numeric values to these
'method' tokens. The numeric values are used by the Information
Element 'localtionMethod', as specified in Section A.8 of this
FESTOR, et al. Expires May 3, 2017 [Page 9]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
document. The numeric values of the registered 'method' tokens are
attributed with the IANA on a next available integer basis. An
example of registered 'method' tokens and their provisional numeric
values is provided below.
+--------+--------------+----------------------------------------+
| Number | Method | Description |
+--------+--------------+----------------------------------------+
|0 | GPS | Global Positioning System |
|1 | A-GPS | GPS with assistance |
|2 | Manual | Entered manually by a user |
|3 | DHCP | Provided by DHCP |
|4 | Triangulation| Triangulated from time-of-arrival, |
| | | signal strength or similar measurement |
|5 | Cell | Location of the cellular radio antenna |
|6 | 802.11 | IEEE 802.11 access point location |
+--------+--------------+----------------------------------------+
6.2 Location Information Elements
This document requests that the IANA registers the set of Information
elements listed in Appendix A in the IANA IPFIX Information Element
registry. Registrations of these new Information Elements MUST be
reviewed by a designated group of experts (IE-DOCTORS), appointed by the
IESG, as indicated in [RFC7013].
FESTOR, et al. Expires May 3, 2017 [Page 10]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Appendix A. IPFIX Location Information Elements
This appendix contains a set of IPFIX Information Elements that can be
used for exporting location-related information of a Metering Process.
They SHALL be used for exporting geospatial and civic location, together
with IPFIX Information Elements already defined in [RFC7012] for
exporting IP traffic Flows.
A.1. geospatialLocationCRSCode
Description: Denotes the Coordinate Reference System (CRS) codes
according to which the location coordinates are organized and
related to the real world, as specified in [GEOSHAPE]. In this
document we mandate the use of the World Geodetic System 1984
(WGS84) [WGS84] coordinate reference system and the usage of the
European petroleum survey group (EPSG) code 4326 for two-
dimensional (2D) shape representations and EPSG 4979 for three-
dimensional (3D) volume representations.
Data Type: unsigned16
Data Type Semantics: identifier
PEN (provisional): 12559 (Inria)
ElementId: 401
A.2. geospatialLocationLat
Description: Denotes the coordinate information value of the
latitude.
Data Type: float64
PEN (provisional): 12559 (Inria)
ElementId (provisional): 402
A.3. geospatialLocationLng
Description: Denotes the coordinate information value of the
longitude.
Data Type: float64
PEN (provisional): 12559 (Inria)
ElementId (provisional): 403
A.4. geospatialLocationAlt
Description: Denotes the coordinate information value of the
altitude.
Data Type: float64
FESTOR, et al. Expires May 3, 2017 [Page 11]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
PEN (provisional): 12559 (Inria)
ElementId (provisional): 404
A.5. geospatialLocationRadius
Description: Denotes a radius value (in meters) of a location
described using a circular area in a two-dimensional CRS or
a sphere shape in a three-dimensional CRS.
Data Type: float32
Data Type Semantics: quantity
PEN (provisional): 12559 (Inria)
ElementId (provisional): 405
A.6. civicLocationType
Description: Denotes the civic location information type as
specified in [RFC4776].
Data Type: unsigned8
PEN (provisional): 12559 (Inria)
ElementId (provisional): 406
A.7. civicLocationValue
Description: Denotes a civic location information element that MUST
be encoded as a UTF-8 string. The location information MAY be a
civic address as specified in [RFC4776] or information on
proximity to known objects.
Data Type: string
PEN (provisional): 12559 (Inria)
ElementId (provisional): 407
A.8. locationMethod
Description: Denotes the way in which the location information has
been obtained. The locationMethod sub-registry is defined in
Section 6.1.
Data Type: unsigned8
Data Type Semantics: identifier
PEN (provisional): 12559 (Inria)
ElementId (provisional): 408
FESTOR, et al. Expires May 3, 2017 [Page 12]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
A.9. locationTime
Description: Denotes the time when the location information is
obtained on a device acting as an IPFIX Flow Exporter. The time
is expressed in seconds since January 1, 1970, 00:00:00 UTC.
Data Type: dateTimeSeconds
Data Type Semantics: quantity
PEN (provisional): 12559 (Inria)
ElementId (provisional): 409
A.10. deviceId
Description: Denotes an identifier of a physical device acting as an
IPFIX Flow Exporter. The Exporting Process uses this identifier
to uniquely identify the device where Flows were metered. The
identifier is unique per device. This Information Element can
be used when an IPFIX Flow Exporter is behind a NAT.
Data Type: unsigned64
Data Type Semantics: identifier
PEN (provisional): 12559 (Inria)
ElementId (provisional): 410
FESTOR, et al. Expires May 3, 2017 [Page 13]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Appendix B. Recommended IPFIX Templates for Location Export
This appendix contains a set of recommended IPFIX Templates for
exporting geospatial and civic location information. The geospatial
templates are related to a point, circle or area shapes. The
definition and usage of the shapes is covered in [GeoSHAPE]. Civic
locations can be exported using a Template containing a
subTemplateList [RFC6313], where each element of the list corresponds
to a Template.
B.1. Geospatial Point Location Template
The point shape is the simplest form of a geospatial location, which
SHOULD be used when there is no known uncertainty. The following
Template is defined for exporting a 2D geospatial point location:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 300 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locationMethod = 408 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locationTime = 409 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| geospatialLocationCRSCode=401 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| geospatialLocationLat = 402 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| geospatialLocationLng = 403 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Template for exporting a 2D point-based geospatial location
For illustration, the following presents an example Data Record to
export a 2D geospatial point location:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 300 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locMethod = 3 | locationTime = 1234555555 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FESTOR, et al. Expires May 3, 2017 [Page 14]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
| ... octet 4 |geospatialLocationCRSCode=4326 |geospatial ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... LocationLat = 48.690855 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 6 - 8 |geospatial ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationLng = 6.172851 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 6 - 8 | Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Data Record of a geospatial 2D point location
B.2. Geospatial Circle Location Template
The circle Template is suitable for exporting the location of a flow
observed within a circle shape where its center is represented using
a geospatial point position and its radius represents the
uncertainty.
Template Record for Geospatial Circle (ID = 301)
| locationMethod(408)[1]
| locationTime(409)[4]
| geospatialLocationCRSCode(401)[2]
| geospatialLocationRadius(405)[4]
| geospatialLocationLat(402)[8]
| geospatialLocationLng(403)[8]
Figure 3: Template for exporting a circle-based geospatial location
The following presents an example of a Data Record carrying a circle-
based geospatial location:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 301 | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locMethod = 3 | locationTime = 1234555555 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 4 |geospatialLocationCRSCode=4326 | geospatial ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... LocationRadius = 850.24 | geospatial ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... LocationPosLat = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 42.5463 | geospatial ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FESTOR, et al. Expires May 3, 2017 [Page 15]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
| ... LocationLng = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| -73.2512 | Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Data Record of a circle-based geospatial location
B.3. Geospatial List Template
The list locations Template is suitable for exporting a variable-
length list of different geospatial point positions of a single flow.
For example, it could be used to export the start and the end
locations of a flow. The template relies on a subTemplateList data
type to export the list of geospatial point-based positions. This
template requires [RFC6313] compliant Exporting and Collecting
Processes. Figure 5 depicts an example of such a subTemplate for
exporting each element of the list.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 302 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locationTime = 409 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| geospatialLocationLat = 402 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| geospatialLocationLng = 403 | Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Template for exporting a geospatial 2D point-based position
Template Record for Geospatial List (ID = 303)
| locationMethod(408)[1]
| geospatialLocationCRSCode(401)[2]
+-subTemplateList(292)[0XFFFF]
+-Geospatial 2D Point position Template Record(302)[16]
Figure 6: Template for exporting a geospatial list of locations
The following presents an example Data Record carrying a list of two
geospatial point positions. Each point-based position is defined as
an element of a subTemplateList Information Element with semantic
"allOf".
FESTOR, et al. Expires May 3, 2017 [Page 16]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 303 | Length = 53 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locMethod = 3 |geospatialLocationCRSCode=4326 | 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Geospatial Point List length=43 |semantic=allOf| Template ID = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 302 | locationTime = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... 1234555555 | geospatialLocationLat1 = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 43.311 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 8 | geospatialLocationPostLng1 = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| -73.422 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 8 | locationTime = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... 1234555555 | geospatialLocationLat2 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 43.111 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 8 | geospatialLocationtLng2 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| -73.322 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 8 |
+-+-+-+-+-+-+-+-+
Figure 7: Data Record of a geospatial list of point-based locations
B.4. Civic Location Template
A civic-based location Data Record consists of a tuple of
(civicLocationType, civicLocationValue) Information Elements. Each
tuple is defined as an element of a subTemplateList Information
Element with semantic "allOf". This template requires [RFC6313]
compliant Exporting and Collecting Processes.
Template Record for Civic location (ID = 304)
| locationMethod(408)[1]
| locationTime(409)[4]
+-subTemplateList (292)[0xFFFF]
FESTOR, et al. Expires May 3, 2017 [Page 17]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
+-Civic element Template Record (ID = 305)
| civiLocationType(406)[1]
| civicLocationValue(407)[v]
Figure 8: Template for exporting a civic location
The "Civic element" Template Record, as shown in Figure 8, MUST be
defined for each tuple. For the purpose of illustration, we consider
exporting the civic location "Inria Nancy-Grand Est, Building B,
Office 123" obtained through DHCP. Using the Template described in
Figure 8, the resulting Data Record is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 304 | Length = 62 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locMethod = 3 | locationTime = 1234555555 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... octet 4 | 255 |Civic elements list length = 50|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| semantic=allOf| Civic element TemplateID = 305| CivicType=21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 21 | CivicValue = Inria Nancy-Grand |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Est ... | CivicType=25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | CivicValue = Building |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B ... | CivicType=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | CivicValue = Office |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 123 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Data Record of a civic location
Note that the values of the civiLocationType are defined in
[RFC4776].
FESTOR, et al. Expires May 3, 2017 [Page 18]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
B.5. Compound Location Template
A compound location is used to describe a location, represented by a
composite of both civic and geospatial information. An example
situation is a two-dimensional geospatial 2D point position
(latitude, longitude) describing a location of a building, and a
civic element representing the floor in that building. A
subTemplateMultiList [RFC6313] SHOULD be used to export a Template
for both geospatial and civic information. To represent the above
example, the following Template is defined:
Template Record for Compound Location (ID = 306)
| locationTime(409)[4]
+-subTemplateMultiList(293)[0XFFFF]
+-Geospatial Template Record (ID = 307)
| locationMethod(408)[1]
| geospatialLocationCRSCode(401)[2]
| geospatialLocationLat(402)[8]
| geospatialLocationLng(403)[8]
+-Civic location Template Record (ID = 308)
| locationMethod(408)[1]
| civicLocationType(406)[1]
| civicLocationValue(407)[v]
Figure 10: Template for exporting a compound location
A data Record encoded using the Template shown in Figure 11 is
represented as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 311 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locationTime = 12345555555555 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Attributes List Length = 53 | semantic=allOf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 312 | Geospatial Attr Length = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locMethod = 3 |geospatialLocationCRSCode=4326 |geospatial ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... LocationLat1 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| -34.407 |geospatial ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... LocationLng1 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FESTOR, et al. Expires May 3, 2017 [Page 19]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
| 150.8883 | Template ID = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 313 | Civic location Attr length=25 | locMethod=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CivicType = 21| 21 | CivicValue = Inria ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nancy-Grand Grand Est ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Data Record of a compound location
FESTOR, et al. Expires May 3, 2017 [Page 20]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Appendix C. Example Implementation
This appendix shows an example application that relies on the set of
IPFIX Information Elements described in Appendix A. This application,
named SURFmap, is a network monitoring tool based on the Google Maps
API that uses Flow data to visualize network Flows on a map
[SURFMAP]. By default, geolocation databases are used for retrieving
the (estimated) physical location associated to an IP address. The
Information Elements described in this document, however, will allow
SURFmap to use the absolute location information exported for Flows.
SURFmap has been developed in the past as a plugin to NfSen [NFSEN].
NfSen provides a Web-frontend to nfdump [NFDUMP], which is a set of
tools for flow data collection and processing, among others. To
support collection and processing of Flow Records containing any of
the new Information Elements (e.g. by SURFmap), an extension to
nfdump has been developed.
The following presents a set of Flow Records that have been exported
by a mobile Flow Exporter. Several fields, such as destination IP
address and port number, location timestamp and location method have
been left out for the sake of space. It is clear that the mobile
device has moved while exporting Flow Records, as the latitude and
longitude coordinates have changed over time.
Start time Src IP Addr:Port Pkts Bytes Latitude Longtitude
20:19:21.852 173.194.40.113:443 9 2730 48.690855 6.172851
20:21:42.307 91.202.200.229:80 13 9137 48.690855 6.172851
20:21:42.307 10.21.20.232:59521 15 1547 48.690855 6.172851
20:22:38.084 73.194.40.113:80 8 1799 48.690855 6.172851
20:22:38.084 10.21.20.232:34056 9 877 48.690855 6.172851
21:17:13.498 173.194.45.80:443 12 2830 48.713145 6.17526
21:17:13.498 10.21.20.232:49233 15 2301 48.713145 6.17526
21:17:16.919 10.21.20.232:15572 1 72 48.744506 6.154815
21:17:16.919 172.20.2.39:53 1 257 48.744506 6.15481
FESTOR, et al. Expires May 3, 2017 [Page 21]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Normative References
[GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, DOI
10.17487/RFC3693, February 2004, <http://www.rfc-
editor.org/info/rfc3693>.
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson,
"Threat Analysis of the Geopriv Protocol", RFC 3694, DOI
10.17487/RFC3694, February 2004, <http://www.rfc-
editor.org/info/rfc3694>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
<http://www.rfc-editor.org/info/rfc4119>.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, DOI
10.17487/RFC4776, November 2006, <http://www.rfc-
editor.org/info/rfc4776>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <http://www.rfc-editor.org/info/rfc5139>.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
DOI 10.17487/RFC5470, March 2009, <http://www.rfc-
editor.org/info/rfc5470>.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, DOI 10.17487/RFC5491, March 2009,
<http://www.rfc-editor.org/info/rfc5491>.
FESTOR, et al. Expires May 3, 2017 [Page 22]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
"Dynamic Host Configuration Protocol Options for
Coordinate-Based Location Configuration Information",
RFC 6225, DOI 10.17487/RFC6225, July 2011,
<http://www.rfc-editor.org/info/rfc6225>.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
<http://www.rfc-editor.org/info/rfc6235>.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
<http://www.rfc-editor.org/info/rfc6313>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012, DOI
10.17487/RFC7012, September 2013, <http://www.rfc-
editor.org/info/rfc7012>.
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IP Flow Information Export (IPFIX)
Information Elements", BCP 184, RFC 7013, DOI
10.17487/RFC7013, September 2013, <http://www.rfc-
editor.org/info/rfc7013>.
Informative References
[NFDUMP] Haag, P., "NFDUMP", http://nfdump.sourceforge.net, May
2013.
[NFSEN] Haag, P., "NfSen", http://nfsen.sourceforge.net, January
2012.
[SURFMAP] Hofstede, R., Fioreze, T., "SURFmap: A Network Monitoring
Tool Based on the Google Maps API", Proceedings of the
IFIP/IEEE International Symposium on Integrated Network
Management, 2009, June 2009.
[OGP] Oil and Gas Producers Association, "EPSG Geodetic
Parameter Registry", http://www.epsg-registry.org, August
FESTOR, et al. Expires May 3, 2017 [Page 23]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
2011.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009,
<http://www.rfc-editor.org/info/rfc5513>.
Acknowledgements
The authors were partly funded by FLAMINGO, a Network of Excellence
project (ICT-318488) supported by the European Commission under its
Seventh Framework Programme, and the EIT ICT Labs activity "Smart
Networks at the Edge".
FESTOR, et al. Expires May 3, 2017 [Page 24]
INTERNET DRAFT Location-Based Network Monitoring October 30, 2016
Authors' Addresses
Olivier Festor
Inria
615 rue du Jardin Botanique
54600 Villers-les-Nancy
France
Phone: +33 3 83 59 30 66
Email: Olivier.Festor@inria.fr
Abdelkader Lahmadi
University of Lorraine - LORIA
615 rue du Jardin Botanique
54600 Villers-les-Nancy
France
Phone: +33 3 83 59 30 00
Email: Abdelkader.Lahmadi@loria.fr
Rick Hofstede
University of Twente
P.O. Box 217
7500 AE Enschede
The Netherlands
Phone: +31 53 489 2013
Email: r.j.hofstede@utwente.nl
Aiko Pras
University of Twente
P.O. Box 217
7500 AE Enschede
The Netherlands
Phone: +31 53 489 3778
Email: a.pras@utwente.nl
FESTOR, et al. Expires May 3, 2017 [Page 25]
