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]