Tunnel Management BOF Taesang Choi Internet Draft Changhoon Kim Document: : Seunghyun Yoon ETRI Marcus Brunner Hiroyuki Saito NEC Corporation November 2001 Tunnel Management: Traffic Measurements and Status Monitoring 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