Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring

From: Tanja Zseby <[email-masked]>
Date: Wed, 06 Feb 2002 12:30:17 +0100

Hi K.C.,

attached you can find my contributions to the architecture document.

- The first text contains some first thoughts on how IPFIX and AAA could 
communicate.

- The second text contains considerations on how IPFIX can be used for 
QoS monitoring. Maybe this can also go into the architecture document 
 (Ram Gopal for instance had a section on "some applications for IPFIX" 
in his text). Or do you think this should be put into a separate document ?

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

Contribution to IPFIX WG				Tanja Zseby
							FhI FOKUS

							February 2002

IPFIX and AAA

AAA defines a protocol and an architecture for authentication, 
authorization and accounting for service usage. The DIAMETER protocol 
is used for AAA communication for network access services (Mobile IP, 
NASREQ, ROAMOPS). The AAA architecture [RFC2903] provides a framework 
for extending the AAA support also for other services. DIAMETER defines 
the exchange of messages between AAA entities, e.g. between AAA clients 
at access devices and AAA servers and among AAA servers. It is used 
also for the transfers of accounting records. For usage-based 
accounting measurement data from the network is needed to generate an 
accounting record. IPFIX provides a protocol to export measurement data 
from the measurement point to the consumer of this data (like network 
management and accounting systems). The provisioning of accounting with 
IPFIX can be realized without a AAA infrastructure. The collector can 
directly forward the measurement information to an accounting application. 
Nevertheless, if a AAA infrastructure is in place, IPFIX can provide the 
input for the generation of accounting records and several features of the 
AAA architecture can be used. Features include the mapping of a user ID to 
the flow information (by using authentication information), the generation 
of DIAMETER accounting records and the secure exchange of accounting 
records between domains with DIAMETER. Three possibilities to connect 
IPFIX and AAA can be distinguished: 

1. Connecting via an AAA client

One possibility to connect IPFIX and AAA is to run a AAA client on the 
IPFIX collector. This client can generate DIAMETER accounting messages 
and send them to a AAA server. The mapping of the flow information to a 
user ID can be done in the AAA server by using data from the authentication 
process. DIAMETER accounting messages can be sent to the accounting 
application or to other AAA servers (e.g. in roaming scenarios).

       +---------+  DIAMETER    +---------+ 
       |  AAA-S  |------------->|  AAA-S  |
       +---------+              +---------+ 
            ^
            | DIAMETER		
            |
	    |
     +--+--------+--+
     |  |  AAA-C |  |
     +  +--------+  |
     |              |
     |  Collector   |
     +--------------+    
            ^
            | IPFIX		
            |
      +------------+
      |  Exporter  |
      +------------+   

Figure 1: IPFIX collector connects to AAA server via AAA client 

2. Connecting via an Application Specific Module (ASM)

Another possibility is to directly connect the IPFIX collector with the AAA server via an 
application specific module (ASM). Application specific modules have been proposed by the 
IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface 
between AAA server and service equipment. In this case the IPFIX collector is part of the 
ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the 
AAA server. The ASM translates the received IPFIX data into an appropriate format for the 
AAA server. The AAA server then can add information about the user ID and generate a 
DIAMETER accounting record. This accounting record can be sent  to an accounting 
application or to other AAA serves. 

       +---------+  DIAMETER    +---------+ 
       |  AAA-S  |------------->|  AAA-S  |
       +---------+              +---------+ 
            ^
            |		
    +------------------+
    |     ASM          |
    |  +------------+  |
    |  |  Collector |  |
    +------------------+
            ^
            | IPFIX		
            |
      +------------+
      |  Exporter  |
      +------------+   

Figure 2: IPFIX connects to AAA server via ASM 

3. Using DIAMETER as IPFIX protocol

The third possibility is that the IPFIX exporter itself already uses the DIAMETER protocol, 
generates DIAMETER accounting records (or a simplified version) and directly can 
communicate with a AAA server. Nevertheless, DIAMETER and IPFIX address quite 
different problems. An IPFIX exporting device can be a router or another device with scarce 
resources. A simpler protocol than DIAMETER might be sufficient and much better suited for 
IPFIX. Furthermore, IPFIX also needs to support other applications than accounting. All this 
might require simplifications and extensions to the DIAMETER protocol that reduce the 
compatibility with the AAA server or increase the complexity of the server and with this also 
decreases the benefit of using DIAMETER in this context.

Contribution to IPFIX WG				Tanja Zseby
							FhI FOKUS

							February 2002

QoS Monitoring with IPFIX 

The performance QoS monitoring is one target application for using the 
IPFIX protocol. QoS monitoring is the passive observation of the 
transmission quality for single flows or traffic aggregates in the 
network. It is needed for instance for the validation of QoS guarantees 
in service level agreements. Some QoS metrics require the correlation of 
data from multiple measurement points. For this the clock of the involved
exporting devices need to be synchronized. Furthermore such measurements 
would benefit from post-processing functions (e.g. packet ID generation) 
at the exporter and/or collector. This section describes how the monitoring 
of different metrics can be performed with IPFIX. The following metrics are 
considered: round trip time, one-way-delay, loss and delay variation.

Measurement of Round-trip-time (RTT) with IPFIX

The passive measurement of round-trip-times (RTT) can be performed by using 
packet pair matching techniques as described in [Brow00]. For the 
measurements, request/response packet pairs from protocols like DNS, ICMP,
SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively observe the 
RTT. As always for passive measurements this only works if the required 
traffic of interest is actually present in the network. In order to use this 
measurement technique, the IPFIX meter needs to measure both directions. A 
classification of the protocols mentioned above has to be done. That means 
parts of the transport header are used for the classification. Since a 
differentiation of flows in accordance to the transport header is one of 
the requirements for IPFIX, such classification can be performed without 
extensions. Nevertheless, the meter needs to recognize request and response 
packets for the given protocols and therefore needs to look further into the 
packet. This is not required for IPFIX but can be achieved by optional 
extensions to the classification process. The exporting device needs to 
assign a timestamp for the arrival of the packets. The calculation of the RTT 
can be done directly at the exporter or at the collector. In the first case 
IPFIX would transfer the calculated RTT to the collector. In the second case 
IPFIX needs to send the observed packet types and the timestamps to the collector.

Measurement of One-way-delay (OWD) with IPFIX

Passive one-way-delay measurements require the collection of data at two 
measurement points. It is required to recognize packets at the second 
measurement point in order to correlate packet arrival events from both 
points. This can be done for instance by capturing packet headers and parts 
of the packet and recognize packets based on this. In order to reduce the 
amount of measurement data a unique packet ID can be calculated from the 
header and part of the content e.g. by using a CRC or hash function [GrDM98, 
DuGr00, ZsZC01].Since IPFIX is not targeted at packet capturing these 
functionalities do not need to be supported by a standard IPFIX meter. 
Nevertheless, in some scenarios it might be sufficient to calculate a packet 
ID under consideration of header fields including datagramm ID and maybe 
sequence numbers (from transport protocols) without looking at parts of the 
packet content. Especially if packet IDs need to be unique only for a 
certain time interval or a certain amount of packet ID collisions is 
tolerable this can be a solution. 

Measurement of Loss with IPFIX

Passive loss measurements for single flows can be performed at one measurement 
point for instance by using sequence numbers that are present in higher layer 
protocols. This requires the capturing of the sequence numbers of subsequent 
packets of the observed flow at the IPFIX meter. An alternative to this is to 
perform a two-point measurement as described above and just consider packets 
as lost, that do not arrive at the second measurement point in a given maximum 
time frame. 

Measurement of delay variation with IPFIX

Delay variation is defined as the difference of one-way-delay values for selected 
packets.[DeCi01]. Therefore this metric can be calculated by performing passive 
measurement of one-way-delay for subsequent packets (e.g. of a flow) and then 
calculate the differences. 

Sampling for QoS Monitoring

Since QoS monitoring can lead to an overwhelming amount of measurement result 
data, it would  highly benefit from the deployment of mechanisms to reduce 
the measurement data, like aggregation of results and sampling. Sampling 
methods can be grouped according to the sampling strategy (systematic, 
random or stratified) and the trigger that starts a sampling interval 
(count-based, time-based or packet-content-based) [ClPB93]. Sampling can 
also be used as a method to dynamically reduce resource consumption if the 
meter is overloaded. Then the IPFIX meter can switch to a sampling method 
if too many packets have to be observed. 
Since the expected estimation error depends heavily on the used sampling 
strategy, the application that receives the data needs to be aware of the 
sampling scheme and the used parameters. Therefore it is important that 
the IPFIX exporter informs the collector precisely about the used sampling 
strategy. This is even more required if the IPFIX meter dynamically invokes sampling.

[Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, 
http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-dist/

[DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for IPPM, 
<draft-ietf-ippm-ipdv-08.txt>, November   2001

[RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss Metric for 
IPPM, September 1999

[ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application of Sampling
Methodologies to Network Traffic Characterization, Proceedings of ACM SIGCOMM'93, 
San Francisco, CA, USA,  September 13 - 17, 1993

[GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: 
Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on 
the Internet, INET'98, Geneva, Switzerland,  21-24 July, 1998

[DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for Direct Traffic 
Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - 
September 1, 2000.

[RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric for IPPM, 
Request for Comments: 2679, September 1999  

[ZsZC01]	Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of Building Blocks 
for Passive One-way-delay Measurements, Proceedings of Passive and Active Measurement 
Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM 2001)

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 06 Feb 2002 12:13:56 -0800

Hi Tanja,

> - The first text contains some first thoughts on how IPFIX and AAA could

To me, this portion is entirely out of scope from an IPFIX arch point
of view.
This is more of an application which takes in flow records collected by the
IPFIX collector. Similarly there could be other applications that use the
collected flow records.IMO we should not be defining these interfaces in
the archtecture.
If there is something like an applicability doc, that would be a good place
for this to go. But again the point is that IPFIX should not go all the way to
define interfaces with each of the possible applications.

> in his text). Or do you think this should be put into a separate document ?

This also looks to be good for an applicability doc.
Thanks
Ganesh

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Jc Martin <[email-masked]>
Date: Wed, 06 Feb 2002 14:35:39 -0800

Ganesh,

  The interface between AAA and IPFIX can be as simple as a common set of
attributes, coding, ... There should be an effort to avoid the proliferation
of accounting attributes specially if they refer to the same element.

Also, the mediation applications are merging multiple source of information to
build the CDRs, it is likely that IPFIX records will be consolidated with radius
records to determine the end user of a given IP address. I agree that this should
be in an applicability doc, but it could also be taken into account when the
architecture is defined.

JC.

---

From: Tanja Zseby <[email-masked]>
Date: Thu, 07 Feb 2002 10:23:29 +0100

Hi Ganesh

I agree, that different applications can be consumer of IPFIX data. 
Nevertheless, AAA defines a whole architecture for accounting and 
itself provides input to accounting and billing applications. Therefore 
I think we need to show how IPFIX and AAA can work together. I agree 
that it is not the task of IPFIX to define the interfaces. And maybe you 
are right, and the architecture document is not the rigtht place for 
this. If Nevil writes something on relations to RTFM we could put 
together a document on relations between IPFIX and other WGs/frameworks. 
Or really start a applicability document with sections for the target 
applications mentioned in the requirements draft.

Regards
Tanja

---

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 07 Feb 2002 11:23:16 -0800

Hi Tanja,

Tanja Zseby wrote:

> itself provides input to accounting and billing applications.
> Therefore I think we need to show how IPFIX and AAA can work together.
> I agree that it is not the task of IPFIX to define the interfaces. And
> maybe you are right, and the architecture document is not the rigtht
> place for this. If Nevil writes something on relations to RTFM we
> could put together a document on relations between IPFIX and other
> WGs/frameworks. Or really start a applicability document with sections
> for the target applications mentioned in the requirements draft.

I think an applicability doc would be great to have considering that
some many pieces
outside IPFIX want to make use of the collected information.
Thanks
Ganesh

---

From: [email-masked]
Date: Sat, 09 Feb 2002 07:24:19 +0100 (CET)

Hi Tanja,

I agree with your statement. The discussion of interaction with AAA
should not be part of the architecture document. So, let's take it
out of it.

Also I agree that this might fit very well into an applicability 
document. Why don't you just start editing one based on your text.

Best wishes,

    Juergen
--
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de 

> applications mentioned in the requirements draft.
[...]