One document matched: draft-ji-i2rs-usecases-ccne-service-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 RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.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-pce-stateful-pce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-pce-07.xml">
<!ENTITY I-D.chen-idr-rr-based-traffic-steering-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chen-idr-rr-based-traffic-steering-usecase.xml">
<!ENTITY I-D.medved-i2rs-topology-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-medved-i2rs-topology-im-01.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ji-i2rs-usecases-ccne-service-01"
ipr="trust200902">
<front>
<title abbrev="I2RS Use Cases for CCNE">I2RS Use Cases for Control of
Forwarding Path by Central Control Network Element (CCNE) </title>
<author fullname="Xiaofeng Ji" initials="X. " surname="Ji">
<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>jixiaofeng@huawei.com</email>
</address>
</author>
<author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
<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>zhuangshunwan@huawei.com</email>
</address>
</author>
<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="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"/>
<abstract>
<t> As network expand bridging access, Data Center and WAN,
more networks have a central control point for the network
elements in one administrative domain. This document defines
that network device as central control network element (CCNE).
The CCNE can be RR Router, PCE Server, or a federation of RR
Router and PCE Server, or other devices. This document
describes use case where the CCNE can utilize both these
the traditional functions and the programmatic
Interface to Routing System (I2RS) to communicate with devices
in the network. The I2RS use cases described in this document encompass:
Control IP Network by RR Router, Control MPLS TE Network
by PCE Server.</t>
<t> The goal of this document is to inform the
community's understanding of how CCNE extensions
fit within the overall I2RS architecture. It is intended to
provide a basis for the solutions draft describing the set
of interfaces for the CCNE device.
</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default" >
<t>I2RS working group is chartered to define an interface to the routing
system <xref target="I-D.ietf-i2rs-architecture" /> . This interface
can be used to read topology and forwarding
information of the routing system. This document discusses the use cases
of I2RS in controlling forward path scenario by CCNE.</t>
<t>With the development of network technologies, more and more
applications need to have a central control point for the network
elements in one administrative domain, such central control point is a
central control network element (CCNE). CCNE controls the network
elements in its administrative domain, the type of CCNE can be RR
Router, PCE Server, or a federation of RR Router and PCE Server, etc.
CCNE is developed from the traditional network element, which plus some
I2RS interfaces, can provide both traditional network services and I2RS
services.</t>
<t> This document describes requirement and use cases for which I2RS can
be used for CCNE device. The use cases described in this document
encompass: Control IP Network by RR Router, Control MPLS TE Network
by PCE Server. The goal is to inform the community's understanding
of where the I2RS CCNE extensions fit within the overall I2RS
architecture. It is intended to provide a basis for the solutions
draft describing the set of interfaces for the CCNE device.
</t>
</section>
<section title="Teminology" toc="default">
<t> </t>
<t>RIB: Routing Information Base</t>
<t>I2RS: Interface to Routing System</t>
<t>RR: Route Reflector</t>
<t>PCE: Path Computation Element</t>
<t>Central Controlled Network Element (CCNE): </t>
</section>
<section title="Use Case of I2RS in Control Forward Path by CCNE">
<t/>
<section title="I2RS Use Cases for Control Path by RR">
<t>A route reflector (RR) is a network routing component. It offers an
alternative to the logical full-mesh requirement of internal border
gateway protocol (IBGP). A RR acts as a focal point for IBGP sessions.
The purpose of the RR is concentration. Multiple BGP routers can peer
with a central point, the RR - acting as a route reflector server -
rather than peer with every other router in a full mesh. All the other
IBGP routers become route reflector clients.</t>
<t>Traditional IP network provides only Best Effort (BE) data
transmission capacity without assuring reachability, and does not
provide services with QOS assurance. Traditional IP path is not
explicit, and is difficult to monitor and tune. At the moment IP
Traffic Engineering usually is being implemented through complicated
route policy, and does not efficiently use network bandwidth.</t>
<t>With the IP network more and more widely used, users and
applications are placing increased demands on Internet service
providers (ISPs) to deliver explicit IP path configuration, flexible
route control, IP Traffic Engineering, better QOS, efficiently
monitoring and tuning method. To assist network operators in
addressing this challenge, we present some I2RS RR use cases, introduce
a set of I2RS programmatic APIs for RR that allows a network operator
to flexibly control routing between the traffic ingresses and egresses
within an ISP's network.</t>
<figure align="center">
<artwork><![CDATA[
+---------------------+
| APP + I2RS Client |
| (Central Controller)|
+---------------------+
|
[Interface for control ip forward network path]
|
+----------+ +-----------+
|RR Router |-[ BGP ]-| RR Router |
+----------+ +-----------+
|
[BGP]
|
+--------+
| Router |
+--------+
Figure 1. Control IP Network by RR
]]></artwork>
</figure>
<t/>
<section title="RR Provides Whole Network Views">
<t>For an IP network, if all routers run BGP and are connected by a
centralized RR, and the RR has the topology, network capacity,
network resource and customer policy etc information of the whole
network. Then APP or Controller can get the whole network views from
RR.</t>
<t>[<xref target="I-D.medved-i2rs-topology-im" />] defines the information model for
network topologies.</t>
<t/>
</section>
<section title="Explicit IP Path Configuration on RR">
<t>According to whole network views get from RR, applications can
push an explicit IP path configuration on RR. For example in Figure
2, a path from Source 1 (S1) to Destination 1 (D1): S1-A-B-C-D1. The
use of this path will be described in next Section.</t>
<t><figure align="center">
<artwork><![CDATA[ +-------------------+
| APP-I2RS Client |
| (CCNE) |
+-------------------+
|
[Interface for control ip forward network path]
|
----
/ \
| RR |
\ /
/-+-\
/ | \
/ | \
/ +--+-+ \
+--+-+/| | B | +--+-+
Source 1---| A | | +----+ | C |--- Destination 1
\ /+----+ | +----+\ /
* +---+----+-------+ *
/ \+--+-+ | +-+--+/ \
Source 2---| D | +--+-+ | F |--- Destination 2
+----+ | E | +----+
+----+
Figure 2: Route Reflection based Traffic Steering (RRTS)
]]></artwork>
</figure></t>
<t/>
</section>
<section title="RR based Traffic Steering">
<t>RR based Traffic Steering
([<xref target="I-D.chen-idr-rr-based-traffic-steering-usecase"/> ]) introduces
the requirements and use cases of RRTS.</t>
<t>For a product network, an acceptable solution should be able to
smoothly and incrementally upgrade the network and should not affect
the on-going services. Route Reflection is widely deployed in the
field, a Route Reflector (RR) has the ability to
"install"/distribute a route to its client with the nexthop that can
be either the RR itself or any other different BGP speakers. Given
this, for an IP network, if all routers run BGP and are connected by
a centralized RR, and the RR has the topology, network capacity,
network resource and customer policy etc information of the whole
network. Then the RR can compute the routes for every router and
install/distribute the routes to corresponding routers.</t>
<t><figure>
<artwork><![CDATA[
+-------------------+
| APP-I2RS client |
| (CCNE)
+-------------------+
|
[BGP RR API]
|
+------------+ +------------------+
| RR Router |--[Topology API]--| Topology Manager |
+------------+ +------------------+
|
[BGP API]
|
+------------+
| Router |
+------------+
Figure 3: An Architecture for RR
]]></artwork>
</figure>
Figure 3 shows an architecture for RR. APP and RR gets
topology information from Topology Manager via Topology API. APP
computes the IP Path and pushes the explicit IP Path Configuration
to RR via BGP RR API. RR transfers the IP Path into BGP routes and
pushes them to its clients via BGP API.</t>
<t>Figure 2 is a reference architecture of the Route Reflection
based Traffic Steering (RRTS). The RR and its route reflection
clients form a RRTS domain. The RR is a I2RS controller that is
responsible for the BGP route decision of the whole domain. All
other routers in the domain are as route reflection clients of the
RR, each router will establish an I-BGP session to the RR, and there
is no direct BGP sessions among these routers.</t>
<t>This looks no different from the current Route Reflector (RR)
based architecture. For each client, it will still run as current,
when received BGP routes from outside, it will transparently
distribute the routes to the RR. For each route, the RR will make
the decision for each relevant router and then install/distribute
the route to each related router.</t>
<t>For example, for a path from Source 1 (S1) to Destination 1 (D1),
if the computed path is: S1-A-B-C-D1, then the RR will distribute a
route (D1) to C with the nexthop set to D1; a route (D1) to B with
the nexthop set to C, and a route (D1) to A with the nexthop set to
B, and finally the route (D1) will be distributed to S1 by A.</t>
<t>RRTS will not require the clients to make any changes. All the
changes are made on the RR, the RR can apply any route or traffic
engineering algorithms.</t>
<t/>
</section>
<section title="RR Events">
<t/>
<section title="Notification of IP Path Events">
<t>With I2RS, it is conceivable that applications could tell the
status of an IP Path.</t>
<t/>
</section>
<section title="Tracing IP Paths">
<t>With I2RS, it would be possible for an I2RS controller to
rapidly gather information from across a large set of BGP routers
in the network via RR, then we can trace the state of IP path
easily.</t>
<t/>
</section>
</section>
</section>
<section title="I2RS Use Case for Control MPLS TE Network Path by PCE">
<t>Path computation in large, multi-domain networks is complex and may
require special computational components and cooperation between the
elements in different domains. PCE [<xref target="RFC4655" />] is proposed to address
this problem.</t>
<t>With PCE, operator can make more services and traffic to be hold in
the same MPLS TE network, and promote network resource
utilization.</t>
<t>The following describes set of use cases for which I2RS's
programmatic interfaces can be used to control and analyze MPLS TE
network. PCE use cases described in this document cover the following
aspects: TE Link attributes configuration, TE constraints
configuration, global concurrent re-optimization, network topology or
resource query and failure simulation. The goal is to inform the
community's understanding of where the I2RS PCE 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 PCE.</t>
<t/>
<section title="PCE Server Provides Whole MPLS TE Network Views">
<t>For MPLS TE network, if all routers run PCEP protocol and are
connected with PCE server or router, PCE device has the TE topology
and network resources of the whole network.</t>
<t>With I2RS, the centralized I2RS client (attached to application)
may get the whole TE topology and network resources from the PCE device. It is
not necessary for PCC devices to update to support I2RS.</t>
<t>Before upgrade a current network, network operator may need to
check if it is necessary. PCE makes it easy for operator to check
network resource by providing some user query interfaces.</t>
<t>With I2RS, the process may be put in I2RS Client, and
connected with other applications like resource visualized toos,
this will make it easy for operator do network management and
maintenance.</t>
<t/>
</section>
<section title="Global Concurrent Re-optimization">
<t>The stateful PCE [<xref target="I-D.ietf-pce-stateful-pce" />] specifies PCEP
extensions to enable stateful control of LSPs to PCE. With
delegation of control over LSPs from PCC, an active stateful PCE can
request a PCC to update one or more attributes of an LSP and to
re-signal the LSP with updated attributes. Global concurrent
re-optimization is a concurrent path computation application where a
set of TE paths are computed concurrently in order to efficiently
utilize network resources.</t>
<t><figure align="center">
<artwork><![CDATA[
+-------------------+
| APP -- I2RS Client|
| (on CCNE) |
+-------------------+
|
[Interface for control mple TE network path]
|
+----------+ +--------+
|PCE Server|--[PCEP]--| PCC |
| Router | | Router |
+----------+ +--------+
|
[PCEP]
|
+--------+
| PCC |
| Router |
+--------+
Figure 4. Control MPLS TE Network by PCE
]]></artwork>
</figure></t>
<t/>
<section title="TE Link and TE LSP Constraint Configuration">
<t>To adjust MPLS TE path more subtly, new link attributes such as
latency may be proposed to gain the goal. However, it is not a
good way to upgrade devices or extends protocols. It would be easy
if PCE provide interfaces to set TE links’ attributes and TE
LSPs’ constraints.</t>
<t>With I2RS, The interfaces can be extended to conveniently
adjust TE network logical topology.</t>
<t/>
</section>
<section title="Calculated Path Approve and Disapprove">
<t>With interfaces to set TE links’ attributes and TE
LSPs’ constraints would be provided, network operator may
trigger a global concurrent re-optimization after some
modification. He may want to check results before they take
effect. A confirmation mechanism is proposed for operator to
confirm the calculated result, and paths would be sent to PCC if
approved otherwise canceled.</t>
<t>With I2RS, I2RS client can easily promote the network
resource utilization by instructing the I2RS agent to
triggering PCE to do global concurrent re-optimization,
and report results. The I2RS Client can then approve
or disapprove with the calculated results based on internal
logic, and then send any changs to the I2RS Agents on
the appropriate nodes.</t>
<t/>
</section>
</section>
<section title="Failure Simulation">
<t>In network upgrade, operator typically fist find the traffic
passing the node or link to be upgraded, estimate the affection. If
it is accepted, operator will switch over the traffic and switch
back after the upgrade. It is arduous for operator to estimate the
affection of link or node failure, more ever, there is not only one
failure.</t>
<t>With I2RS, I2RS controller may easily address the problem. I2RS
client could ask all I2RS agents for appropriate nodes to
send status information on the link failure links or nodes failures.
Based on this information, the I2RS client could pass information
to a local PCE devices (via PCE protocol or I2RS updates)
to do failure simulation based on the status information.
After the failure simulation, the I2RS client could then
update adjusted pathways to the I2RS agent.
</t>
<t/>
</section>
</section>
<section title="Requirements for I2RS from the use cases">
<t>From the above use case, the requirements for I2RS are:</t>
<t>1. I2RS interface should support I2RS client running on a
CCNE to be able to pull information from both the BGP RR and
the PCE. This information can include: BGP topology information,
BGP routes, BGP statistics, BGP Peer topologies, PCE topology
information, and PCE state information. The I2RS Client's request
for reading of the RR and PCE topology information
needs to have timely and rapid response from the I2RS Agent. </t>
<t>2. I2RS client should be able to set resource constraints
at the I2RS Agent, and receive status information on the
setting of resource constraints.</t>
<t>3. I2RS interface should be able to set service goal value to
CCNE.</t>
<t>4. I2RS client should be able support information models
that allow re-optimization traffic model at at CCNE .</t>
<t>5. I2RS client should be able to receive notification at
the CCNE, and be able to send status to the I2RS agent. </t>
<t>6. I2RS client should work in parallel with traditional
network management or OAM protocols sent to the general NE.
</t>
<t>7. I2RS clients should be able to to be light weight enough
to be able to support running on a variety of devices (routers,
centralized servers, or devices doing both). </t>
<t/>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Routing information is very critical and sensitive information for
the operators. I2RS should provide strong security mechanism to protect
the routing information that it could not be accessed by the
un-authorised users. It should also protect the security and integrity
protection of the routing data.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4655;
</references>
<references title="Informative References">
&I-D.ietf-i2rs-architecture;
&I-D.ietf-pce-stateful-pce;
&I-D.chen-idr-rr-based-traffic-steering-usecase;
&I-D.medved-i2rs-topology-im;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:52:04 |