Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)

Leinen, Simon

doi:10.17487/rfc3955

Cited by 19 publications

(10 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In 2004 that work produced two RFCs, 'IPFIX Requirements' [3] and 'IPFIX Candidate Evaluation' [4]. The WG began by considering commonly-used (in 2000) flow monitoring systems, choosing not to consider systems that did not handle flows as they are defined above.…”

Section: Ipfix: Architecture and Information Modelmentioning

confidence: 99%

See 1 more Smart Citation

Flow-Based Measurement: IPFIX Development and Deployment

Brownlee

2011

IEICE Trans. Commun.

View full text Add to dashboard Cite

SUMMARYThis paper presents a history of the IPFIX working group, from initial chartering through development and testing, re-chartering and further development, and looking ahead to future developments. As a standardised way of exporting information about traffic flows, IPFIX has attracted a growing number of implementors, who have continued to develop it in useful ways without changing its underlying architecture. This makes it a good example of how to develop a new technology. Further, it demonstrates widespread recognition of the importance of network measurement in the development, deployment and production stages of networks and the applications that depend on them. key words: traffic flows, network data export, IPFIX

show abstract

Section: Ipfix: Architecture and Information Modelmentioning

confidence: 99%

“…The protocols evaluated by the WG were CRANE, Diameter, LFAP, NetFlow version 9 and Streaming IPDR. RFC 3955 [4] gives brief summaries for each of them.…”

Section: Ipfix: Architecture and Information Modelmentioning

confidence: 99%

Flow-Based Measurement: IPFIX Development and Deployment

Brownlee

2011

IEICE Trans. Commun.

View full text Add to dashboard Cite

show abstract

“…7) High-availability and resilience -does the language spoken between exporters and collectors make it easier to achieve a high grade-of-service? The main characteristics Cisco's NetFlow and CRANE are given below, for the purposes of comparison, and the reader should please refer to [8] for a detailed analysis of other existing protocols such as DIAMETER, LFAF, and Streaming IPDR. Note: we refer to NetFlow version 9 when we write NetFlow.…”

Section: A Choosing a Flow-export Protocolmentioning

confidence: 99%

Closing the Loop for Dynamic IP QoS Provisioning: A Case Study

Tan

Seah

2007

32nd IEEE Conference on Local Computer Networks (LCN 2007)

View full text Add to dashboard Cite

Abstract-This paper investigates an approach to enabling dynamic reactive quality-of-service (QoS) management for IP networks. We use the information collected from monitoring traffic flows combined with middleware for setting network element configurations to differentiate the service given to traffic. We report on experiences of implementing the QoS management system using XORP (eXtensible Open Router Platform) and Click, the open source software router. The performance evaluation in terms of packet loss, dynamic behaviour of QoS configuration and time to re-configure the XORP+Click router is presented.

show abstract

“…We assume that for each interdomain link, there is a corresponding eBGP session between the local egress router and the remote AS. A TEroute reflector [11,23] centralizes the traffic statistics [36,16,57] as well as the BGP routes from the border routers of the domain. Two solutions can be envisioned to allow the TE-route reflector to know about all external routes known by the border routers.…”

Section: Performance Evaluationmentioning

confidence: 99%

Designing BGP-based outbound traffic engineering techniques for stub ASes

Uhlig

Bonaventure

2004

SIGCOMM Comput. Commun. Rev.

View full text Add to dashboard Cite

Today, most multi-connected autonomous systems (AS) need to control the flow of their interdomain traffic for both performance and economical reasons. This is usually done by manually tweaking the BGP configurations of the routers on an error-prone trialand-error basis. In this paper, we demonstrate that designing systematic BGP-based traffic engineering techniques for stub ASes are possible. Our approach to solve this traffic engineering problem is to allow the network operator to define objective functions on the interdomain traffic. Those objective functions are used by an optimization box placed inside the AS that controls the interdomain traffic by tuning the iBGP messages distributed inside the AS. We show that the utilization of an efficient evolutionary algorithm allows to both optimize the objective function and limit the number of iBGP messages. By keeping a lifetime on the tweaked routes, we also show that providing stability to the interdomain path followed by the traffic is possible. We evaluate the performance of solution based on traffic traces from two stub ASes of different sizes. Our simulations show that the interdomain traffic can be efficiently engineered by using not more than a few iBGP advertisements per minute.Our contribution in this paper is to demonstrate that by carefully thinking the design of the interdomain traffic engineering technique, stub ASes can engineer their outbound traffic over relatively short timescales, by exclusively tweaking their BGP routes, and with a minimal burden on BGP. Systematic BGP-based traffic engineering for stub ASes is thus possible at a very limited cost in terms of iBGP messages.

show abstract

Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)

Cited by 19 publications

References 11 publications

Flow-Based Measurement: IPFIX Development and Deployment

Flow-Based Measurement: IPFIX Development and Deployment

Closing the Loop for Dynamic IP QoS Provisioning: A Case Study

Designing BGP-based outbound traffic engineering techniques for stub ASes

Contact Info

Product

Resources

About