Internet DRAFT - draft-ji-i2rs-usecases-ccne-service
draft-ji-i2rs-usecases-ccne-service
Network Working Group X. Ji
Internet-Draft S. Zhuang
Intended status: Informational T. Huang
Expires: January 5, 2015 S. Hares
Huawei Technologies
July 4, 2014
I2RS Use Cases for Control of Forwarding Path by Central Control Network
Element (CCNE)
draft-ji-i2rs-usecases-ccne-service-02
Abstract
As networks 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 cases 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 increase 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 January 5, 2015 [Page 1]
Internet-Draft I2RS Use Cases for CCNE July 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Teminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for I2RS from CCNE use cases . . . . . . . . . . 3
4. Use Case of I2RS in Control Forward Path by CCNE . . . . . . 4
4.1. I2RS Use Cases for Control Path by RR . . . . . . . . . . 4
4.1.1. RR Provides Whole Network Views . . . . . . . . . . . 5
4.1.2. Explicit IP Path Configuration on RR . . . . . . . . 5
4.1.3. RR based Traffic Steering . . . . . . . . . . . . . . 6
4.1.4. RR Events . . . . . . . . . . . . . . . . . . . . . . 8
4.2. I2RS Use Case for Control MPLS TE Network Path by PCE . . 8
4.2.1. PCE Server Provides Whole MPLS TE Network Views . . . 8
4.2.2. Global Concurrent Re-optimization . . . . . . . . . . 9
4.2.3. Failure Simulation . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Ji, et al. Expires January 5, 2015 [Page 2]
Internet-Draft I2RS Use Cases for CCNE July 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
scenarios 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 Routers and PCE Servers,
etc. CCNE is developed from the traditional network element, which
with 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 increase 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. Requirements for I2RS from CCNE use cases
This section list the I2RS requirements derived from these CCNE use
cases. The numbering of the requirements uses CCNE-REQ-nn to provide
a global numbering for all I2RS requirements
The use cases in this document show the following requirements for
I2RS are the following:
Ji, et al. Expires January 5, 2015 [Page 3]
Internet-Draft I2RS Use Cases for CCNE July 2014
CCNE-REQ-01: 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.
CCNE-REQ-02: I2RS client should be able to set resource constraints
at the I2RS Agent, and receive status information on the setting of
resource constraints.
CCNE-REQ-03: I2RS interface should be able to set service goal value
to CCNE.
CCNE-REQ-04: I2RS client should be able support information models
that allow re-optimization traffic model at at CCNE .
CCNE-REQ-05: I2RS client should be able to receive notification at
the CCNE, and be able to send status to the I2RS agent.
CCNE-REQ-06: I2RS client should work in parallel with traditional
network management or OAM protocols sent to the general NE.
CCNE-REQ-07: 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. Use Case of I2RS in Control Forward Path by CCNE
4.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
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.
Ji, et al. Expires January 5, 2015 [Page 4]
Internet-Draft I2RS Use Cases for CCNE July 2014
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, efficient 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
4.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.
[[I-D.medved-i2rs-topology-im]] defines the information model for
network topologies.
4.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.
Ji, et al. Expires January 5, 2015 [Page 5]
Internet-Draft I2RS Use Cases for CCNE July 2014
+-------------------+
| 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)
4.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 production 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.
Ji, et al. Expires January 5, 2015 [Page 6]
Internet-Draft I2RS Use Cases for CCNE July 2014
+-------------------+
| 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
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.
Ji, et al. Expires January 5, 2015 [Page 7]
Internet-Draft I2RS Use Cases for CCNE July 2014
4.1.4. RR Events
4.1.4.1. Notification of IP Path Events
With I2RS, it is conceivable that applications could tell the status
of an IP Path.
4.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.
4.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.
4.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.
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.
Ji, et al. Expires January 5, 2015 [Page 8]
Internet-Draft I2RS Use Cases for CCNE July 2014
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.
4.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
4.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.
Ji, et al. Expires January 5, 2015 [Page 9]
Internet-Draft I2RS Use Cases for CCNE July 2014
4.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.
4.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.
5. IANA Considerations
This document makes no request of IANA.
6. 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.
Ji, et al. Expires January 5, 2015 [Page 10]
Internet-Draft I2RS Use Cases for CCNE July 2014
7. References
7.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.
7.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-04 (work in
progress), June 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 January 5, 2015 [Page 11]
Internet-Draft I2RS Use Cases for CCNE July 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
Huawei Technologies
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Ji, et al. Expires January 5, 2015 [Page 12]
