| Routing Area Working Group | T. Huang |
| Internet-Draft | Z. Li |
| Intended status: Informational | S. Hares |
| Expires: January 5, 2015 | Huawei Technologies |
| July 4, 2014 |
Use Cases for an Interface to MPLS TE
draft-huang-i2rs-mpls-te-usecases-02
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 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.
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 January 5, 2015.
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.
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 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.
This section summarize the requirements from the MPLS TE use cases. Each of these requirements has been given an an ID number of MPLS-TE-REQ-nn for ease of reference. While this summary provides a handy reference, the reader is advised to review the full details of the MPLS TE scenario.
The requirements from the Traffic Steering use case are:
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.
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.
[MPLS-TE-REQ-01] Network programming software managing the static CR-LSP devices may incorporate an I2RS Client along with a path calculation entity, a 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.
[MPLS-TE-REQ-02] 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.
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.
[MPLS-TE-REQ-03:] 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.
[MPLS-TE-REQ-04:] 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.
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.
[MPLS-TE-REQ-05] With I2RS, the node's I2RS agent can send to an I2RS client the status notification of not enough resources for back up LSP and TE tunnel. Upon receiving this notification the I2RS client could trigger concurrent calculation for the failed path calculation of the backup LSP or TE tunnel and send the updated paths to I2RS agents with a command to re-signal the TE LSPS with make-before-break Method.
This section describes use cases for the MPLS TE traffic switch over caused by failure detection, network upgrading, overloading, and schedule traffic movements.
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.
[MPLS-TE-REQ-06] 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.
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.
[MPLS-TE-REQ-07] 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).
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.
[MPLS-TE-REQ-08] I2RS agents can notify I2RS Clients of impending or existing MPLS TE overload conditions that might cause TE LSP rejections. This overload conditions include: due to CPU, memory, LSP label space, or LSP numbers.
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.
[MPLS-TE-REQ09] 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.
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.
[MPLS-TE-REQ-10] 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.
In the global concurrent re-optimization process in section 2.2, an LSP update may depend on another LSP to release resources for it.
[MPLS-TE-REQ-11] The 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. [MPLS-TE-REQ-12] The I2RS Client can gather the TE LSPs' state from I2RS Agents on all nodes in order to coordinate such handling of LSP resources.
[MPLS-TE-REQ-13] 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
+--------------------------+
| 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
This document includes no request to IANA.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |