Routing Area Working Group S. Hares Internet-Draft M. Chen Intended status: Informational Huawei Technologies Expires: January 5, 2015 July 4, 2014 Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) using Interface to Routing System draft-hares-i2rs-use-case-vn-vc-03 Abstract Software Defined Networks (SDN) provide a way to virtualize and abstract the network in order to present virtual or abstract resources to third-party applications running in software. Applications can utilize a programmable interface to receive these virtual or abstract resource descriptions in a form that allows monitoring or manipulation of resources within the network. The Interface to the Routing System (I2RS) provides an interface directly to the routing System to monitor best paths to any destination or change routes in the routing information base (RIB) or MPLS Label Information Base (LIB). The I2RS interfaces may be combined with other interfaces to the forwarding plane (ForCES (RFC3746)), device configuration (NETCONF), or mid-level/peer-to-peer (ALTO, draft-ietf- alto-protocol) system to create these virtual pathways. This document outlines how SDN networks can use the I2RS interface to implement an automated set of network services for the Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). These systems provide service routing a better way to create paths within a hub and spoke environment, and provide service routing the ability to create pathways based on service. 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/. 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." Hares & Chen Expires January 5, 2015 [Page 1] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Summary of I2RS requirements . . . . . . . . . . . . . . . . 3 3. Virtual Circuit on Demand . . . . . . . . . . . . . . . . . . 5 3.1. Why I2RS enabled solutions are necessary . . . . . . . . 6 3.2. Why is not in scope for I2RS . . . . . . . . . . . . . . 6 3.3. Example Topology for Virtual Circuit on Demand (VCoD) . . 6 3.4. I2RS Requirements for Virtual Circuit on Demand (VCoD) . 7 4. Virtual Network on Demand (VNoD) . . . . . . . . . . . . . . 8 5. Automated On Demand Networks . . . . . . . . . . . . . . . . 10 6. What is Missing in RIB Informational Model (RIB IM) . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Interface to the Routing System (I2RS) architecture ([I-D.ietf-i2rs-architecture]) describes a mechanism where the distributed control plane can be augmented by an outside control plane through an open accessible programmatic interface. I2RS provides a "halfway point" between completely an architecture that replaces the traditional distributed control planes and directly configuring devices via off-board processes. Hares & Chen Expires January 5, 2015 [Page 2] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 This draft proposes a set of use cases using I2RS mechanisms to implement a Software Defined Network (SDN) to enact virtual connections and virtual networks as automated services. This document focuses on how I2RS would support two automated network services: Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) may be used within hub-spoke networks and improve service routing. In the future, an application enabled SDN service may provide the Virtual Circuits (VCoD) and Virtual Networks on Demand (VNoD) for any type of network service. This document contains a summary of I2RS requirements from VCoD and VNoD use case, background to I2RS, a VCoD use case, a VNoD use case, and a discussion of what the RIB Information Model is missing. Those familiar with I2RS problem statement ([I-D.ietf-i2rs-problem-statement]), I2RS architecture ([I-D.ietf-i2rs-architecture]), and the concepts of Virtual Connections (VCs) or Virtual Networks (VNs) may wish to skip the background section. 1.1. 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]. 2. Summary of I2RS requirements This section contains a summary of what each use case indicates is needed in the I2RS protocol (features and data). Section 3-5 provide descriptions of the Virtual Circuit on Demand (VCoD), Virtual Network on Demand (VNoD), and Automated on Demand Networks. Each of these sections specifies a use case description followed by a summary of I2RS requirements. The use cases in this document have been numbered to allow coherent compilation of the the I2RS requirements into a single list. In this draft, each unique requirement for the I2RS protocol(I2RS client-I2RS agent) for the Virtual Circuit on Demand (VCoD) use caes has the label VCoD-REQnn where nn is an number. Each unique requirement for the VNoD use case has the label VNoD-REQnn where nn is a number. This use case also indicates things which are lacking in the Each unique requirement for for VCoD additions to the I2RS RIB Informational Model VCOD-IM-REQnn (where nn is a unique number). Similarly, each unique requirement for VNoD additions to the RIB informational Model is identified with VNoD-IM-REQnn where nn is a unique number. Section 6 contains a list of what is missing in the RIB Informational Model. Hares & Chen Expires January 5, 2015 [Page 3] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 The requirements for Virtual Connections on Demand (VCoD) use cases are: o VCoD-REQ01: I2RS Agent SHOULD provide the ability to read the virtual network topology database for the technology supported to determine nodes and connections. For optical, these are the optical connections and what node they connect to, and the topologies created. For MPLS, this is virtual circuit available, what nodes they connect to, and the network topologies created. For IP technologies, this could include the GRE tunnels, what interface it connects to, and the topologies created. For Ethernet circuits this should involve circuit type (e.g, point-to- point (P2P) or point-to-multipoint (P2MP)) and what nodes it can reach, and the topologies created. o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the configuration of a virtual circuit in a node. o VCod-REQ03: I2RS Agent SHOULD provide monitor and provide statistics on the virtual connection to the I2RS client via a Read request or status Notification. The I2RS client can then determine if the connection falls below a quality level the application has requested. If the I2RS client does determine the circuit is below the required quality, it could create another circuit. The I2RS may choose to create the second virtual circuit, transfer flows, and then break the first circuit. The Virtual Network on Demand (VCoD) contains the same first three requirements. This means that: o VNoD-REQ01 = VCoD-REQ01, o VNoD-REQ02 = VCoD-REQ02, and o VNoD-REQ03 = VCoD-REQ03. These requirements will not be repeated, so the VNoD begin with VNoD- REQ-04. The requirements for the Virtual Networks on Demand (VNoD) are: o VT-VN-REQ04: I2RS Agent SHOULD provide the ability to influence the configuration of a virtual network in a node. o VT-VN-REQ05: I2RS Agent SHOULD provide the ability to report statistics on the network nodes and end-to-end traffic flows via read of status data or via notifications of status. Hares & Chen Expires January 5, 2015 [Page 4] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 o VT-VN-REQ06: The I2RS protocol and RIB Informational Model (IM) MUST support logical tunnels of type MPLS as well as IP, GRE, VxLAN, and GRE. Large carrier networks utilize MPLS in a variety of forms (LDP, static MPLS TE, or dynamic TE LSPs created by RSVP- TE). o VT-VN-REQ07: I2RS SHOULD support Informational Models and features to allow MPLS technologies to create Hub-spoke topology and service routing in networks in Carriers, Enterprise, and Data Centers. o VT-VN-REQ08: I2RS protocols, Information Models, and Data Models MUST be able to support Carriers using these MPLS technologies to support networks for Mobile BackHaul, on-demand MPLS overlays, and on-demand video conferencing networkings. 3. Virtual Circuit on Demand Virtual Circuit on Demand (VCoD) application associates to I2RS client (or clients) which can communicate with the I2RS agent (or agents) which control the VCoD circuit's creation, deletion, modification, query for information or status changes. Information for this application needs to include for network topology, interface statistics, available circuits per node, available bandwidth on circuits. Interface statistics might be required on a historical and instantaneous time basis. The circuit statistics might also need jitter, delay, and exit-point performance. The virtual circuits may be obtained via RIB Informational Model (RIB IM) ([I-D.ietf-i2rs-rib-info-model]) from the interface list, or from the nexthop lists. Write access to set-up new interfaces is not clearly spelled out in the current version of the RIB IM, nor are the statistics (historical or time). This use case points out additional Information Models (IMs) that need to be added to the I2RS information models. In the example topology below, the VCoD application's I2RS client communicates with I2RS agents to set-up virtual circuits from Edge 1 to Edge 2. The I2RS client communicates with I2RS Agent-1 on node 1, I2RS Agent-2 on node 2, I2RS Agent-3 on node 3, and I2RS Agent 4 on node 4 for to set-up the virtual circuit. The VCoD application contains the necessary logic to determine the pathway from Edge 1 to Edge 2. A second option for VCoD is to have an application communicate with two I2RS clients who cooperate to set-up the virtual connections between Edge 1 and Edge 2. Information passed between the two Hares & Chen Expires January 5, 2015 [Page 5] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 clients can be done via other IETF protocols (E.g. stateful PCE or ALTO). 3.1. Why I2RS enabled solutions are necessary Past solutions in this area have included uses of device configuration across multiple nodes (SNMP or NETCONF based) with proprietary services combined with topology queries. The lack of coordinated responses to routing topology queries has created problems in quickly obtaining and configuring changes for Virtual Circuits. New algorithms can create better services in routing and switching. These algorithms include Fast-Reroute of RSVP or IGPs which aid the automatic re-establishment of some circuits, but the complexity of some of these algorithms increases cost within the network elements. It's often difficult to justify the added complexity in the database and algorithms of routing protocols to solve what is considered a point case. While the set-up of these virtual circuits is possible with current technology, the lack of the I2RS-like framework makes VCoD network complex. With this support, VCoD may be able to reduce complexity on the individual nodes. 3.2. Why is not in scope for I2RS The means by which the VCoD application determines which I2RS client to associate with is outside the I2RS protocol and architecture. A list of virtual circuits per node may be queried from the RIB Informational Model's (RIB IM) ([I-D.ietf-i2rs-rib-info-model]) interface and nexthop lists. However, other means may be used to determine the possible interfaces on a node. For example, ALTO could inform the application which nodes have an I2RS Agent supporting the VCoD service, and SNMP/NETCONF could be used to determine which interfaces were configured. 3.3. Example Topology for Virtual Circuit on Demand (VCoD) Hares & Chen Expires January 5, 2015 [Page 6] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 +----------------------------+ | Application (VCoD) | +---*------------------------+ | | | | +-------*------------++-------------------+< NETCONF |I2RS client 1 |< PCE info> |I2RS Commissioner-2 |< PCEP |VC controller | | VN controller | +--*----------*--*-*-+ +-------------------+ | | | | | | | | | |--------------------------+ | | | |-----------+ | | | | | | | | | +--------+ +--------+ +---------+ +----------+ | I2RS | | I2RS | | I2RS | | I2RS | | Agent-1| |Agent-2 | | Agent-3 | | Agent-4 | |--------| |--------+ +---------+ +----------+ | node 1 | | node 2 | | node 3 | | node 4 | +--------+ +--------+ +---------+ +----------+ | | | | | | edge1 |--------| |------------| | |----edge2 3.4. I2RS Requirements for Virtual Circuit on Demand (VCoD) The following things need to be supported for this application: o VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the virtual network topology database for the technology supported. For optical, these are the optical connections and what node they connect to, and the topologies created. For MPLS, this is virtual circuit available, what nodes they connect to, and the network topologies created. For IP technologies, this could include the GRE tunnels, what interface it connects to, and the topologies created. For Ethernet circuits this should involve circuit type (e.g, point-to-point (p2p) or point-to-multipoint (p2mp)) and what nodes it can reach, and the topologies created. o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the configuration of a virtual circuit in a node. o VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide statistics on the virtual connection to the I2RS client via a Read request or status Notification. The I2RS client can then determine if the connection falls below a quality level the application has requested. If the I2RS client does determine the Hares & Chen Expires January 5, 2015 [Page 7] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 circuit is below the required quality, it could create another circuit. The I2RS may choose to create the second virtual circuit, transfer flows, and then break the first circuit. What is needed in the RIB IM Model o VCoD-RIB_IM-REQ01: The RIB IM model ([I-D.ietf-i2rs-rib-info-model] provides with each route an associated nexthop-list 0-N members. Each nexthop-list is flagged with a protection preference (1 or 2), and a Load balance weight (1 to 99). If the host routes for all nodes in the topology exist within the RIB IM model's instantiation, then the nexthop member on the nexthop-list SHOULD provide the following information: * identifier for interface * egress interface (logical, virtual, or physical) * address of physical interface (IP address or MAC) plus RIB * tunnel encapsulation for interface (IP GRE, MPLS tunnel), * logical tunnel identifier * RIB name (for look-up resolution) * flags for specialized look-ups (Discard packets, discard with error notification, receive) o VT-VC-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include circuit type (p2p, mp2mp), optical connection information, and additional statistics per virtual circuit. o VT-VC_RIB_IM-REQ03:The RIB IM model's instantiation within the protocol must provide an easy way to specify queries for this information. 4. Virtual Network on Demand (VNoD) Virtual Networks on Demand (VNoD) are simply extensions to the Virtual Connections on Demand concept. The I2RS client is tasked to create a virtual network instead of a single connection. The example sequence would be that the application discovers the appropriate I2RS clients (I2RS VNoD client 1 and I2RS VNoD Client 2) which support VNoD via a protocol outside the I2RS framework (e.g. ALTO). The I2RS Client-2 works with the I2RS Agents 1-4 to set-up a virtual network. This involves the following: Hares & Chen Expires January 5, 2015 [Page 8] Internet-Draft I2RS Use Cases VCoD VNoD July 2014 o gathering potential topology information (in order to create the network, o set-up the virtual network (via influencing configurations on node), o monitoring changes in topology (in order to potential failovers, o influencing changes to virtual network via configurations, and o removing the virtual network after the demand has expired. +-------------------------+ | Application | +-------------------------+ | | | | +------------------+< Policy +-------------------+