Network Working Group K. Suzuki Internet-Draft M. Jibiki Intended status: Informational NEC Expires: September 25, 2010 March 24, 2010 A Framework for Automatic Traffic Engineering of Autonomous System draft-suzuki-framework-auto-te-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 25, 2010. 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 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 BSD License. Suzuki & Jibiki Expires September 25, 2010 [Page 1] Internet-Draft A Framework for Automatic TE of AS March 2010 Abstract This document describes a framework for automatic traffic engineering of autonomous system (AS). Automatic traffic engineering aims to automatically control incoming traffic. The framework in this document provides roles of each element and a communication model between the elements for realizing automatic traffic engineering. Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Communication Model . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Traffic Information . . . . . . . . . . . . . . . . . . . . 3 2.2. TE Control Message . . . . . . . . . . . . . . . . . . . . 4 3. Role of Element . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. eBGP Router . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. TE Server . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 5 Suzuki & Jibiki Expires September 25, 2010 [Page 2] Internet-Draft A Framework for Automatic TE of AS March 2010 1. Introduction BGP protocol[2] is used by operators of AS for controlling traffic which comes in the AS. To realize appropriate traffic engineering, operators have to set up configuration of BGP router in the AS appropriately. It is difficult for the operators to control incoming traffic fluctuating moment by moment. This increases operating cost of AS. This document describes a framework for automatic traffic engineering of autonomous system (AS). Automatic traffic engineering aims to automatically control incoming traffic. The framework in this document provides roles of each element and a communication model between the elements for realizing automatic traffic engineering. 2. Communication Model Incoming +--------+ Traffic +--------+ Traffic | | Info. | | ---> | eBGP | ----> | | eBGP peer | Router | TE Ctrl. | | <---> | | <---- | | +--------+ | TE | Incoming +--------+ Traffic | Server | Traffic | | Info. | | ---> | eBGP | ----> | | eBGP peer | Router | TE Ctrl. | | <---> | | <---- | | +--------+ +--------+ Figure 1: Autonomous System Framework 2.1. Traffic Information Traffic information is information of traffic which comes in from neighbor AS. The traffic information is made by eBGP router, and is sent to TE server. Traffic information may be sampled flow data, e.g. IP Traffic Flow information for IPFIX protocol [3], or summarized data of flow information, e.g. MIB data for SNMP [4]. Specifications of the traffic information is concretely defined by the other documents. Suzuki & Jibiki Expires September 25, 2010 [Page 3] Internet-Draft A Framework for Automatic TE of AS March 2010 2.2. TE Control Message TE control message is used by TE server to control BGP messages which eBGP router sends to peer. TE control message may be iBGP message, NETCONF [5], or command of CLI over SSH [6]. Specifications of the TE control message is concretely defined by the other documents. 3. Role of Element 3.1. eBGP Router All eBGP routers in the autonomous system make traffic information , and send the traffic information to TE Server. The eBGP routers receive TE control message from TE server, send BGP message to eBGP peer according to the TE control message. 3.2. TE Server TE server receives traffic information which eBGP router sends and analyze the traffic information. Then, the TE server makes TE control message according to the result of analysis, and sends the TE control message to eBGP routers. This document doesn't treat the concrete algorithm for analyzing traffic information. 4. IANA Considerations This document does not raise any IANA consideration issues. 5. Security Considerations For communication between each element, this framework uses existing standard protocols(e.g. BGP). This framework does not change the security issues of these protocols. 6. Acknowledgments The work was partly supported by the Ministry of Internal Affairs and Communications, Japan. Suzuki & Jibiki Expires September 25, 2010 [Page 4] Internet-Draft A Framework for Automatic TE of AS March 2010 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 7.2. Informative References [3] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to version 2 of the Internet-standard Network Management Framework", RFC 1441, April 1993. [5] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [6] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. Authors' Addresses Kazuya Suzuki NEC Corporation 1753, Shimonumabe, Nakahara-ku Kawasaki, Kanagawa 211-8666 Japan Masahiro Jibiki NEC Corporation 1753, Shimonumabe, Nakahara-ku Kawasaki, Kanagawa 211-8666 Japan Suzuki & Jibiki Expires September 25, 2010 [Page 5]