Network Working Group X. Ji
Internet-Draft S. Zhuang
Intended status: Informational T. Huang
Expires: August 17, 2014 Huawei Technologies
S. Hares
Hickory Hill Consulting
February 13, 2014
I2RS Use Cases for Control of Forwarding Path by Central Control Network
Element (CCNE)
draft-ji-i2rs-usecases-ccne-service-01
Abstract
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.
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.
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/.
Ji, et al. Expires August 17, 2014 [Page 1]
Internet-Draft I2RS Use Cases for CCNE February 2014
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 August 17, 2014.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Teminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Case of I2RS in Control Forward Path by CCNE . . . . . . 3
3.1. I2RS Use Cases for Control Path by RR . . . . . . . . . . 3
3.1.1. RR Provides Whole Network Views . . . . . . . . . . . 4
3.1.2. Explicit IP Path Configuration on RR . . . . . . . . 5
3.1.3. RR based Traffic Steering . . . . . . . . . . . . . . 5
3.1.4. RR Events . . . . . . . . . . . . . . . . . . . . . . 7
3.2. I2RS Use Case for Control MPLS TE Network Path by PCE . . 7
3.2.1. PCE Server Provides Whole MPLS TE Network Views . . . 7
3.2.2. Global Concurrent Re-optimization . . . . . . . . . . 8
3.2.3. Failure Simulation . . . . . . . . . . . . . . . . . 9
3.3. Requirements for I2RS from the use cases . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Ji, et al. Expires August 17, 2014 [Page 2]
Internet-Draft I2RS Use Cases for CCNE February 2014
1. Introduction
I2RS working group is chartered to define an interface to the routing
system [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.
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.
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.
2. Teminology
RIB: Routing Information Base
I2RS: Interface to Routing System
RR: Route Reflector
PCE: Path Computation Element
Central Controlled Network Element (CCNE):
3. Use Case of I2RS in Control Forward Path by CCNE
3.1. I2RS Use Cases for Control Path by RR
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
Ji, et al. Expires August 17, 2014 [Page 3]
Internet-Draft I2RS Use Cases for CCNE February 2014
reflector server - rather than peer with every other router in a full
mesh. All the other IBGP routers become route reflector clients.
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.
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.
+---------------------+
| 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
3.1.1. RR Provides Whole Network Views
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.
Ji, et al. Expires August 17, 2014 [Page 4]
Internet-Draft I2RS Use Cases for CCNE February 2014
[[I-D.medved-i2rs-topology-im]] defines the information model for
network topologies.
3.1.2. Explicit IP Path Configuration on RR
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.
+-------------------+
| 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)
3.1.3. RR based Traffic Steering
RR based Traffic Steering
([[I-D.chen-idr-rr-based-traffic-steering-usecase] ]) introduces the
requirements and use cases of RRTS.
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
Ji, et al. Expires August 17, 2014 [Page 5]
Internet-Draft I2RS Use Cases for CCNE February 2014
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.
+-------------------+
| APP-I2RS client |
| (CCNE)
+-------------------+
|
[BGP RR API]
|
+------------+ +------------------+
| RR Router |--[Topology API]--| Topology Manager |
+------------+ +------------------+
|
[BGP API]
|
+------------+
| Router |
+------------+
Figure 3: An Architecture for RR
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.
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.
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.
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
Ji, et al. Expires August 17, 2014 [Page 6]
Internet-Draft I2RS Use Cases for CCNE February 2014
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.
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.
3.1.4. RR Events
3.1.4.1. Notification of IP Path Events
With I2RS, it is conceivable that applications could tell the status
of an IP Path.
3.1.4.2. Tracing IP Paths
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.
3.2. I2RS Use Case for Control MPLS TE Network Path by PCE
Path computation in large, multi-domain networks is complex and may
require special computational components and cooperation between the
elements in different domains. PCE [[RFC4655]] is proposed to
address this problem.
With PCE, operator can make more services and traffic to be hold in
the same MPLS TE network, and promote network resource utilization.
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.
3.2.1. PCE Server Provides Whole MPLS TE Network Views
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.
Ji, et al. Expires August 17, 2014 [Page 7]
Internet-Draft I2RS Use Cases for CCNE February 2014
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.
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.
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.
3.2.2. Global Concurrent Re-optimization
The stateful PCE [[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.
+-------------------+
| 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
Ji, et al. Expires August 17, 2014 [Page 8]
Internet-Draft I2RS Use Cases for CCNE February 2014
3.2.2.1. TE Link and TE LSP Constraint Configuration
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.
With I2RS, The interfaces can be extended to conveniently adjust TE
network logical topology.
3.2.2.2. Calculated Path Approve and Disapprove
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.
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.
3.2.3. Failure Simulation
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.
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.
Ji, et al. Expires August 17, 2014 [Page 9]
Internet-Draft I2RS Use Cases for CCNE February 2014
3.3. Requirements for I2RS from the use cases
From the above use case, the requirements for I2RS are:
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.
2. I2RS client should be able to set resource constraints at the
I2RS Agent, and receive status information on the setting of resource
constraints.
3. I2RS interface should be able to set service goal value to CCNE.
4. I2RS client should be able support information models that allow
re-optimization traffic model at at CCNE .
5. I2RS client should be able to receive notification at the CCNE,
and be able to send status to the I2RS agent.
6. I2RS client should work in parallel with traditional network
management or OAM protocols sent to the general NE.
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).
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
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.
6. References
Ji, et al. Expires August 17, 2014 [Page 10]
Internet-Draft I2RS Use Cases for CCNE February 2014
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
6.2. Informative References
[I-D.chen-idr-rr-based-traffic-steering-usecase]
Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of
Route Reflection based Traffic Steering", draft-chen-idr-
rr-based-traffic-steering-usecase-00 (work in progress),
July 2013.
[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-01 (work in
progress), February 2014.
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-07 (work in progress), October 2013.
[I-D.medved-i2rs-topology-im]
Medved, J., Bahadur, N., Clemm, A., and H.
Ananthakrishnan, "An Information Model for Network
Topologies", draft-medved-i2rs-topology-im-01 (work in
progress), October 2013.
Authors' Addresses
Xiaofeng Ji
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jixiaofeng@huawei.com
Ji, et al. Expires August 17, 2014 [Page 11]
Internet-Draft I2RS Use Cases for CCNE February 2014
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Tieying Huang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: huangtieying@huawei.com
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Ji, et al. Expires August 17, 2014 [Page 12]