Skip to main content

Extending IP Flow-Based Network Monitoring with Location Information
draft-irtf-nmrg-location-ipfix-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Olivier Festor , Abdelkader Lahmadi , Rick Hofstede , Aiko Pras
Last updated 2015-01-26 (Latest revision 2014-10-27)
RFC stream Internet Research Task Force (IRTF)
Formats
IETF conflict review conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix, conflict-review-irtf-nmrg-location-ipfix
Additional resources Mailing list discussion
Stream IRTF state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to nmrg-chairs@ietf.org
draft-irtf-nmrg-location-ipfix-02
Network Management Research Group                              O. Festor
Internet-Draft                                                     Inria
Intended Status: Informational                                A. Lahmadi
Expires: April 30, 2015                   University of Lorraine - LORIA
                                                             R. Hofstede
                                                                 A. Pras
                                                    University of Twente
                                                        October 27, 2014

  Extending IP Flow-Based Network Monitoring with Location Information
                   draft-irtf-nmrg-location-ipfix-02

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 April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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 April 30, 2015                 [Page 1]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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 Considerations . . . . . . . . . . . . . . . . . . . .  9
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A. IPFIX Location Information Elements  . . . . . . . . . 10
     A.1. geospatialLocationCRSCode . . . . . . . . . . . . . . . . . 10
     A.2. geospatialLocationLat . . . . . . . . . . . . . . . . . . . 10
     A.3. geospatialLocationLng . . . . . . . . . . . . . . . . . . . 10
     A.4. geospatialLocationAlt . . . . . . . . . . . . . . . . . . . 11
     A.5. geospatialLocationRadius  . . . . . . . . . . . . . . . . . 11
     A.6. civicLocationType . . . . . . . . . . . . . . . . . . . . . 11
     A.7. civicLocationValue  . . . . . . . . . . . . . . . . . . . . 11
     A.8. locationMethod  . . . . . . . . . . . . . . . . . . . . . . 12
     A.9. locationTime  . . . . . . . . . . . . . . . . . . . . . . . 12
     A.10. deviceId . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Appendix B. Recommended IPFIX Templates for Location Export  . . . 12
     B.1. Geospatial Point Location Template  . . . . . . . . . . . . 13
     B.2. Geospatial Circle Location Template . . . . . . . . . . . . 14
     B.3. Geospatial List Template  . . . . . . . . . . . . . . . . . 15
     B.4. Civic Location Template . . . . . . . . . . . . . . . . . . 16
     B.5. Compound Location Template  . . . . . . . . . . . . . . . . 17
   Appendix C. Example Implementation . . . . . . . . . . . . . . . . 19
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 20
   Informative References . . . . . . . . . . . . . . . . . . . . . . 21
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

 

FESTOR, et al.           Expires April 30, 2015                 [Page 2]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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
   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.
 

FESTOR, et al.           Expires April 30, 2015                 [Page 3]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   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 IPFIX 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
   Information Data Format in [RFC5491], to allow the encapsulation of
   location information within a presence document.

 

FESTOR, et al.           Expires April 30, 2015                 [Page 4]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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
   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
 

FESTOR, et al.           Expires April 30, 2015                 [Page 5]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   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 IPFIX 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 IPFIX 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
   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 space becomes usual
 

FESTOR, et al.           Expires April 30, 2015                 [Page 6]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   over time since it has been observed before. QoS monitoring
   applications will also benefit from the presence of location
   information with the Metering Process since it will allow for
   correlating quality parameters of IP Flows with respect to their
   measurement location. Thus, fine-grained QoS parameters can be
   validated and analyzed. For example, the 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
   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. 
 

FESTOR, et al.           Expires April 30, 2015                 [Page 7]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   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 current location when moving from one room to another. For long-
   running Flows, the Metering Process may use a distance-based
   expiration policy, such as expiring a Flow every upon a configured
   distance value in meters.  

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
   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.

 

FESTOR, et al.           Expires April 30, 2015                 [Page 8]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

5. Security Considerations

   The use of location information on the Internet has been discussed in
   "GeoPriv Requirements" [RFC3693], while the threats facing Internet
   protocols that carry location information are detailed in [RFC3694].
   IPFIX messages exchanged between the Metering and Collecting
   Processes that carry location information should be signed and
   encrypted to provide protection, as defined in [RFC3694]. 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. The applicability and analysis
   of these security requirements for the IPFIX protocol - especially in
   the case where location information is conveyed - is however outside
   of the scope of this document. This document only specifies the new
   IPFIX Information Elements for exporting location information.
   Otherwise, the same security considerations as those defined for the
   IPFIX protocol and the IPFIX information model apply.

6. IANA Considerations

   This document specifies several new IPFIX Information Elements and
   types that need to be registered with IANA. The values of existing
   location methods are enumerated within an IANA registry [RFC4119].
   However, integer identifiers for these methods need to be registered
   with IANA as described 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 [RFC5985]             |
      |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      |
      +--------+--------------+----------------------------------------+

 

FESTOR, et al.           Expires April 30, 2015                 [Page 9]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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

 

FESTOR, et al.           Expires April 30, 2015                [Page 10]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

A.4. geospatialLocationAlt

   Description: Denotes the coordinate information value of the
      altitude.

   Data Type: float64
   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

 

FESTOR, et al.           Expires April 30, 2015                [Page 11]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

A.8. locationMethod

   Description: Denotes the way in which the location information has
      been obtained. The locationMethod sub-registry is defined in
      Section 8.1.

   Data Type: unsigned8
   Data Type Semantics: identifier
   PEN (provisional): 12559 (Inria)
   ElementId (provisional): 408

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

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.

 

FESTOR, et al.           Expires April 30, 2015                [Page 12]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... octet 4   |geospatialLocationCRSCode=4326 |geospatial ... |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ... LocationLat = 48.690855                        |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... octet 6 - 8                               |geospatial ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LocationLng = 6.172851                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... octet 6 - 8                             | Padding (opt)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

 

FESTOR, et al.           Expires April 30, 2015                [Page 13]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

        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 ...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         ... LocationLng =                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 -73.2512                      | Padding (opt) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4: Data Record of a circle-based geospatial location

 

FESTOR, et al.           Expires April 30, 2015                [Page 14]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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".

    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 = |
 

FESTOR, et al.           Expires April 30, 2015                [Page 15]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ... 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]
      +-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
 

FESTOR, et al.           Expires April 30, 2015                [Page 16]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   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].

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)
 

FESTOR, et al.           Expires April 30, 2015                [Page 17]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

        | 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 =                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           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 April 30, 2015                [Page 18]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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 April 30, 2015                [Page 19]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

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, March 1997.

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC 6313, July 2011.

   [RFC7012]  Claise, B., Ed., and B. Trammell, Ed., "Information Model
              for IP Flow Information Export (IPFIX)", RFC 7012,
              September 2013.

   [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, September 2013.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              March 2009.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC6225]  Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed.,
              "Dynamic Host Configuration Protocol Options for
              Coordinate-Based Location Configuration Information",
              RFC 6225, July 2011.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              Presence Information Data Format Location Object (PIDF-LO)
              Usage Clarification, Considerations, and Recommendations",
              RFC 5491, March 2009.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
 

FESTOR, et al.           Expires April 30, 2015                [Page 20]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
              Support", RFC 6235, May 2011.

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
              2011.

   [RFC5513]  Farrel, A., "IANA Considerations for Three Letter
              Acronyms", RFC 5513, April 1 2009.

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".

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
 

FESTOR, et al.           Expires April 30, 2015                [Page 21]
INTERNET DRAFT     Location-Based Network Monitoring    October 27, 2014

   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 April 30, 2015                [Page 22]