One document matched: draft-huang-i2rs-mpls-te-usecases-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4447 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4447.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC5283 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5283.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-mpls-ldp-ip-pw-capability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-ip-pw-capability.xml">
<!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml">
<!ENTITY I-D.ietf-mpls-ldp-dod SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-dod.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.hares-i2rs-use-case-vn-vc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-use-case-vn-vc.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-huang-i2rs-mpls-te-usecases-01"
ipr="trust200902">
<front>
<title abbrev="I2RS MPLS LDP">Use Cases for an Interface to MPLS
TE</title>
<author fullname="Tieying Huang" initials="T" surname="Huang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>Huangtieying@huawei.com</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Hickory Hill Consulting</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date month="February" year="2014"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>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.</t>
<t>The I2RS architecture and protocol as defined in [<xref
target="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.</t>
<t>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.</t>
</section>
<section title="MPLS TE Configuration" toc="default">
<t>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.</t>
<t>The following cases will introduce how to improve configuration
efficiency with I2RS and I2RS client.</t>
<section title="Static CR-LSP Configuration">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="RSVP-TE Policy Configuration">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="MPLS TE Protection" toc="default">
<t>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.</t>
<t>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 tunnel and the updated
paths will be sent to I2RS agents to re-signal the TE LSPs with
make-before-break method.</t>
</section>
<section title="MPLS TE Traffic Switch Overs " toc="default">
<t>This section describes use cases for the MPLS TE traffic switch over
caused by failure detection, network upgrading, overloading, and
schedule traffic movements.</t>
<section title="Failure Detection ">
<t>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.</t>
<t>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.</t>
</section>
<section title="Network Upgrading ">
<t>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.</t>
<t>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).</t>
</section>
<section title="Handling Node Overload">
<t>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.</t>
</section>
</section>
<section title="Monitoring of MPLS TE" toc="default">
<t/>
<section title="Performance Monitoring">
<t>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</t>
<t>With I2RS, the I2RS client can be attached to the application as
gather the traffic statistics from I2RS agents running on the ingress
nodes.</t>
<t>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.</t>
</section>
<section title="Fault Monitoring">
<t>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.</t>
<t>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.</t>
</section>
<section title="LSP Monitoring">
<t>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.</t>
<t>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</t>
<figure>
<artwork><![CDATA[
+--------------------------+
| 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
]]></artwork>
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The MPLS TE use cases described in this document assumes use of
I2RS's programmatic interfaces described in the I2RS framework mentioned
in <xref target="I-D.ietf-i2rs-architecture"/>, and as a use case does
not change the underlying security issues.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC4364;
&RFC4447;
&RFC4762;
&RFC5036;
&RFC5283;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-mpls-ldp-ip-pw-capability;
&I-D.ietf-mpls-seamless-mpls;
&I-D.ietf-mpls-ldp-dod;
&I-D.hares-i2rs-use-case-vn-vc;
&I-D.ietf-i2rs-rib-info-model;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:23:43 |