Network Working Group T. Huang Internet-Draft Z. Li Intended status: Informational Huawei Technologies Expires: April 23, 2014 October 20, 2013 Use Cases for an Interface to MPLS TE draft-huang-i2rs-mpls-te-usecases-00 Abstract An MPLS Traffic Engineering(TE) network is typically configured and results of its operation are analyzed by Command Line Interface (CLI), SNMP or NETCONF. These interactions to control MPLS TE and diagnose its operation encompass: MPLS TE configuration, MPLS TE protection, traffic switching-over, monitoring of MPLS TE and fault detection. Interface to the Routing System's (I2RS) Programmatic interfaces, as defined in [I-D.ward-i2rs-framework], provides an alternate way to control the configuration and diagnose the operation of MPLS TE. I2RS may be used for the configuration, manipulation, polling or analyzing MPLS TE. This document describes set of use cases for which I2RS can be used for MPLS TE. It is intended to provide a base for the solution draft describing a set of interfaces to MPLS TE. 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2014. Huang & Li Expires April 23, 2014 [Page 1] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 Copyright Notice Copyright (c) 2013 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. MPLS TE Configuration . . . . . . . . . . . . . . . . . . . . 3 2.1. Static CR-LSP Configuration . . . . . . . . . . . . . . . 3 2.2. RSVP-TE LSP Configuration . . . . . . . . . . . . . . . . 4 3. MPLS TE Protection . . . . . . . . . . . . . . . . . . . . . 4 4. MPLS TE Traffic Switching-over . . . . . . . . . . . . . . . 5 4.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 5 4.2. Network Upgrading . . . . . . . . . . . . . . . . . . . . 5 4.3. Overloading . . . . . . . . . . . . . . . . . . . . . . . 5 5. Monitoring of MPLS TE . . . . . . . . . . . . . . . . . . . . 6 5.1. Performance Monitoring . . . . . . . . . . . . . . . . . 6 5.2. Fault monitoring . . . . . . . . . . . . . . . . . . . . 6 5.3. LSP State Monitoring . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Typically, an MPLS TE network configured and results of its operation are analyzed by CLI, SNMP or NETCONF. These interactions to control MPLS TE and diagnose its operation encompass: MPLS TE configuration, MPLS TE protection, traffic switching-over, traffic detection and fault detection. The I2RS Framework document [I-D.ward-i2rs-framework] describes a mechanism to control network protocols like MPLS TE using a set of programmatic interfaces. These programmatic interfaces allow one to Huang & Li Expires April 23, 2014 [Page 2] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 control MPLS TE network by analyzing its operational state and TE LSP data, plus manipulating TE LSP's configuration to achieve various goals. The I2RS is not intended to replace any existing configuration mechanisms, (i.e.: Command Line Interface or NETCONF). Instead, I2RS is intended to augment those existing mechanisms by defining a standardized set of programmatic interfaces to enable easier configuration, interrogation and analysis of MPLS TE network. This document describes set of use cases for which I2RS's programmatic interfaces can be used to control and analyze the operation of MPLS TE. The use cases described in this document cover the following aspects of MPLS TE: MPLS TE configuration, MPLS TE protection, MPLS TE traffic switching-over, monitoring of MPLS TE and fault detection. The goal is to inform the community's understanding of where the I2RS MPLS TE extensions fit within the overall I2RS architecture. It is intended to provide a basis for the solutions draft describing the set of Interfaces to the MPLS TE. This document describes set of use cases for which I2RS's programmatic interfaces can be used to control and analyze the operation of MPLS TE. The use cases described in this document cover the following aspects of MPLS TE: MPLS TE configuration, MPLS TE protection, MPLS TE traffic switching-over, monitoring of MPLS TE and fault detection. The goal is to inform the community's understanding of where the I2RS MPLS TE extensions fit within the overall I2RS architecture. It is intended to provide a basis for the solutions draft describing the set of Interfaces to the MPLS TE. 2. MPLS TE Configuration There is two types of TE LSP: static CR-LSP and dynamic TE LSP created by protocol of RSVP-TE or CR-LDP. Static CR-LSP is configured with forwarding items such as interface, label and bandwidth etc. node by node. Dynamic TE LSP is configured with MPLS TE parameters which are used to calculate path and set up TE LSP by protocol. Both configurations are complex Following will introduce how to improve configuration efficiency with I2RS and I2RS controller. 2.1. Static CR-LSP Configuration Nodes and interfaces to be gone through should be prepared with label and bandwidth before a static CR-LSP configuration, and then static CR-LSP will be configured through some forms of CLI or NETCONF. Static CR-LSP is used in small, simple topology and less service for its complex configuration. Huang & Li Expires April 23, 2014 [Page 3] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 Network programming software may be put in I2RS controller, and the software may include a path calculation entity, a label management entity and a bandwidth management entity. With I2RS, it will greatly improve static CR-LSP configuration efficiency. LSP forward downloading is processed node by node. When ingress node finishes forward downloading, the other nodes' forward item may not be ready and traffic will be lost in this condition. With I2RS, I2RS controller my download the forwarding items from egress node to ingress node, and download the next node forwarding item after getting the forward downloading success event from the fore device. 2.2. RSVP-TE LSP Configuration MPLS TE defines abundant constraints such as explicit path, bandwidth, affinity, SRLG, priority and hop limit etc. Local path calculation entity would calculate an appropriate path according to the constraints. It is known to all that the calculated results are closely related with the request order, different calculation order may have different results. Concurrent calculation would get the optimized result and hold more services in TE network. With I2RS, I2RS central controller would trigger global concurrent re-optimization timely or manually to re-optimize MPLS TE network and send the constraints include the calculated path to devices to re- signal the TE LSPs with make-before-break method. 3. MPLS TE Protection There are so many kinds of protection for MPLS TE, such as TE tunnel protection, TE LSP protection and TE FRR protection. Further, each protection may have two methods: 1:1 and 1+1 protection. FRR may have another two methods: link and node protection. With I2RS, I2RS controller can define the protection mode according to the service requirement. In addition, typically when it is told that there is no enough resource for the backup LSP or TE tunnel, it is usually not true in the distributed network. If existing LSP or TE tunnel could be adjusted to bypass some links or nodes, resource will be released to the backup LSP or TE tunnel. With I2RS, I2RS central controller would trigger concurrent calculation by the failed path calculation for the backup LSP or TE tunnel events. Then the updated path will be set to devices to re-signal the TE LSPs with make-before-break method. MPLS TE network would be re-optimized to hold the backup LSP or TE tunnel. Huang & Li Expires April 23, 2014 [Page 4] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 With I2RS, I2RS central controller would trigger concurrent calculation by the fail calculation for the backup LSP or TE tunnel events and send updated path to devices to re-signal the TE LSPs with make-before-break method. MPLS TE network would be re-optimized to hold the backup LSP or TE tunnel. 4. MPLS TE Traffic Switching-over This section describes set of use cases of MPLS TE traffic switching- over. The use cases described in this section cover the following aspects: failure detection, network upgrading, overloading and switch-over on schedule. 4.1. Failure Detection There are many failure detect technologies such as Ethernet OAM/BFD/ OAM/RSVP Hello. When a failure is detected, traffic will be switched over to the backup path. Re-optimization of the TE tunnel may fail for insufficient resource. With I2RS, I2RS central controller would trigger global concurrent optimization for the fail event and send updated path to devices to re-signal the TE LSPs with make-before-break method. 4.2. Network Upgrading When upgrading in a network are planned (e.g., for maintenance purposes), some graceful mechanisms can be used to gracefully shut down MPLS-TE / GMPLS-TE on such resource as a TE link, a component link within a bundled TE link, a label resource, or an entire TE node, to avoid traffic disruption. Typically IGP or RSVP-TE protocol is extended to notify ingress node to bypass the shut down point. With I2RS, I2RS controller gets the upgrade event from operator, and calculate another path for the affected TE tunnels to deviate the traffic from the resource to be upgraded. After finishing upgrade, I2RS controller would switch back the traffic or re-optimize all the TE tunnels. This will simplify the process without protocol extension. 4.3. Overloading When there is overloading in some nodes, such as CPU overloading, memory overloading, label overloading or LSP number overloading in some nodes, setup of new TE LSPs should be rejected at this condition. However, existing TE LSPs may be affected and TE LSPs flapping would occur. Huang & Li Expires April 23, 2014 [Page 5] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 Typically, a threshold value is set to avoid overloading, setup of new TE LSPs should be rejected in advance to avoid affection of the existing TE LSPs. Protocol like IGP or RSVP-TE would be extended to take some new error code to notify all other nodes or ingress node to bypass the overloading nodes. With I2RS, I2RS controller may monitor devices and find overloading occurrence and disappearance, and it will avoid to choose the overloading node in the following calculations without protocol extension. 5. Monitoring of MPLS TE 5.1. Performance Monitoring Typically, performance measurement such as traffic statistics is done in the ingress node of TE tunnel. There are many application about traffic analysis, traffic dining, and traffic forecast etc. The applications depend on the statistics information reported to a central controller. With I2RS, I2RS controller provides a platform to implement these applications. In automatic bandwidth adjustment application, with I2RS, I2RS controller would monitor and analyze TE tunnel real traffic and calculate a new path with the new bandwidth for TE tunnel if it is needed, and send to devices to re-signal the TE tunnel with make- before-break method. 5.2. Fault monitoring When node or link failure happens, traffic will be switched over to the backup path. At the same time, the failure information will be reported and recorded. Network operator will process network management and maintenance based on the failed information. With I2RS, the failed information may be reported to the I2RS central controller. 5.3. LSP State Monitoring In global concurrent re-optimization process in section 2.2, an LSP update may depend on another LSP to release resource for it. I2RS controller will notify devices to re-signal TE LSPs one by one if there is dependency. I2RS controller should be aware of the TE LSPs' state. With I2RS, I2RS controller would monitor the TE LSPs' state. 6. IANA Considerations Huang & Li Expires April 23, 2014 [Page 6] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 This document makes no request of IANA. 7. Security Considerations The MPLS TE use cases described in this document assumes use of I2RS's programmatic interfaces described in the I2RS framework mentioned in [I-D.ward-i2rs-framework]. This document does not change the underlying security issues inherent in the existing [I-D .ward-i2rs-framework]. 8. References 8.1. Normative References [I-D.ward-i2rs-framework] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Framework", draft-ward-i2rs-framework-00 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. Authors' Addresses Tieying Huang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: huangtieying@huawei.com Huang & Li Expires April 23, 2014 [Page 7] Internet-Draft Use Cases for an Interface to MPLS TE October 2013 Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Huang & Li Expires April 23, 2014 [Page 8]