One document matched: draft-ji-i2rs-usecases-ccne-service-00.txt
Network Working Group X. Ji
Internet-Draft S. Zhuang
Intended status: Informational T. Huang
Expires: April 24, 2014 Huawei Technologies
October 21, 2013
I2RS Use Cases for Control of Forwarding Path by Central Control Network
Element (CCNE)
draft-ji-i2rs-usecases-ccne-service-00
Abstract
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.
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 April 24, 2014 [Page 1]
Internet-Draft I2RS Use Cases for CCNE October 2013
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 24, 2014.
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. Teminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases of I2RS in Controlling Forwarding Path by CCNE . . 3
3.1. I2RS Use Cases for Controlling 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 Controlling 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 . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The I2RS, as defined in [I-D.ward-i2rs-framework], may be used for
the configuration, manipulation, polling or analyzing protocol data.
Ji, et al. Expires April 24, 2014 [Page 2]
Internet-Draft I2RS Use Cases for CCNE October 2013
The I2RS is not intended to replace any existing configuration
mechanisms. 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 the
protocol.
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
CCNE: Central Control Network Element
RIB: Routing Information Base
I2RS: Interface to Routing System
RR: Route Reflector
PCE: Path Computation Element
3. Use Cases of I2RS in Controlling Forwarding Path by CCNE
3.1. I2RS Use Cases for Controlling 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.
Ji, et al. Expires April 24, 2014 [Page 3]
Internet-Draft I2RS Use Cases for CCNE October 2013
Traditional IP network provides only Best Effort (BE) data
transmission capacity without assuring the 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 case, 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 or 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.
[I-D.medved-i2rs-topology-im] defines the information model for
network topologies.
Ji, et al. Expires April 24, 2014 [Page 4]
Internet-Draft I2RS Use Cases for CCNE October 2013
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 or Controller |
+-------------------+
|
[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.ietf-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
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 April 24, 2014 [Page 5]
Internet-Draft I2RS Use Cases for CCNE October 2013
+-------------------+
| APP or Controller |
+-------------------+
|
[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 April 24, 2014 [Page 6]
Internet-Draft I2RS Use Cases for CCNE October 2013
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 Controlling 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, include PCE and PCC devices, run
IGP and PCEP protocols, then PCE device has a view of the TE topology
and network resources of the whole MPLS TE network.
With I2RS, the centralized I2RS Controller may get the whole MPLS TE
topology and network resources from the PCE devices. 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
needed. 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 controller, and connected with other applications like
resource visualized tools, this will make it easy for operator do
network management and maintenance.
Ji, et al. Expires April 24, 2014 [Page 7]
Internet-Draft I2RS Use Cases for CCNE October 2013
3.2.2. Global Concurrent Re-Optimization
Stateful PCE [I-D.ietf-pce-stateful-pce] specifies a set of
extensions to PCEP to enable stateful control of LSPs via PCEP. 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 or Controller |
+-------------------+
|
[Interface for control mple TE network path]
|
+----------+ +--------+
|PCE Server|--[PCEP]--| PCC |
| Router | | Router |
+----------+ +--------+
|
[PCEP]
|
+--------+
| PCC |
| Router |
+--------+
Figure 4. Control MPLS TE Network by PCE
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.
Ji, et al. Expires April 24, 2014 [Page 8]
Internet-Draft I2RS Use Cases for CCNE October 2013
3.2.2.2. Calculated Path Approve and Disapprove
With interfaces to set TE links' attributes and TE LSPs' constraints,
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 controller can easily promote the network resource
utilization by triggering PCE to do global concurrent re-optimization
if necessary and approve or disapprove with the calculated results.
3.2.3. Failure Simulation
When outages 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 a resource such 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 can easily implement failure simulation by
triggering a global concurrent re-optimization with some shutdown
points.
3.3. Requirements for I2RS
From the above use cases, the requirements for I2RS are:
1. I2RS interface should support CCNE include both RR and PCE or
other. It should be able to read both RR and PCE topology
information in a timely manner.
2. I2RS interface should be able to set resource's constraint value
to CCNE.
3. I2RS interface should be able to set service goal value to CCNE.
4. I2RS interface should be able to re-optimization traffic model by
CCNE.
5. I2RS interface should be able to send event or alarm notification
form CCNE.
6. CCNE should support traditional protocol to communicate with
general NE.
Ji, et al. Expires April 24, 2014 [Page 9]
Internet-Draft I2RS Use Cases for CCNE October 2013
7. CCNE should support I2RS interface for network control. CCNE is
a NE with double role, controller and NE.
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
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[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.atlas-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-atlas-i2rs-
problem-statement-02 (work in progress), August 2013.
[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.ward-i2rs-framework]
Ji, et al. Expires April 24, 2014 [Page 10]
Internet-Draft I2RS Use Cases for CCNE October 2013
Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Framework", draft-ward-i2rs-framework-00
(work in progress), February 2013.
Authors' Addresses
Xiaofeng Ji
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jixiaofeng@huawei.com
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
Ji, et al. Expires April 24, 2014 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 20:22:56 |