Internet DRAFT - draft-choi-tunman-stats
draft-choi-tunman-stats
Tunnel Management BOF Taesang Choi
Internet Draft Changhoon Kim
Document: : <draft-choi-tunman-stats-00.txt> Seunghyun Yoon
ETRI
Marcus Brunner
Hiroyuki Saito
NEC Corporation
November 2001
Tunnel Management: Traffic Measurements and Status Monitoring
<draft-choi-tunman-stats-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
As VPNs grow in popularity, tunnel configuration and management
becomes ever more important since the services and mechanisms proposed
for VPN deployment are based on tunnels and tunneling protocols. It is
important, then, for operating and managing such tunnel services to
have a measurement mechanisms and infrastructure available. Various
tunnel statistics can be considered important. Basically, two
different kinds of measurement methods, namely active and passive, are
possible. For that reason, data path elements for counting and
injecting artificial traffic need to be placed and controlled
Conventions used in this document
Choi et al. Expires May 2001 1
Tunnel Management: Traffic Measurement and Status Monitoring
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 RFC-2119 [1].
1. Introduction
The draft is one in a series, which are concerned with a general
framework for the configuration (and management) of tunnels used to
implement a variety of services including VPNs. There are different
mechanisms and protocols that can be used to create tunnels. Examples
include MPLS, Ipsec, L2TP, MPLambdaS, VLANs/VCs.
These different tunnel types are often used to provide different
services where the type of service desired determines the type of
tunnel.
In order to get a grip on the complexities associated with tunnel
configuration management for VPN services, we break things down into
the following four categories:
- Endpoint Discovery and Setup
- Route Binding
- Datapath [6,9] Provisioning and Encapsulation
- Traffic Measurement and Status Monitoring
This draft addresses the last point of these, measurements and status
monitoring. For the other points see [5][6]. After tunnels are
configured and operational, tunnel traffic measurement and status
monitoring play a critical role for their performance, availability,
and usage measurement. Regardless of the type of tunnel mechanism(s)
used, various statistics about performance, availability, and usage
are important for various processes in the operation, administration,
and management of IP networks, and even more important in the case of
VPNs sold to customers.
Depending on the application, measurement in one way or another is
used to supervise, check, and control tunnels. Application areas
include fault detection, usage statistics, and performance monitoring,
accounting, customer notifications, etc.
The scope of this draft is tunnel measurement for tunnel performance
and status monitoring for fault and performance management. Specific
mechanism of data storage, data processing, statistics generation and
reporting is an important part of measurement and monitoring system
but it is considered out of scope of this document.
2. Relation to other drafts in tunman
Choi et al Expires May 2002 2
Tunnel Management: Traffic Measurement and Status Monitoring
Since measurement is the last part in the whole process of tunnel
management, all other steps are assumed to be performed already. More
specifically, the end-points of the tunnel are known [5], routing
decisions across multiple tunnel alternatives are defined [5], and
Datapath Elements [6] are configured.
From a configuration point of view, the data path elements for the
different kinds of measurements needs to be provisioned (if possible)
and configured. Note that the authors are in disagreement on the
concept of specialized data path element for measurements. Some think
configuring (Functional) Datapath Elements is not related with traffic
measurement methods. As far as some understand, the concept of
Datapath Elements has been introduced in [9], and now the term is
related with the special definition. See open issue 1.
3. Use Cases for Tunnel Traffic Measurement and Status Monitoring
Tunnel traffic measurement and status monitoring are used to collect
traffic data and other information for the following purposes:
- Tunnel Traffic Characterization
- Tunnel Monitoring
- Performance Monitoring
- Status Monitoring
- Tunnel Traffic Control
- Policing, Shaping, Performance Guarantee, etc.
- Accounting and Billing
- Tunnel Performance Forecasting
4. Tunnel Traffic Measurement and Status Monitoring Architecture
Since there are various ways to provision tunnels, tunnel traffic
measurement and status monitoring mechanisms need to be generic enough
to applicable to all of them. Currently, some VPN MIBs are defined
such as VPN MIB [1] and VR MIB [2]. They are specific to particular
tunnel configuration mechanisms such as MPLS/BGP VPN and VR VPN.
There are other types of tunnels, which don?t have associated MIBs.
In order to collect tunnel statistics and monitor status of tunnels in
this heterogeneous environment, this architecture should allow various
means of traffic measurement such as passive and active measurement
and status monitoring by means of various mechanisms, such as MIB,
PIB, or CLI polling.
Other working groups in IETF have been working on various aspects of
traffic measurement and status monitoring, although they are defined
Choi et al Expires May 2002 3
Tunnel Management: Traffic Measurement and Status Monitoring
for general purpose. This document adopts and uses the existing works
as much as possible and will reference them.
Tunnel Traffic Measurement
Conceptually two different methods for measuring and monitoring
network performance are known: passive measurement and active
measurement. For passive measurement, a data or control path element
is supervised by monitoring packets in order to store and collect
information from various fields within packet headers. Examples
include flow measurement [7] and Remote Monitoring (RMON) [8]. But
most of the defined MIBs in the IETF include some sort of passive
monitoring of certain parts. Passive monitoring does not add extra
traffic load to the network and they enable gathering of a large
amount of detailed information. However, recording and logging the
data in high-speed networks often require special arrangements for the
collection, storage, and processing of very large amounts of data.
On the other hand, active measurement is based on injecting probe
packets, often using ICMP. The most well-known examples are ping and
traceroute, in the IP space. The measurement facilities basically are
senders, injecting artificial traffic into the network in order to
measure a specific part with a particular traffic stream. On the
receiving side two possibilities exist in general. First, the traffic
is mirrored back towards the sender (the model used by ping). In this
case, the sender also takes care of the results. Second, the receiver
gathers the traffic and takes appropriate actions, e.g. notifies a
management station (using SNMP notifications or COPS
requests/reports).
Tunnel Status Monitoring
Status monitoring can be achieved via polling-based, notification-
based, and hybrid methods. The method used heavily depends on the
protocol capabilities available for interaction with a management
station.
5. Time Scales for Tunnel Traffic Measurement and Status Monitoring
The information collected by tunnel traffic measurement can be
provided to the end user or application either in real time or non-
real time depending on the activities to be performed and the actions
to be taken related to the tunnel management. Tunnel traffic control
will generally require real-time or near real-time information. For
tunnel-based network planning and capacity management information may
be provided in non-real time after the processing of raw data.
Choi et al Expires May 2002 4
Tunnel Management: Traffic Measurement and Status Monitoring
Broadly speaking, the following three time scales can be classified,
according to the use of observed traffic information for network
operations [3].
. Tunnel-based Network planning
Information that changes on the order of months is used to make
traffic forecasts as a basis for network extensions and long-term
network configuration in terms of tunnel management.
. Tunnel-based Capacity management
Information that changes on the order of days or hours is used to
manage the deployed facilities, by taking appropriate maintenance or
engineering actions to optimize utilization. For example, new MPLS
tunnels may be set up or existing tunnels modified while meeting
service level agreements. Also, load balancing may be performed, or
traffic may be rerouted for re-optimization after a failure.
. Real-time Tunnel Traffic control
Information that changes on the order of minutes or less is used to
adapt to the current network conditions in near real time. Thus, to
combat localized congestion, traffic management actions may perform
temporary fast-rerouting to redistribute the load. Upon detecting a
failure, traffic may be diverted to pre-established, secondary routes
until the failed path can be re-established. These control actions
can be performed by the configuration management system based on the
information provided by the traffic measurement system. Thus tight
cooperation between the two systems is a crucial part of the tunnel
management in general.
6. Tunnel Traffic Measurement and Status Monitoring Basis
Tunnel measurements and status monitoring can be classified on the
basis of where, and at which level the traffic data are gathered and
aggregated.
Tunnel traffic measurement can be based on flows, classes of flows
(e.g., refered to with DSCP in packet header), tunnel fragments (e.g.,
between CE-PE, PE-PE, etc.), tunnels, groups of tunnels including
tunnel within tunnel hierarchies. For this draft, flow-based and class
of flow-based mechanisms are out of scope.
Tunnel status monitoring can be performed on the tunnel end-points as
well as on mid-points. However, since we focus on tunnels, the mid-
points are out of scope. Mid-point might play a role in hierarchical
tunnel in tunnel scenarios.
Choi et al Expires May 2002 5
Tunnel Management: Traffic Measurement and Status Monitoring
7. Tunnel Traffic Measurement and Status Monitoring Entities
We need to identify the types of tunnel statistics and status to be
collected. Entities can be classified into two major groups: tunnel
traffic measurement entities and tunnel status monitoring entities.
Data Path Elements
A Functional Datapath Element as defined in [9] is a basic building
block of a conceptual router. Typical elements in the DiffServ domain
are Classifiers, Meters, Actions, Algorithmic Droppers, Queues and
Schedulers. In the area of tunnel management, other data path elements
are involved including encryption, decryption, and mapping traffic to
tunnels [6]. However, looking into measurements from a conceptual
point of view there are additional data path elements concerned with
different kind of measurements.
Elements used in the data path for measurments include interceptor,
active traffic generators, and active traffic receivers. For the case
of tunnel measurements, all elements can be located at the originating
or terminating node. Only in hierarchical cases (tunnel in tunnel)
different approaches are needed.
An interceptor looks into a packet, and performs specific actions,
based on information in the packet. Note that a counter is a
interceptor with an associated action. Basically, the counter does not
look into the packet header, but just counts the number of packets
passing by.
An active traffic generator generates traffic of a specific type and
sends it to a specific tunnel.
An active traffic receiver receives packets at a tunnel termination
point and take appropriate action.
Benefit of incorporating measurement into the data path include the
ability to distinguish and monitor based on inner and/or outer
headers, the flexibility of injection approaches (active appraoches),
specialized treatment for active monitor packets, etc?
The draft in its current version describes a very rough architecture
and model for monitoring. At a later stage it will be refined towards
a detailed definition of appropriate structures and elements. These
detailed model will be the basis for building future MIBs and PIB for
monitoring of tunnels.
Traffic Measurement Parameters
- traffic volume sent
Choi et al Expires May 2002 6
Tunnel Management: Traffic Measurement and Status Monitoring
- available bandwidth of a tunnel
- throughput
- loss ratio
- delay and its variation
Tunnel Status Monitoring Entities
- availability (check whether it is available at all)
- operational status (in what status the tunnel is intended to be)
- average holding time (tunnel duration or lifetime)
- Functional Datapath Elements [6,9] of tunnels
- number of classifiers, meters, queues, etc.
- length of each queue
- (random / deterministic) drop counts of each queue
- health of Datapath Elements
- etc.
8. Traffic Measurement and Status Monitoring Actions and Mechanisms
There are quite a number of actions, which can be preformed, based on
the information within packet headers. However, in the general case of
tunnels, where the underlying technology is not specified, the actions
are limited. Counting the number of packets, and very often the number
of octets, enables to monitor the usage of the tunnel and tunnel
packet loss. All actions based on packet header information need to be
defined per technology, but some general action for aggregation
purposes are possible.
Active measurement enables monitoring of network parameters such as
packet transfer delay and availability. Actions involved are the
definition of the sending and receiving process.
Some actions might be involved in the process of notifying the
management systems about certain situations, happened on the data
path.
In order to embody the above actions, the following mechanisms can be
used.
- SNMP
- Flow export (e.g. RTFM, NetFlow, etc.)
- Traffic Capture
e.g. OC-Xmon
- RMON
- CLI
- Active Measurement Facilities
- Traffic Generator & Receiver, Traffic Analyzer
Choi et al Expires May 2002 7
Tunnel Management: Traffic Measurement and Status Monitoring
9. Relation to tunnel configuration
Besides statistics measurement, it is also important for the manager
application to have prompt feedback of the configuration actions.
Different methods can be used for the same purpose. For instance,
SNMP can be used for both (configuration and feedback), COPS for
configuration and SNMP for feedback, COPS for both, etc.
Again, the feedback mechanism should not be restricted to a particular
protocol in order to cover various tunnels.
On the other hand, measurement and monitoring process also require
provisioned tunnel configuration information. For example, when we
perform active traffic measurement on a particular tunnel, we need to
know route binding information at the beginning end-point of the
tunnel, so that the we can inject probe packets into the proper target
tunnel. But generally, it is very hard to remodel and restructure the
configuration information which has provisioned on a network, only on
the basis of monitored and measured data. Therefore, in order to make
measurement and monitoring process efficiently acquire the configured
information, having a formal information model for tunnel
configuration might be beneficial. Such kind of information model may
be structured as a PIB-like form. But still, they should be modeled
generic enough to cover various tunneling mechanisms.
10. Security Considerations
TBD
11. Acknowledgements
12. References
[1] T. Nadeau, et. al, "MPLS/BGP Virtual Private Network Management
Information Base Using SMIv2", Internet-Draft, Work in Progress, July
2001.
[2] E. Stelzer, et. al, "Virtual Router Management Information Base
Using SMIv2", Internet-Draft, Work in Progress, July 2001.
[3] G. Ash, "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-
based Multiservice Networks", Internet-Draft, Work in Progress, March
2001.
[4] W. Lai, et. al, "A Framework for Internet Traffic Engineering
Measurement", Internet-Draft, Work in Progress, August 2001.
Choi et al Expires May 2002 8
Tunnel Management: Traffic Measurement and Status Monitoring
[5] F. Reichmeyer et al., "Tunnel Endpoint Configuration and Route
Binding", Internet Draft, draft-many-tunman-endpoint-config-00.txt,
work in progress, November 2001.
[6] K. Chan et al., "Tunnel Management Data Path", Internet Draft,
draft-chan-tunman-datapath-00.txt, work in progress.
[7] RFC 2722, ?Traffic Flow Measurement: Architecture?, 1999.
[8] Waldbusser, S., "Remote Network Monitoring Management Information
Base", STD 59, RFC 2819, May 2000.
[9] Y. Mernet et al, ?An Informal Management Model for Diffserv
Routers?, Internet Draft, draft-ietf-diffserv-model-06.txt, work in
progress
13. Author's Addresses
Taesang Choi
Internet Architecture Team, ETRI
161 Kajong-Dong, Yusong-Gu
Daejon 305-350 Republic of Korea
Phone: +82 42 860 5628
Fax: +82 42 860 5440
E-mail: choits@etri.re.kr
Changhoon Kim
Internet Architecture Team, ETRI
161 Kajong-Dong, Yusong-Gu
Daejon 305-350 Republic of Korea
Phone: +82 42 860 5801
Fax: +82 42 860 5440
E-mail: kimch@etri.re.kr
Seunghyun Yoon
Internet Architecture Team, ETRI
161 Kajong-Dong, Yusong-Gu
Daejon 305-350 Republic of Korea
Phone: +82 42 860 6329
Fax: +82 42 860 5440
E-mail: shpyoon@etri.re.kr
Marcus Brunner
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
D-69115 Heidelberg, Germany
Phone: +49 (0)6221 9051129
Fax: +49 (0)6221 9051155
Choi et al Expires May 2002 9
Tunnel Management: Traffic Measurement and Status Monitoring
E-mail: brunner@ccrle.nec.de
Hiroyuki Saito
NEC Corporation
Development Laboratories
1131, Hinode, Abiko, Chiba, 270-1198, JAPAN
Phone: +81 471-85-6738
Fax: +81 471-85-6841
Email: hiroyuki@ptl.abk.nec.co.jp
14. Open Issues
Issue 1
There is a mismatch in opinions on whether data path elements
specifically used for measurements should be in or out of scope of
this draft.
Issue 2
Feedback mechanisms of information gathered in an synthetic sink,
active monitor etc. need to be defined more clearly. Additionally,
feedback of on configurations/changes of configuration might be
handled in this draft, but might be in the tunnel management
configuration draft.
Choi et al Expires May 2002 10
