Internet DRAFT - draft-huang-i2rs-mpls-te-usecases
draft-huang-i2rs-mpls-te-usecases
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
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
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 January 5, 2015 [Page 1]
Internet-Draft I2RS MPLS LDP July 2014
This Internet-Draft will expire on January 5, 2015.
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. I2RS Requirements from the MPLS TE Use cases . . . . . . . . 3
3. MPLS TE Configuration . . . . . . . . . . . . . . . . . . . . 5
3.1. Static CR-LSP Configuration . . . . . . . . . . . . . . . 5
3.2. RSVP-TE Policy Configuration . . . . . . . . . . . . . . 6
4. MPLS TE Protection . . . . . . . . . . . . . . . . . . . . . 6
5. MPLS TE Traffic Switch Overs . . . . . . . . . . . . . . . . 7
5.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 7
5.2. Network Upgrading . . . . . . . . . . . . . . . . . . . . 7
5.3. Handling Node Overload . . . . . . . . . . . . . . . . . 8
6. Monitoring of MPLS TE . . . . . . . . . . . . . . . . . . . . 8
6.1. Performance Monitoring . . . . . . . . . . . . . . . . . 8
6.2. Fault Monitoring . . . . . . . . . . . . . . . . . . . . 9
6.3. LSP Monitoring . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
Huang, et al. Expires January 5, 2015 [Page 2]
Internet-Draft I2RS MPLS LDP July 2014
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.
2. I2RS Requirements from the MPLS TE Use cases
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:
o 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 should be abl to communicate
the static configuration to the network nodes, and monitor the
status of the CR-LSPs.
o MPLS-TE-REQ-02: The I2Client should be able to synchronously send
the configuration for all of the network nodes from egress node to
ingress node via the I2RS Agents attached to each node, and be
able to delay the final ingress node configuration until all the
Huang, et al. Expires January 5, 2015 [Page 3]
Internet-Draft I2RS MPLS LDP July 2014
I2RS AGents on all other nodes toward the egress have denoted a
successful path set-up.
o [MPLS-TE-REQ-03:] MPLS TE defines abundant constraints such as
explicit path, bandwidth, affinity, SRLG, priority, hop limit, and
others. The I2RS Client Agent exchange should be able to signal
concurrent local path calculation could obtain an optimized result
and allow more services to be held in a TE network. The I2RS
Agent should be able to trigger a global concurrent re-
optimization at a specific time on multiple nodes by communicating
with each node's I2RS agent.
o [MPLS-TE-REQ-04:] The I2RS client should be able to manually
calculate a re-optimization of the 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.
o [MPLS-TE-REQ-05] With I2RS, the node's I2RS agent should be able
to send to an I2RS client a status notification that not enough
resources exist for a back up LSP and TE tunnel. Upon receiving
this notification the I2RS client should be able to 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.
o [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 signalling 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.
o [MPLS-TE-REQ-07] Upon receiving a signal an upgrade event signal
(from operator), the I2RS client could calculate another path for
the affected TE tunnels to deviate traffic away from the resource
being upgraded, and then send the request to 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).
o [MPLS-TE-REQ-08] I2RS agents can notify I2RS Clients of impending
or existing MPLS TE overload conditions that might cause TE LSP
Huang, et al. Expires January 5, 2015 [Page 4]
Internet-Draft I2RS MPLS LDP July 2014
rejections. This overload conditions include: due to CPU, memory,
LSP label space, or LSP numbers.
o [MPLS-TE-09] Automatic bandwidth adjustment applications can also
be linked to the I2RS clients need to monitor the traffic on TE
tunnels in order to provide traffic analysis. The I2RS client
should be able to 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 also needs to be able to
the I2RS agents in the nodes to install the new TE Tunnels with
the make-before-break option.
o [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.
o [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.
o [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 single location.
3. 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.
3.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.
Huang, et al. Expires January 5, 2015 [Page 5]
Internet-Draft I2RS MPLS LDP July 2014
[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.
3.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.
[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.
4. 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.
Huang, et al. Expires January 5, 2015 [Page 6]
Internet-Draft I2RS MPLS LDP July 2014
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.
5. 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.
5.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.
[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.
5.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.
[MPLS-TE-REQ-07] With I2RS, the operator signals the upgrade event to
the application associated with the I2RS client. The I2RS client
Huang, et al. Expires January 5, 2015 [Page 7]
Internet-Draft I2RS MPLS LDP July 2014
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).
5.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.
[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.
6. Monitoring of MPLS TE
6.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.
[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.
Huang, et al. Expires January 5, 2015 [Page 8]
Internet-Draft I2RS MPLS LDP July 2014
6.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.
[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.
6.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.
[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
Huang, et al. Expires January 5, 2015 [Page 9]
Internet-Draft I2RS MPLS LDP July 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
7. IANA Considerations
This document includes no request to IANA.
8. 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 January 5, 2015 [Page 10]
Internet-Draft I2RS MPLS LDP July 2014
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.hares-i2rs-use-case-vn-vc]
Hares, S. and M. Chen, "Use Cases for Virtual Connections
on Demand (VCoD) and Virtual Network on Demand (VNoD)
using Interface to Routing System", draft-hares-i2rs-use-
case-vn-vc-02 (work in progress), February 2014.
[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-04 (work in
progress), June 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-04 (work in progress), June 2014.
[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-03 (work in progress), May 2014.
[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, "Controlling State Advertisements
Of Non-negotiated LDP Applications", draft-ietf-mpls-ldp-
ip-pw-capability-07 (work in progress), April 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-07 (work in progress), June 2014.
Huang, et al. Expires January 5, 2015 [Page 11]
Internet-Draft I2RS MPLS LDP July 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
Susan Hares
Huawei Technologies
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Huang, et al. Expires January 5, 2015 [Page 12]
