One document matched: draft-huang-i2rs-mpls-te-usecases-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:01:18 |