summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5982.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5982.txt')
-rw-r--r--doc/rfc/rfc5982.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5982.txt b/doc/rfc/rfc5982.txt
new file mode 100644
index 0000000..357f032
--- /dev/null
+++ b/doc/rfc/rfc5982.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Kobayashi, Ed.
+Request for Comments: 5982 NTT PF Lab.
+Category: Informational B. Claise, Ed.
+ISSN: 2070-1721 Cisco Systems, Inc.
+ August 2010
+
+
+ IP Flow Information Export (IPFIX) Mediation: Problem Statement
+
+Abstract
+
+ Flow-based measurement is a popular method for various network
+ monitoring usages. The sharing of flow-based information for
+ monitoring applications having different requirements raises some
+ open issues in terms of measurement system scalability, flow-based
+ measurement flexibility, and export reliability that IP Flow
+ Information Export (IPFIX) Mediation may help resolve. This document
+ describes some problems related to flow-based measurement that
+ network administrators have been facing, and then it describes IPFIX
+ Mediation applicability examples along with the problems.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5982.
+
+Copyright Notice
+
+ Copyright (c) 2010 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. Code Components extracted from this document must
+
+
+
+Kobayashi and Claise Informational [Page 1]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology and Definitions .....................................3
+ 3. IPFIX/PSAMP Documents Overview ..................................5
+ 3.1. IPFIX Documents Overview ...................................5
+ 3.2. PSAMP Documents Overview ...................................5
+ 4. Problem Statement ...............................................5
+ 4.1. Coping with IP Traffic Growth ..............................6
+ 4.2. Coping with Multipurpose Traffic Measurement ...............7
+ 4.3. Coping with Heterogeneous Environments .....................7
+ 4.4. Summary ....................................................7
+ 5. Mediation Applicability Examples ................................8
+ 5.1. Adjusting Flow Granularity .................................8
+ 5.2. Collecting Infrastructure ..................................8
+ 5.3. Correlation for Data Records ...............................9
+ 5.4. Time Composition ...........................................9
+ 5.5. Spatial Composition .......................................10
+ 5.6. Data Record Anonymization .................................11
+ 5.7. Data Retention ............................................11
+ 5.8. IPFIX Export from a Branch Office .........................12
+ 5.9. Distributing Data Record Types ............................13
+ 5.10. Flow-Based Sampling and Selection ........................14
+ 5.11. Interoperability between Legacy Protocols and IPFIX ......15
+ 6. IPFIX Mediators' Implementation-Specific Problems ..............15
+ 6.1. Loss of Original Exporter Information .....................15
+ 6.2. Loss of Base Time Information .............................16
+ 6.3. Transport Sessions Management .............................16
+ 6.4. Loss of Options Template Information ......................16
+ 6.5. Template ID Management ....................................17
+ 6.6. Consideration for Network Topology ........................18
+ 6.7. IPFIX Mediation Interpretation ............................18
+ 6.8. Consideration for Aggregation .............................19
+ 7. Summary and Conclusion .........................................20
+ 8. Security Considerations ........................................20
+ 9. Acknowledgements ...............................................21
+ 10. References ....................................................22
+ 10.1. Normative References .....................................22
+ 10.2. Informative References ...................................22
+ Contributors ......................................................24
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 2]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+1. Introduction
+
+ An advantage of flow-based measurement is that it allows monitoring
+ large amounts of traffic observed at distributed Observation Points.
+ While flow-based measurement can be applied to one of various
+ purposes and applications, it is difficult for flow-based measurement
+ to apply to multiple applications with very different requirements in
+ parallel. Network administrators need to adjust the parameters of
+ the metering devices to fulfill the requirements of every single
+ measurement application. Such configurations are often not supported
+ by the metering devices, either because of functional restrictions or
+ because of limited computational and memory resources, which inhibit
+ the metering of large amounts of traffic with the desired setup. IP
+ Flow Information Export (IPFIX) Mediation fills the gap between
+ restricted metering capabilities and the requirements of measurement
+ applications by introducing an intermediate device called the IPFIX
+ Mediator.
+
+ The IPFIX requirements defined in [RFC3917] mention examples of
+ intermediate devices located between Exporters and Collectors, such
+ as IPFIX proxies or concentrators. But, there are no documents
+ defining a generalized concept for such intermediate devices. This
+ document addresses that issue by defining IPFIX Mediation -- a
+ generalized intermediate device concept for IPFIX -- and examining in
+ detail the motivations behind its application.
+
+ This document is structured as follows: Section 2 describes the
+ terminology used in this document, Section 3 gives an IPFIX/Packet
+ Sampling (PSAMP) document overview, Section 4 introduces general
+ problems related to flow-based measurement, Section 5 describes some
+ applicability examples where IPFIX Mediation would be beneficial,
+ and, finally, Section 6 describes some problems an IPFIX Mediation
+ implementation might face.
+
+2. Terminology and Definitions
+
+ The IPFIX-specific and PSAMP-specific terminology used in this
+ document is defined in [RFC5101] and [RFC5476], respectively. In
+ this document, as in [RFC5101] and [RFC5476], the first letter of
+ each IPFIX-specific and PSAMP-specific term is capitalized along with
+ the IPFIX Mediation-specific terms defined here.
+
+ In this document, we call "record stream" a stream of records
+ carrying flow- or packet-based information. The records may be
+ encoded as IPFIX Data Records or in any other format.
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 3]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ Original Exporter
+
+ An Original Exporter is an IPFIX Device that hosts the Observation
+ Points where the metered IP packets are observed.
+
+ IPFIX Mediation
+
+ IPFIX Mediation is the manipulation and conversion of a record
+ stream for subsequent export using the IPFIX protocol.
+
+ The following terms are used in this document to describe the
+ architectural entities used by IPFIX Mediation.
+
+ Intermediate Process
+
+ An Intermediate Process takes a record stream as its input from
+ Collecting Processes, Metering Processes, IPFIX File Readers,
+ other Intermediate Processes, or other record sources; performs
+ some transformations on this stream, based upon the content of
+ each record, states maintained across multiple records, or other
+ data sources; and passes the transformed record stream as its
+ output to Exporting Processes, IPFIX File Writers, or other
+ Intermediate Processes, in order to perform IPFIX Mediation.
+ Typically, an Intermediate Process is hosted by an IPFIX Mediator.
+ Alternatively, an Intermediate Process may be hosted by an
+ Original Exporter.
+
+ IPFIX Mediator
+
+ An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation
+ by receiving a record stream from some data sources, hosting one
+ or more Intermediate Processes to transform that stream, and
+ exporting the transformed record stream into IPFIX Messages via an
+ Exporting Process. In the common case, an IPFIX Mediator receives
+ a record stream from a Collecting Process, but it could also
+ receive a record stream from data sources not encoded using IPFIX,
+ e.g., in the case of conversion from the NetFlow V9 protocol
+ [RFC3954] to the IPFIX protocol.
+
+ Note that the IPFIX Mediator is a generalization of the
+ concentrator and proxy elements envisioned in the IPFIX
+ requirements [RFC3917]. IPFIX Mediators running appropriate
+ Intermediate Processes provide the functionality specified
+ therein.
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 4]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+3. IPFIX/PSAMP Documents Overview
+
+ IPFIX Mediation can be applied to Flow- or packet-based information.
+ The Flow-based information is encoded as IPFIX Flow Records by the
+ IPFIX protocol, and the packet-based information is extracted by some
+ packet selection techniques and then encoded as PSAMP Packet Reports
+ by the PSAMP protocol. Thus, this section describes relevant
+ documents for both protocols.
+
+3.1. IPFIX Documents Overview
+
+ The IPFIX protocol [RFC5101] provides network administrators with
+ access to IP flow information. The architecture for the export of
+ measured IP flow information from an IPFIX Exporting Process to a
+ Collecting Process is defined in [RFC5470], per the requirements
+ defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how
+ IPFIX Data Records and Templates are carried via a number of
+ transport protocols from IPFIX Exporting Processes to IPFIX
+ Collecting Processes. IPFIX has a formal description of IPFIX
+ Information Elements, their names, types, and additional semantic
+ information, as specified in [RFC5102]. [RFC5815] specifies the
+ IPFIX Management Information Base. Finally, [RFC5472] describes what
+ types of applications can use the IPFIX protocol and how they can use
+ the information provided. Furthermore, it shows how the IPFIX
+ framework relates to other architectures and frameworks. The storage
+ of IPFIX Messages in a file is specified in [RFC5655].
+
+3.2. PSAMP Documents Overview
+
+ The framework for packet selection and reporting [RFC5474] enables
+ network elements to select subsets of packets by statistical and
+ other methods and to export a stream of reports on the selected
+ packets to a Collector. The set of packet selection techniques
+ (Sampling and Filtering) standardized by PSAMP is described in
+ [RFC5475]. The PSAMP protocol [RFC5476] specifies the export of
+ packet information from a PSAMP Exporting Process to a Collector.
+ Like IPFIX, PSAMP has a formal description of its Information
+ Elements, their names, types, and additional semantic information.
+ The PSAMP information model is defined in [RFC5477]. [PSAMP-MIB]
+ describes the PSAMP Management Information Base.
+
+4. Problem Statement
+
+ Network administrators generally face the problems of measurement
+ system scalability, Flow-based measurement flexibility, and export
+ reliability, even if some techniques, such as Packet Sampling,
+ Filtering, Data Records aggregation, and export replication, have
+ already been developed. The problems consist of adjusting some
+
+
+
+Kobayashi and Claise Informational [Page 5]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ parameters of metering devices to resources of the measurement system
+ while fulfilling appropriate conditions: data accuracy, Flow
+ granularity, and export reliability. These conditions depend on two
+ factors.
+
+ o Measurement system capacity: This consists of the bandwidth of the
+ management network, the storage capacity, and the performances of
+ the collecting devices and exporting devices.
+
+ o Application requirements: Different applications, such as traffic
+ engineering, detecting traffic anomalies, and accounting, impose
+ different Flow Record granularities, and data accuracies.
+
+ The sustained growth of IP traffic has been overwhelming the
+ capacities of measurement systems. Furthermore, a large variety of
+ applications (e.g., Quality-of-Service (QoS) measurement, traffic
+ engineering, security monitoring) and the deployment of measurement
+ systems in heterogeneous environments have been increasing the demand
+ and complexity of IP traffic measurements.
+
+4.1. Coping with IP Traffic Growth
+
+ Enterprise or service provider networks already have multiple 10 Gb/s
+ links, their total traffic exceeding 100 Gb/s. In the near future,
+ broadband users' traffic will increase by approximately 40% every
+ year according to [TRAFGRW]. When administrators monitor IP traffic
+ sustaining its growth at multiple Exporters, the amount of exported
+ Flow Records from Exporters could exceed the ability of a single
+ Collector.
+
+ To deal with this problem, current data reduction techniques (Packet
+ Sampling and Filtering in [RFC5475], and aggregation of measurement
+ data) have been generally implemented on Exporters. Note that Packet
+ Sampling leads to potential loss of small Flows. With both Packet
+ Sampling and aggregation techniques, administrators might no longer
+ be able to detect and investigate subtle traffic changes and
+ anomalies, as this requires detailed Flow information. With
+ Filtering, only a subset of the Data Records are exported.
+
+ Considering the potential drawbacks of Packet Sampling, Filtering,
+ and Data Records aggregation, there is a need for a large-scale
+ collecting infrastructure that does not rely on data reduction
+ techniques.
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 6]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+4.2. Coping with Multipurpose Traffic Measurement
+
+ Different monitoring applications impose different requirements on
+ the monitoring infrastructure. Some of them require traffic
+ monitoring at a Flow level while others need information about
+ individual packets or just Flow aggregates.
+
+ To fulfill these diverse requirements, an Exporter would need to
+ perform various complex metering tasks in parallel, which is a
+ problem due to limited resources. Hence, it can be advantageous to
+ run the Exporter with a much simpler setup and to perform appropriate
+ post-processing of the exported Data Records at a later stage.
+
+4.3. Coping with Heterogeneous Environments
+
+ Network administrators use IPFIX Devices and PSAMP Devices from
+ various vendors, various software versions, and various device types
+ (router, switch, or probe) in a single network domain. Even legacy
+ flow export protocols are still deployed in current networks. This
+ heterogeneous environment leads to differences in Metering Process
+ capabilities, Exporting Process capacity (export rate, cache memory,
+ etc.), and data format. For example, probes and switches cannot
+ retrieve some derived packet properties from a routing table.
+
+ To deal with this problem, the measurement system needs to mediate
+ the differences. However, equipping all collecting devices with this
+ absorption function is difficult.
+
+4.4. Summary
+
+ Due to resource limitations of the measurement system, it is
+ important to use traffic data reduction techniques as early as
+ possible, e.g., at the Exporter. However, this implementation is
+ made difficult by the heterogeneous environment of exporting devices.
+ On the other hand, keeping data accuracy and Flow granularity to meet
+ the requirements of different monitoring applications requires a
+ scalable and flexible collecting infrastructure.
+
+ This implies that a new Mediation function is required in typical
+ Exporter-Collector architectures. Based on some applicability
+ examples, the next section shows the limitation of the typical
+ Exporter-Collector architecture model and the IPFIX Mediation
+ benefits.
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 7]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+5. Mediation Applicability Examples
+
+5.1. Adjusting Flow Granularity
+
+ The simplest set of Flow Keys is a fixed 5-tuple of protocol, source
+ and destination IP addresses, and source and destination port
+ numbers. A shorter set of Flow Keys, such as a triple, a double, or
+ a single property, (for example, network prefix, peering autonomous
+ system number, or BGP Next-Hop fields), creates more aggregated Flow
+ Records. This is especially useful for measuring router-level
+ traffic matrices in a core network domain and for easily adjusting
+ the performance of Exporters and Collectors.
+
+ Implementation analysis:
+
+ Implementations for this case depend on where Flow granularity is
+ adjusted. More suitable implementations use configurable Metering
+ Processes in Original Exporters. The cache in the Metering
+ Process can specify its own set of Flow Keys and extra fields.
+ The Original Exporter thus generates Flow Records of the desired
+ Flow granularity.
+
+ In the case where a Metering Process hosting no ability to change
+ the Flow Keys in Original Exporters creates Flow Records, or PSAMP
+ Packet Reports, an IPFIX Mediator can aggregate Data Records based
+ on a new set of Flow Keys. Even in the case of a Metering Process
+ hosting this ability, an IPFIX Mediator can further aggregate the
+ Flow Records.
+
+5.2. Collecting Infrastructure
+
+ Increasing numbers of IPFIX Exporters, IP traffic growth, and the
+ variety of treatments expected to be performed on the Data Records
+ make it more and more difficult to implement all measurement
+ applications within a single Collector.
+
+ Implementation analysis:
+
+ To increase the collecting (e.g., the bandwidth capacity) and
+ processing capacity, distributed Collectors close to Exporters
+ need to be deployed. In such a case, those Collectors would
+ become IPFIX Mediators, re-exporting Data Records on demand to
+ centralized applications. To cope with the variety of measurement
+ applications, one possible implementation uses an Intermediate
+ Process deciding to which Collector(s) each record is exported.
+ More specific cases are described in Section 5.9.
+
+
+
+
+
+Kobayashi and Claise Informational [Page 8]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+5.3. Correlation for Data Records
+
+ The correlation amongst Data Records or between Data Records and
+ metadata provides new metrics or information, including the
+ following.
+
+ o One-to-one correlation between Data Records
+
+ * One-way delay from the correlation of PSAMP Packet Reports from
+ different Exporters along a specific path. For example, one-
+ way delay is calculated from the correlation of two PSAMP
+ Packet Reports, including the packet digest and the arrival
+ time at the Observation Point. This scenario is described in
+ Section 6.2.1.2 of [RFC5475].
+
+ * Packet inter-arrival time from the correlation of sequential
+ PSAMP Packet Reports from an Exporter.
+
+ * Treatment from the correlation of Data Records with common
+ properties, observed at incoming/outgoing interfaces. Examples
+ are the rate-limiting ratio, the compression ratio, the
+ optimization ratio, etc.
+
+ o Correlation amongst Data Records
+
+ Average/maximum/minimum values from correlating multiple Data
+ Records. Examples are the average/maximum/minimum number of
+ packets of the measured Flows, the average/maximum/minimum one-way
+ delay, the average/maximum/minimum number of lost packets, etc.
+
+ o Correlation between Data Records and other metadata
+
+ Examples are some BGP attributes associated with Data Records, as
+ determined via routing table lookup.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an Intermediate
+ Process located between the Metering Processes and Exporting
+ Processes on the Original Exporter, or alternatively, a separate
+ IPFIX Mediator located between the Original Exporters and IPFIX
+ Collectors.
+
+5.4. Time Composition
+
+ Time composition is defined as the aggregation of consecutive Data
+ Records with identical Flow Keys. It leads to the same output as
+ setting a longer active timeout on Original Exporters, with one
+
+
+
+Kobayashi and Claise Informational [Page 9]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ advantage: the creation of new metrics such as average, maximum, and
+ minimum values from Flow Records with a shorter time interval enables
+ administrators to keep track of changes that might have happened
+ during the time interval.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an Intermediate
+ Process located between the Metering Processes and Exporting
+ Processes on the Original Exporter, or alternatively a separate
+ IPFIX Mediator located between the Original Exporters and IPFIX
+ Collectors.
+
+5.5. Spatial Composition
+
+ Spatial composition is defined as the aggregation of Data Records in
+ a set of Observation Points within an Observation Domain, across
+ multiple Observation Domains from a single Exporter, or even across
+ multiple Exporters. The spatial composition is divided into four
+ types.
+
+ o Case 1: Spatial composition within one Observation Domain
+
+ For example, to measure the traffic for a single logical interface
+ in the case in which link aggregation [IEEE802.3ad] exists, Data
+ Records metered at physical interfaces belonging to the same trunk
+ can be merged.
+
+ o Case 2: Spatial composition across Observation Domains, but within
+ a single Original Exporter
+
+ For example, in the case in which link aggregation exists, Data
+ Records metered at physical interfaces belonging to the same trunk
+ grouping beyond the line card can be merged.
+
+ o Case 3: Spatial composition across Exporters
+
+ Data Records metered within an administrative domain, such as the
+ west area and east area of an ISP network, can be merged.
+
+ o Case 4: Spatial composition across administrative domains
+
+ Data Records metered across administrative domains, such as across
+ different customer networks or different ISP networks, can be
+ merged. For example, a unique Collector knows in which customer
+ network an Exporter exists, and then works out the traffic data
+ per customer based on the Exporter IP address.
+
+
+
+
+Kobayashi and Claise Informational [Page 10]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ Implementation analysis:
+
+ One possible implementation for cases 1 and 2 uses an Intermediate
+ Process located between the Metering Processes and Exporting
+ Processes on the Original Exporter. A separate IPFIX Mediator
+ located between the Original Exporters and IPFIX Collectors is a
+ valid solution for cases 1, 2, 3, and 4.
+
+5.6. Data Record Anonymization
+
+ IPFIX exports across administrative domains can be used to measure
+ traffic for wide-area traffic engineering or to analyze Internet
+ traffic trends, as described in the spatial composition across
+ administrative domains in the previous subsection. In such a case,
+ administrators need to adhere to privacy protection policies and
+ prevent access to confidential traffic measurements by other people.
+ Typically, anonymization techniques enable the provision of traffic
+ data to other people without violating these policies.
+
+ Generally, anonymization modifies a data set to protect the identity
+ of the people or entities described by the data set from being
+ disclosed. It also attempts to preserve sets of network traffic
+ properties useful for a given analysis while ensuring the data cannot
+ be traced back to the specific networks, hosts, or users generating
+ the traffic. For example, IP address anonymization is particularly
+ important for avoiding the identification of users, hosts, and
+ routers. As another example, when an ISP provides traffic monitoring
+ service to end customers, network administrators take care of
+ anonymizing interface index fields that could disclose any
+ information about the vendor or software version of the Exporters.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an anonymization
+ function at the Original Exporter. However, this increases the
+ load on the Original Exporter. A more flexible implementation
+ uses a separate IPFIX Mediator between the Original Exporter and
+ Collector.
+
+5.7. Data Retention
+
+ Data retention refers to the storage of traffic data by service
+ providers and commercial organizations. Legislative regulations
+ often require that network operators retain both IP traffic data and
+ call detail records, in wired and wireless networks, generated by end
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 11]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ users while using a service provider's services. The traffic data is
+ required for the purpose of the investigation, detection, and
+ prosecution of serious crime, if necessary. Data retention examples
+ relevant to IP networks are the following:
+
+ o Internet telephony (includes every multimedia session associated
+ with IP multimedia services)
+
+ o Internet email
+
+ o Internet access
+
+ Data retention, for these services in particular, requires a
+ measurement system with reliable export and huge storage, as the data
+ must be available for a long period of time, typically at least six
+ months.
+
+ Implementation analysis:
+
+ Regarding export reliability requirement, the most suitable
+ implementation uses the Stream Control Transmission Protocol
+ (SCTP) between the Original Exporter and Collector. If an
+ unreliable transport protocol such as UDP is used, a legacy
+ exporting device exports Data Records to a nearby IPFIX Mediator
+ through UDP, and then an IPFIX Mediator could reliably export them
+ to the IPFIX Collector through SCTP. If an unreliable transport
+ protocol such as UDP is used and if there is no IPFIX Mediator,
+ the legacy exporting device should duplicate the exports to
+ several Collectors to lower the probability of losing Flow
+ Records. However, it might result in network congestion, unless
+ dedicated export links are used.
+
+ Regarding huge storage requirements, the collecting infrastructure
+ is described in Section 5.2.
+
+5.8. IPFIX Export from a Branch Office
+
+ Generally, in large enterprise networks, Data Records from branch
+ offices are gathered in a central office. However, in the long-
+ distance branch office case, the bandwidth for transporting IPFIX is
+ limited. Therefore, even if multiple Data Record types should be of
+ interest to the Collector (e.g., IPFIX Flow Records in both
+ directions, IPFIX Flow Records before and after WAN optimization
+ techniques, performance metrics associated with the IPFIX Flow
+ Records exported at regular intervals, etc.), the export bandwidth
+ limitation is an important factor to pay attention to.
+
+
+
+
+
+Kobayashi and Claise Informational [Page 12]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an IPFIX Mediator
+ located in a branch office. The IPFIX Mediator would aggregate
+ and correlate Data Records to cope with the export bandwidth
+ limitation.
+
+5.9. Distributing Data Record Types
+
+ Recently, several networks have shifted towards integrated networks,
+ such as the pure IP and MPLS networks, which include IPv4, IPv6, and
+ VPN traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to
+ be analyzed separately and from different perspectives for different
+ organizations. A single Collector handling all Data Record types
+ might become a bottleneck in the collecting infrastructure. Data
+ Records distributed based on their respective types can be exported
+ to the appropriate Collector, resulting in load distribution amongst
+ multiple Collectors.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses replication of the
+ IPFIX Message in an Original Exporter for multiple IPFIX
+ Collectors. Each Collector then extracts the Data Record required
+ by its own applications. However, this replication increases the
+ load of the Exporting Process and the waste of bandwidth between
+ the Exporter and Collector.
+
+ A more sophisticated implementation uses an Intermediate Process
+ located between the Metering Processes and Exporting Processes in
+ an Original Exporter. The Intermediate Process determines to
+ which Collector a Data Record is exported, depending on certain
+ field values. If an Original Exporter does not have this
+ capability, it exports Data Records to a nearby separate IPFIX
+ Mediator, and then the IPFIX Mediator could distribute them to the
+ appropriate IPFIX Collectors.
+
+ For example, in the case of distributing a specific customer's
+ Data Records, an IPFIX Mediator needs to identify the customer
+ networks. The Route Distinguisher (RD), ingress interface,
+ peering Autonomous System (AS) number, or BGP Next-Hop, or simply
+ the network prefix may be evaluated to distinguish different
+ customer networks. In the following figure, the IPFIX Mediator
+ reroutes Data Records on the basis of the RD value. This system
+ enables each customer's traffic to be inspected independently.
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 13]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ .---------.
+ |Traffic |
+ .---->|Collector|<==>Customer#A
+ | |#1 |
+ | '---------'
+ RD=100:1
+ .----------. .-----------. |
+ |IPFIX | |IPFIX |----' .---------.
+ |Exporter#1| |Mediator | RD=100:2 |Traffic |
+ | |------->| |--------->|Collector|<==>Customer#B
+ | | | | |#2 |
+ | | | |----. '---------'
+ '----------' '-----------' |
+ RD=100:3
+ | .---------.
+ | |Traffic |
+ '---->|Collector|<==>Customer#C
+ |#3 |
+ '---------'
+
+ Figure A. Distributing Data Records to Collectors
+ Using IPFIX Mediator
+
+5.10. Flow-Based Sampling and Selection
+
+ Generally, the distribution of the number of packets per Flow seems
+ to be heavy tailed. Most types of Flow Records are likely to be
+ small Flows consisting of a small number of packets. The measurement
+ system is overwhelmed with a huge amount of these small Flows. If
+ statistics information of small Flows is exported as merged data by
+ applying a policy or threshold, the load on the Exporter is reduced.
+ Furthermore, if the Flow distribution is known, exporting only a
+ subset of the Data Records might be sufficient.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an Intermediate
+ Process located between the Metering Processes and Exporting
+ Processes on the Original Exporter, or alternatively a separate
+ IPFIX Mediator located between the Original Exporters and IPFIX
+ Collectors. A set of IPFIX Mediation functions, such as
+ Filtering, selecting, and aggregation, is used in the IPFIX
+ Mediator.
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 14]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+5.11. Interoperability between Legacy Protocols and IPFIX
+
+ During the migration process from a legacy protocol such as NetFlow
+ [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX
+ Exporters are likely to coexist in the same network. Operators need
+ to continue measuring the traffic data from legacy exporting devices,
+ even after introducing IPFIX Collectors.
+
+ Implementation analysis:
+
+ One possible implementation for this case uses an IPFIX Mediator
+ that converts a legacy protocol to IPFIX.
+
+6. IPFIX Mediators' Implementation-Specific Problems
+
+6.1. Loss of Original Exporter Information
+
+ Both the Exporter IP address indicated by the source IP address of
+ the IPFIX Transport Session and the Observation Domain ID included in
+ the IPFIX Message header are likely to be lost during IPFIX
+ Mediation. In some cases, an IPFIX Mediator might drop the
+ information deliberately. In general, however, the Collector must
+ recognize the origin of the measurement information, such as the IP
+ address of the Original Exporter, the Observation Domain ID, or even
+ the Observation Point ID. Note that, if an IPFIX Mediator cannot
+ communicate the Original Exporter IP address, then the IPFIX
+ Collector will wrongly deduce that the IP address of the IPFIX
+ Mediator is that of the Original Exporter.
+
+ In the following figure, a Collector can identify two IP addresses:
+ 192.0.2.3 (IPFIX Mediator) and 192.0.2.2 (Exporter#2), respectively.
+ The Collector, however, needs to somehow recognize both Exporter#1
+ and Exporter#2, which are the Original Exporters. The IPFIX Mediator
+ must be able to notify the Collector about the IP address of the
+ Original Exporter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 15]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ .----------. .--------.
+ |IPFIX | |IPFIX |
+ |Exporter#1|--------->|Mediator|---+
+ | | | | |
+ '----------' '--------' | .---------.
+ IP:192.0.2.1 IP:192.0.2.3 '----->|IPFIX |
+ ODID:10 ODID:0 |Collector|
+ +------>| |
+ .----------. | '---------'
+ |IPFIX | |
+ |Exporter#2|-----------------------'
+ | |
+ '----------'
+ IP:192.0.2.2
+ ODID:20
+
+ Figure B. Loss of Original Exporter Information
+
+6.2. Loss of Base Time Information
+
+ The Export Time field included in the IPFIX Message header represents
+ a reference timestamp for Data Records. Some IPFIX Information
+ Elements, described in [RFC5102], carry delta timestamps that
+ indicate the time difference from the value of the Export Time field.
+ If the Data Records include any delta time fields and the IPFIX
+ Mediator overwrites the Export Time field when sending IPFIX
+ Messages, the delta time fields become meaningless and, because
+ Collectors cannot recognize this situation, wrong time values are
+ propagated.
+
+6.3. Transport Sessions Management
+
+ Maintaining relationships between the incoming Transport Sessions and
+ the outgoing ones depends on the Mediator's implementation. If an
+ IPFIX Mediator relays multiple incoming Transport Sessions to a
+ single outgoing Transport Session, and if the IPFIX Mediator shuts
+ down its outgoing Transport Session, Data Records of the incoming
+ Transport Sessions would not be relayed anymore. In the case of
+ resetting an incoming Transport Session, the behavior of the IPFIX
+ Mediator needs to be specified.
+
+6.4. Loss of Options Template Information
+
+ In some cases, depending on the implementation of the IPFIX
+ Mediators, the information reported in the Data Records defined by
+ Options Templates could also be lost. If, for example, the Sampling
+ rate is not communicated from the Mediator to the Collector, the
+ Collector would miscalculate the traffic volume. This might lead to
+
+
+
+Kobayashi and Claise Informational [Page 16]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ crucial problems. Even if an IPFIX Mediator were to simply relay
+ received Data Records defined by Options Templates, the values of its
+ scope fields could become meaningless in the content of a different
+ Transport Session. The minimal information to be communicated by an
+ IPFIX Mediator must be specified.
+
+6.5. Template ID Management
+
+ The Template ID is unique on the basis of the Transport Session and
+ Observation Domain ID. If an IPFIX Mediator is not able to manage
+ the relationships amongst the Template IDs and the incoming Transport
+ Session information, and if the Template ID is used in the Options
+ Template scope, IPFIX Mediators would, for example, relay wrong
+ values in the scope field and in the Template Withdrawal Message.
+ The Collector would thus not be able to interpret the Template ID in
+ the Template Withdrawal Message and in the Options Template scope.
+ As a consequence, there is a risk that the Collector would then shut
+ down the IPFIX Transport Session.
+
+ For example, an IPFIX Mediator must maintain the state of the
+ incoming Transport Sessions in order to manage the Template ID on its
+ outgoing Transport Session correctly. Even if the Exporter Transport
+ Session re-initializes, the IPFIX Mediator must manage the
+ association of Template IDs in a specific Transport Session. In the
+ following figure, the IPFIX Mediator exports three Templates (256,
+ 257, and 258), received from Exporter#3, Exporter#2, and Exporter#1,
+ respectively. If Exporter#1 re-initializes, and the Template ID
+ value 258 is now replaced with 256, the IPFIX Mediator must correctly
+ manage the new mapping of (incoming Transport Session, Template ID)
+ and (outgoing Transport Session, Template ID) without shutting down
+ its outgoing Transport Session.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 17]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ .----------. OLD: Template ID 258
+ |IPFIX | NEW: Template ID 256
+ |Exporter#1|----+
+ | | |
+ '----------' X
+ .----------. | .-----------. .----------.
+ |IPFIX | '---------->| | | |
+ |Exporter#2|--------------->|IPFIX |-------------->|IPFIX |
+ | |Template ID 257 |Mediator |Template ID 258| Collector|
+ '----------' +---------->| |Template ID 257| |
+ .----------. | '-----------'Template ID 256'----------'
+ |IPFIX | |
+ |Exporter#3|----'
+ | | Template ID 256
+ '----------'
+
+ Figure C. Relaying from Multiple Transport Sessions
+ to a Single Transport Session
+
+6.6. Consideration for Network Topology
+
+ While IPFIX Mediation can be applied anywhere, caution should be
+ taken as to how to aggregate the counters, as there is a potential
+ risk of double counting. For example, if three Exporters export
+ PSAMP Packet Reports related to the same flow, the one-way delay can
+ be calculated, while summing up the number of packets and bytes does
+ not make sense. Alternatively, if three Exporters export Flow
+ Records entering an administrative domain, then the sum of the
+ packets and bytes is a valid operation. Therefore, the possible
+ function to be applied to Flow Records must take into consideration
+ the measurement topology. The information such as the network
+ topology, or at least the Observation Point and measurement
+ direction, is required for IPFIX Mediation.
+
+6.7. IPFIX Mediation Interpretation
+
+ In some cases, the IPFIX Collector needs to recognize which specific
+ function(s) IPFIX Mediation has executed on the Data Records. The
+ IPFIX Collector cannot distinguish between time composition and
+ spatial composition, if the IPFIX Mediator does not export the
+ applied function. Some parameters related to the function also would
+ need to be exported. For example, in the case of time composition,
+ the active timeout of original Flow Records is required to interpret
+ the minimum/maximum counter correctly. In the case of spatial
+ composition, spatial area information on which Data Records is
+ aggregated is required.
+
+
+
+
+
+Kobayashi and Claise Informational [Page 18]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+6.8. Consideration for Aggregation
+
+ Whether the aggregation is based on time or spatial composition,
+ caution should be taken regarding how to aggregate non-key fields in
+ IPFIX Mediation. The IPFIX information model [RFC5102] specifies
+ that the value of non-key fields, which are derived from fields of
+ packets or from packet treatment and for which the value may change
+ from packet to packet within a single Flow, is determined by the
+ first packet observed for the corresponding Flow, unless the
+ description of the Information Element explicitly specifies a
+ different semantics.
+
+ However, this simple rule might not be appropriate when aggregating
+ Flow Records that have different values in a non-key field. For
+ example, if Differentiated Services Code Point (DSCP) information is
+ to be exported, the following problem can be observed: if two Flows
+ with identical Flow Key values are measured at different Observation
+ Points, they may contain identical packets observed at different
+ locations in the network and at different points in time. On their
+ way from the first to the second Observation Point, the DSCP and
+ potentially some other packet fields may have changed. Hence, if the
+ Information Element ipDiffServCodePoint is included as a non-key
+ field, it can be useful to include the DSCP value observed at either
+ the first or the second Observation Point in the resulting Flow
+ Record, depending on the application.
+
+ Other potential solutions include removing the Information Element
+ ipDiffServCodePoint from the Data Record when re-exporting the
+ aggregate Flow Record, changing the Information Element
+ ipDiffServCodePoint from a non-key field to a Flow Key when
+ re-exporting the aggregated Flow Record, or assigning a non-valid
+ value for the Information Element to express to the Collector that
+ this Information Element is meaningless.
+
+ If Packet Sampling or Filtering is applied, the IPFIX Mediator must
+ report an adjusted PSAMP Configured Selection Fraction when
+ aggregating IPFIX Flow Records with different Sampling rates.
+
+ Finally, special care must be taken when aggregating Flow Records
+ resulting from different Sampling techniques such as Systematic
+ Count-Based Sampling and Random n-out-of-N Sampling, for example.
+
+
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 19]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+7. Summary and Conclusion
+
+ This document describes the problems that network administrators have
+ been facing, the applicability of IPFIX Mediation to these problems,
+ and the problems related to the implementation of IPFIX Mediators.
+ To assist the operations of the Exporters and Collectors, this
+ document demonstrates that there exist various IPFIX Mediation
+ functions from which the administrators may select.
+
+ However, there are still some open issues with the use of IPFIX
+ Mediators. These issues stem from the fact that no standards
+ regarding IPFIX Mediation have been set. In particular, the minimum
+ information that should be communicated between Original Exporters
+ and Collectors, the mapping between different IPFIX Transport
+ Sessions, and the internal components of IPFIX Mediators should be
+ standardized.
+
+8. Security Considerations
+
+ A flow-based measurement system must prevent potential security
+ threats: the disclosure of confidential traffic data, injection of
+ incorrect data, and unauthorized access to traffic data. These
+ security threats of the IPFIX protocol are covered by the Security
+ Considerations section in [RFC5101] and are still valid for IPFIX
+ Mediators.
+
+ A measurement system must also prevent the following security threats
+ related to IPFIX Mediation:
+
+ o Attacks against an IPFIX Mediator
+
+ IPFIX Mediators can be considered as a prime target for attacks,
+ as an alternative to IPFIX Exporters and Collectors. IPFIX
+ Proxies or Masquerading Proxies need to prevent unauthorized
+ access or denial-of-service (DoS) attacks from untrusted public
+ networks.
+
+ o Man-in-the-middle attack by untrusted IPFIX Mediator
+
+ The Exporter-Mediator-Collector structure model could be misused
+ for a man-in-the-middle attack.
+
+ o Configuration on IPFIX Mediation
+
+ An accidental misconfiguration and unauthorized access to
+ configuration data could lead to the crucial problem of disclosure
+ of confidential traffic data.
+
+
+
+
+Kobayashi and Claise Informational [Page 20]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ o Unintentional exposure of end-user information
+
+ The probability of collecting fine-grained information on one
+ arbitrary end user increases with the number of Observation
+ Points. An IPFIX Mediator facing such a situation may have to
+ apply appropriate functions (e.g., anonymization or aggregation)
+ to the Data Records it produces.
+
+ o Multiple-tenancy policy on an IPFIX Mediator
+
+ An IPFIX Mediator handling traffic data from multiple tenants or
+ customers needs to protect those tenants or customers from one
+ another's traffic data. For example, an IPFIX Mediator needs to
+ identify the customer's identifier, e.g., ingress interface index,
+ network address range, VLAN ID, Media Access Control (MAC)
+ address, etc., when feeding the customer's traffic data to a
+ customer's own dedicated IPFIX Collector. If the IPFIX Mediator
+ cannot identify each customer's traffic data, it may need to drop
+ the Data Records. In addition, another technique to keep track of
+ a customer's identifier may be required when customer sites are
+ movable, e.g., in the case of a virtual machine moving to another
+ physical machine.
+
+ o Confidentiality protection via an IPFIX Mediator
+
+ To ensure security of Data Records in transit, transport of Data
+ Records should be confidential and integrity-protected, e.g., by
+ using Transport Layer Security (TLS) [RFC5246] or Datagram
+ Transport Layer Security (DTLS) [RFC4347]. However, an IPFIX
+ Collector cannot know whether received Data Records are
+ transported as encrypted data between an Original Exporter and an
+ IPFIX Mediator. If this information is required on the IPFIX
+ Collector, it must be encoded in the IPFIX Mediator.
+
+ o Certification for an Original Exporter
+
+ An IPFIX Collector communicating via an IPFIX Mediator cannot
+ verify the identity of an Original Exporter directly. If an
+ Original Exporter and an IPFIX Collector are located in different
+ administrative domains, an IPFIX Collector cannot trust its Data
+ Records. If this information is required on the IPFIX Collector,
+ it must be encoded in the IPFIX Mediator.
+
+9. Acknowledgements
+
+ We would like to thank the following persons: Gerhard Muenz for
+ thorough, detailed review and significant contributions regarding the
+ improvement of whole sections; Keisuke Ishibashi for contributions
+
+
+
+Kobayashi and Claise Informational [Page 21]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ during the initial phases of the document; Brian Trammell for
+ contributions regarding the improvement of the Terminology and
+ Definitions section; and Nevil Brownlee, Juergen Schoenwaelder, and
+ Motonori Shindo for their technical reviews and feedback.
+
+10. References
+
+10.1. Normative References
+
+ [RFC5101] Claise, B., Ed., "Specification of the IP Flow
+ Information Export (IPFIX) Protocol for the Exchange
+ of IP Traffic Flow Information", RFC 5101,
+ January 2008.
+
+ [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
+ Sampling (PSAMP) Protocol Specifications", RFC 5476,
+ March 2009.
+
+10.2. Informative References
+
+ [IEEE802.3ad] IEEE Computer Society, "Link Aggregation", IEEE
+ Std 802.3ad-2000, March 2000.
+
+ [PSAMP-MIB] Dietz, T., Ed., Claise, B., and J. Quittek,
+ "Definitions of Managed Objects for Packet Sampling",
+ Work in Progress, July 2010.
+
+ [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
+ "Requirements for IP Flow Information Export (IPFIX)",
+ RFC 3917, October 2004.
+
+ [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services
+ Export Version 9", RFC 3954, October 2004.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
+ Layer Security", RFC 4347, April 2006.
+
+ [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and
+ J. Meyer, "Information Model for IP Flow Information
+ Export", RFC 5102, January 2008.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246, August
+ 2008.
+
+ [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
+ Quittek, "Architecture for IP Flow Information
+ Export", RFC 5470, March 2009.
+
+
+
+Kobayashi and Claise Informational [Page 22]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+ [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
+ "IP Flow Information Export (IPFIX) Applicability",
+ RFC 5472, March 2009.
+
+ [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg,
+ A., Grossglauser, M., and J. Rexford, "A Framework for
+ Packet Selection and Reporting", RFC 5474, March 2009.
+
+ [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S.,
+ and F. Raspall, "Sampling and Filtering Techniques for
+ IP Packet Selection", RFC 5475, March 2009.
+
+ [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and
+ G. Carle, "Information Model for Packet Sampling
+ Exports", RFC 5477, March 2009.
+
+ [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
+ Wagner, "Specification of the IP Flow Information
+ Export (IPFIX) File Format", RFC 5655, October 2009.
+
+ [RFC5815] Dietz, T., Ed., Kobayashi, A., Claise, B., and G.
+ Muenz, "Definitions of Managed Objects for IP Flow
+ Information Export", RFC 5815, April 2010.
+
+ [TRAFGRW] Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The
+ Impact and Implications of the Growth in Residential
+ User-to-User Traffic", SIGCOMM2006, pp. 207-218, Pisa,
+ Italy, September 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 23]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+Contributors
+
+ Haruhiko Nishida
+ NTT Information Sharing Platform Laboratories
+ 3-9-11 Midori-cho
+ Musashino-shi, Tokyo 180-8585
+ Japan
+
+ Phone: +81-422-59-3978
+ EMail: nishida.haruhiko@lab.ntt.co.jp
+
+
+ Christoph Sommer
+ University of Erlangen-Nuremberg
+ Department of Computer Science 7
+ Martensstr. 3
+ Erlangen 91058
+ Germany
+
+ Phone: +49 9131 85-27993
+ EMail: christoph.sommer@informatik.uni-erlangen.de
+ URI: http://www7.informatik.uni-erlangen.de/~sommer/
+
+
+ Falko Dressler
+ University of Erlangen-Nuremberg
+ Department of Computer Science 7
+ Martensstr. 3
+ Erlangen 91058
+ Germany
+
+ Phone: +49 9131 85-27914
+ EMail: dressler@informatik.uni-erlangen.de
+ URI: http://www7.informatik.uni-erlangen.de/~dressler/
+
+
+ Stephan Emile
+ France Telecom
+ 2 Avenue Pierre Marzin
+ Lannion, F-22307
+ France
+
+ Fax: +33 2 96 05 18 52
+ EMail: emile.stephan@orange-ftgroup.com
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 24]
+
+RFC 5982 IPFIX Mediation: Problem Statement August 2010
+
+
+Authors' Addresses
+
+ Atsushi Kobayashi (editor)
+ NTT Information Sharing Platform Laboratories
+ 3-9-11 Midori-cho
+ Musashino-shi, Tokyo 180-8585
+ Japan
+
+ Phone: +81-422-59-3978
+ EMail: akoba@nttv6.net
+
+
+ Benoit Claise (editor)
+ Cisco Systems, Inc.
+ De Kleetlaan 6a b1
+ Diegem 1831
+ Belgium
+
+ Phone: +32 2 704 5622
+ EMail: bclaise@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kobayashi and Claise Informational [Page 25]
+