| Network Working Group | X. Ji |
| Internet-Draft | S. Zhuang |
| Intended status: Informational | T. Huang |
| Expires: August 18, 2014 | Huawei Technologies |
| S. Hares | |
| Hickory Hill Consulting | |
| February 14, 2014 |
I2RS Use Cases for Control of Forwarding Path by Central Control Network Element (CCNE)
draft-ji-i2rs-usecases-ccne-service-01
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.
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].
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/.
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 18, 2014.
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.
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.
RIB: Routing Information Base
I2RS: Interface to Routing System
RR: Route Reflector
PCE: Path Computation Element
Central Controlled Network Element (CCNE):
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.
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
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.
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)
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 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 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.
With I2RS, it is conceivable that applications could tell the status of an IP Path.
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.
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.
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.
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.
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
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.
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.
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.
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).
This document makes no request of IANA.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4655] | Farrel, A., Vasseur, J.-P. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. |
| [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", Internet-Draft draft-ietf-i2rs-architecture-00, August 2013. |
| [I-D.ietf-pce-stateful-pce] | Crabbe, E., Medved, J., Minei, I. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-07, October 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", Internet-Draft draft-chen-idr-rr-based-traffic-steering-usecase-00, July 2013. |
| [I-D.medved-i2rs-topology-im] | Medved, J., Bahadur, N., Clemm, A. and H. Ananthakrishnan, "An Information Model for Network Topologies", Internet-Draft draft-medved-i2rs-topology-im-01, October 2013. |