Routing Area Working Group T. Huang Internet-Draft Z. Li Intended status: Informational Huawei Technologies Expires: August 18, 2014 S. Hares Hickory Hill Consulting February 14, 2014 Use Cases for an Interface to MPLS TE draft-huang-i2rs-mpls-te-usecases-01 Abstract Network services based on Virtual Networks (VN) or Virtual Circuits (VC) may be run over MPLS-TE links, and support network configurations such as hub-spoke, service routing, or on-demand networks. An MPLS Traffic Engineering(TE) network is typically configured and the results of its operation analyzed through network management interfaces (CLI, SNMP or NETCONF). These interactions to control each of the MPLS TE links, and diagnose operations issues concerning link configuration, MPLS TE protection, and traffic switching-over. The network management functions also monitor MPLS TE links and provide fault detection. The Interface to the Routing System (I2RS) (draft-ietf-i2rs- architecture) programmatic interface to the routing system provides an alternative way to control the configuration and diagnose the operation of MPLS links. I2RS may be used for the configuration, manipulation, polling or analyzing MPLS TE. This document describes a set of use cases for which I2RS can be used for MPLS TE. It is intended to provide a base for a solution draft describing I2RS information models and protocol functions that will support virtual networks that utilize MPLS TE. 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." Huang, et al. Expires August 18, 2014 [Page 1] Internet-Draft I2RS MPLS LDP February 2014 This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 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 Policy Configuration . . . . . . . . . . . . . . 4 3. MPLS TE Protection . . . . . . . . . . . . . . . . . . . . . 4 4. MPLS TE Traffic Switch Overs . . . . . . . . . . . . . . . . 5 4.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 5 4.2. Network Upgrading . . . . . . . . . . . . . . . . . . . . 5 4.3. Handling Node Overload . . . . . . . . . . . . . . . . . 6 5. Monitoring of MPLS TE . . . . . . . . . . . . . . . . . . . . 6 5.1. Performance Monitoring . . . . . . . . . . . . . . . . . 6 5.2. Fault Monitoring . . . . . . . . . . . . . . . . . . . . 6 5.3. LSP Monitoring . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Network services based on Virtual Networks (VN) or Virtual Circuits (VC) may be run over MPLS-TE links, and support network configurations such as hub-spoke, service routing, or on-demand networks. Typically, MPLS TE networks are configured and results of its operation analyzed through network management interfaces (CLI, SNMP or NETCONF). These interactions to control MPLS TE links and diagnose their operation encompass: MPLS TE configuration, MPLS TE Huang, et al. Expires August 18, 2014 [Page 2] Internet-Draft I2RS MPLS LDP February 2014 protection, traffic switching-over, traffic detection, and fault detection. The I2RS architecture and protocol as defined in [[I-D.ietf-i2rs-architecture]] may be used to control network protocols like MPLS TE using a set of programmatic interfaces. These programmatic interfaces allow one I2RS client to control the MPLS TE network by analyzing its operational state and TE LSP data, plus manipulating TE LSP's configuration to achieve various goals. I2RS is not intented to replace any replace any existing network management or configuration mechanisms, (E.g. Command Line Interface or NETCONF). Instead, I2RS is intended to augment these existing mechanisms by defining a standardized set of programmatic interfaces to enable easier configuration, interrogation and analysis of the protocol. 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 switch-over, monitoring of MPLS TE and fault detection. The goal is to increase 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 are 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. The following cases will introduce how to improve configuration efficiency with I2RS and I2RS client. 2.1. Static CR-LSP Configuration Currently, nodes and interfaces to be configured with a Static CR-LSP are assigned label and bandwidth values before the static CR-LSP is configured through some network management configuration interface (e.g. CLI or NETCONF). Due to this complex configuration, Static CR- LSP is only used in small, simple topologies with few services. Network programming software managing the static CR-LSP devices may incorporate an I2RS Client along with a path calculation entity, a Huang, et al. Expires August 18, 2014 [Page 3] Internet-Draft I2RS MPLS LDP February 2014 label management entity, and a bandwidth management entity. The I2RS Client will communicate the static configuration to the network nodes, and monitor the status of the CR-LSPs. Currently the downloading of CR-LSP forwarding is processed node by node. When an ingress node finishes download before all other nodes have completed, the forwarding path will not be set-up and the traffic will be lost. With I2RS, the I2RS client may send the configuration for all of the network nodes from egress node to ingress node. The final ingress node configuration may delayed until all other nodes toward the egress have denoted a successful path set-up. 2.2. RSVP-TE Policy Configuration MPLS TE defines abundant constraints such as explicit path, bandwidth, affinity, SRLG, priority, hop limit, and others. A local path calculation entity would calculate an appropriate path according to the constraints. It is common knowledge that the calculated results are closely related with the request order, different calculation order may have different results. Concurrent calculation could obtain an optimized result and allow more services to be held in a TE network. With I2RS, an I2RS client could trigger global concurrent re- optimization at a specific time on multiple nodes by communicating with each node's I2RS agent. Alternatively, the I2RS client could manually re-optimize the MPLS TE network and send the new constraints including the calculated path to each node via the I2RS agent with an indication to re-signal the TE LSPs with make-before-break method. 3. MPLS TE Protection There are 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 client can define the protection mode according to the service requirement and transmit to the I2RS agent on each node. In addition, typically when one node's calculations determine that there is not enough resource for the backup LSP or TE tunnel, it is usually not true in the distributed network. If the existing LSP or TE tunnel could be adjusted to bypass some links or nodes, the necessary resources will be released to provide the backup LSP or TE tunnel. With I2RS, the I2RS client would trigger concurrent calculation for the failed path calculation of the backup LSP or TE Huang, et al. Expires August 18, 2014 [Page 4] Internet-Draft I2RS MPLS LDP February 2014 tunnel and the updated paths will be sent to I2RS agents to re-signal the TE LSPs with make-before-break method. 4. MPLS TE Traffic Switch Overs This section describes use cases for the MPLS TE traffic switch over caused by failure detection, network upgrading, overloading, and schedule traffic movements. 4.1. Failure Detection There are many failure detection 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, upon receipt the failure notification from an I2RS Agent, the I2RS client would create a global concurrent optimization to handle the failure event. This would occur by the I2RS client signaling the I2RS agents on all nodes to: a) trigger a new concurrent calculation of the backup LSP or TE tunnel via failed path calculation, and b) re-signal updates to the TE LSPs process with a make-before-break method. 4.2. Network Upgrading When upgrades in a network are planned (e.g., for maintenance purposes), some graceful mechanisms can be used to avoid traffic disruption by gracefully shutting down MPLS-TE or GMPLS-TE resources. The resources include TE links, component links within bundled TE links, label resources, and an entire TE node. Typically IGP or RSVP-TE protocol is extended to notify ingress node to bypass the shut down point. With I2RS, the operator signals the upgrade event to the application associated with the I2RS client. The I2RS client could calculate another path for the affected TE tunnels to deviate traffic away from the resource being upgraded. The I2RS client would then communicate with I2RS agents on the appropriate nodes to move the traffic. After the upgrade completes, the I2RS client can simply remove I2RS configurations causing the traffic to revert to the original path. Or, the I2RS can re-optimize the TE tunnels for another pathways (E.g. as a part of a sequence of upgrades). Huang, et al. Expires August 18, 2014 [Page 5] Internet-Draft I2RS MPLS LDP February 2014 4.3. Handling Node Overload When a node with MPLS TE support becomes overloaded due to the usage exceeding maximums of CPU, memory, LSP label space, or LSP number space, the setup of new TE LSPs should be rejected. The overload condition may also impact existing LSPs, and even cause flapping of MPLS TEs. Typically, a threshold value is set to avoid the overload condition so that existing TE LSPs will not be impacted. Normally, IGP protocols or RSVP-TE would be extended to notify all other nodes of the overload condition. This notification allows ingress nodes to bypass the overloaded node. 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. Applications such as traffic analysis or traffic forecasts depend on these traffic statistics being reported to centralize site for processing With I2RS, the I2RS client can be attached to the application as gather the traffic statistics from I2RS agents running on the ingress nodes. Automatic bandwidth adjustment applications can also be linked to the I2RS clients that monitor the traffic on TE tunnels and provide analysis. The I2RS client can read the TE Tunnel topology and the bandwidth analysis in order to automatically calculate a new path for the TE tunnel if it is needed. The I2RS Client would then signal the I2RS agents in the nodes to install the new TE Tunnels with the make- before-break option. 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 operators will process network management and maintenance based on the failed information. With I2RS, the node failure or link failure can be part of the notification stream sent by an I2RS Agent to an I2RS Client on a centralized server gathering information. Huang, et al. Expires August 18, 2014 [Page 6] Internet-Draft I2RS MPLS LDP February 2014 5.3. LSP Monitoring In the global concurrent re-optimization process in section 2.2, an LSP update may depend on another LSP to release resources for it. I2RS client can notify the I2RS agents on specific nodes (or devices) to re-signal TE LSPs one by one if there is a resource dependency. The I2RS Client can gather the TE LSPs' state from I2RS Agents on all nodes in order to coordinate such handling of LSP resources. The I2RS Clients collecting information from I2RS Agents can be arranged in a hierarchy to provide scaling of collections. An application hosting an I2RS client collecting information from I2RS Agents on nodes can have an I2RS Agent that reports combined information to a centralized service as shown in the figure 1 below Huang, et al. Expires August 18, 2014 [Page 7] Internet-Draft I2RS MPLS LDP February 2014 +--------------------------+ | Centralized LSP | | Monitoring Application | | I2RS Client-L2 | +-----------+--------------+ ^ /|\ (1-N I2RS Client-2 to I2RS Agents) | +-----------^----------------------------+ | I2RS Agent-L2 | | Traffic Statistics Collection | | Collection Application | | I2RS Client-L1 | +-+---------------+-----------------|----+ ^ ^ ^ /|\ 1-N nodes /|\ 1-N Nodes /|\ | | | +------^---------+ +--^------------+ +---------------+ | I2RS Agent-L1 | | I2RS Agent-L1 | | I2RS Agent-L1 | | Performance | | LSP State | | Fault | | Monitoring | | Monitoring | | Monitoring | +----------------+ +---------------+ +---------------+ | | : : : : ! | | : : : : ! | | : : : : ! | ................: : : : ! | : | .......: : :........ ! | : | : : : ! | : | : : : ! +-V--V--+ +-V--V--+ +---V---+ +---V-----V--+ |MPLS-TE| |MPLS-TE| |MPLS-TE| | MPLS-TE | | Link | | Link | | Link | | Link | +-------+ +-------+ +-------+ +------------+ Figure 1: I2Client-Agent pairs for scalable monitoring 6. IANA Considerations This document includes no request to 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.ietf-i2rs-architecture], and as a use case does not change the underlying security issues. Huang, et al. Expires August 18, 2014 [Page 8] Internet-Draft I2RS MPLS LDP February 2014 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.hares-i2rs-use-case-vn-vc] Hares, S., "Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand using Interface to Routing System", draft-hares-i2rs-use-case-vn-vc-00 (work in progress), February 2013. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-01 (work in progress), February 2014. [I-D.ietf-i2rs-problem-statement] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", draft-ietf-i2rs- problem-statement-00 (work in progress), August 2013. [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-ietf-i2rs-rib-info- model-01 (work in progress), October 2013. [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-ietf-i2rs-rib-info- model-01 (work in progress), October 2013. [I-D.ietf-mpls-ldp-dod] Beckhaus, T., Decraene, B., Tiruveedhula, K., Konstantynowicz, M., and L. Martini, "LDP Downstream-on- Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work in progress), July 2013. [I-D.ietf-mpls-ldp-ip-pw-capability] Raza, K. and S. Boutros, "Disabling IPoMPLS and P2P PW LDP Application's State Advertisement", draft-ietf-mpls-ldp- ip-pw-capability-06 (work in progress), June 2013. Huang, et al. Expires August 18, 2014 [Page 9] Internet-Draft I2RS MPLS LDP February 2014 [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-05 (work in progress), January 2014. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. Authors' Addresses Tieying Huang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: Huangtieying@huawei.com Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Huang, et al. Expires August 18, 2014 [Page 10] Internet-Draft I2RS MPLS LDP February 2014 Susan Hares Hickory Hill Consulting 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Huang, et al. Expires August 18, 2014 [Page 11]