One document matched: draft-hares-use-case-vn-vc-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY I-D.atlas-irs-problem-statement SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-irs-problem-statement.xml">
<!ENTITY I-D.ward-irs-framework SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ward-irs-framework.xml">
<!ENTITY I-D.atlas-irs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-irs-policy-framework.xml">
<!ENTITY I-D.rfernando-irs-framework-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rfernando-irs-framework-requirement.xml">
<!ENTITY I-D.medved-irs-topology-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.medved-irs-topology-requirements.xml">
<!ENTITY I-D.white-irs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-irs-use-case.xml">
<!ENTITY I-D.keyupate-irs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keyupate-irs-bgp-usecases.xml">
<!ENTITY I-D.amante-irs-topology-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.amante-irs-topology-use-cases.xml">
<!ENTITY I-D.bernstein-alto-large-bandwidth-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-alto-large-bandwidth-cases">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-hares-use-case-vn-vc-00" ipr="trust200902">
<front>
<title abbrev="IRS Use Cases VCoD VNoD">Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand using Interface to Routing System</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<!-- Reorder these if your country does things differently -->
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<email>Susan.Hares@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Mach Chen" initials="M" surname="Chen">
<organization>Huawei</organization>
<address>
<postal>
<street>No. 3 Xinxi Road, Shangdo-di </street>
<!-- Reorder these if your country does things differently -->
<city>Hai-Dan District</city>
<region>Beijing</region>
<code>100085</code>
<country>USA</country>
</postal>
<email>mach@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2012" />
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t> Software Defined Networks (SDN) provide a way to virtualize and abstract the network and
present the virtual or abstract resources to the third-party applications running in software.
The application can utilize a programmable interface
to receiving these virtual or abstract resources in a form that allows monitoring or manipulation of resources.
Various programmatic interfaces have been proposed to interface directly to the forwarding plane (OpenFlow, ForCES),
or do device configuration (NETCONF). ALTO has proposed a informational interface to the application.
Only the progammatic Interface to the Routing System (IRS) provides an interface directly to the routing system
to utilize all aspects of the routing system as a system. </t>
<t> The IRS system interacts with the control plane processes to monitor best paths to any destination and
to change the routing information base (RIB) or MPLS label information Base (LIB)
which feeds the forwarding tables the information needed to actually switch traffic at a local level.</t>
<t>This document outlines how SDN networks can use the IRS
interface to implement an automated set of network services for
Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD) </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t> </t>
<t>The Interface to the Routing System Framework [IRS] desribes a mechanism where the distributed control plane
can be augmented by an outside control plane through an open, accessible interface, including the Routing Information
Base (RIB) and the label interface (LIB) individual devices. IRS provides a "halfway point" between completely
replacing the traditional distributed control planes and directly configure devices via off-board processes. </t>
<t> This draft proposes a set of use cases to use IRS mechanisms to implement a Software Defined Network (SDN)
with virtual connections and virtual networks as automated services. This document focuses on how IRS
would support two automated network services: Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD).
The SDN service provides the basic connection and a guidance ("self-help") functionality. </t>
<t>This paper contains a background section, a use case for IRS in VCoD, and a use case for IRS in VNoD. </t>
<t> SDN is a new adventure for the Internet space. Each new adventure in the Internet space requires lots of use cases so that the IETF may determine the critical protocols. </t>
</section>
<section title="Background" toc="default">
<t> </t>
<t> Applications and network layer flows have run independently since the Internet started in the late 1980s.
Provisioning of network servivces and big flows has been done by service providers statically or with proprietary.
Recently, new server and host technologies have increase application data traffic flows across the network.
With the advent of data center providers and cloud services, applications life cycles have shortened to weeks rather
than years. The need for fast automated provisioning of virtual network connections or quick provisioning of
virtual private networks has increased. </t>
<t> Software Defined Neworks have have three areas of challenge to provide such quick network services:
a) how to control the network flows, b) interfaces to networks, and c) how do calculate where these network flows go. </t>
<t> Network flows can be controlled at the forwarding device level or the network control plane level.
Various progammable interfaces have been proposed to provide control over individual forwarding devices.
OpenFlow, for instance, provides a mechanism to replace the dynamic control plane processes on individual
forwarding devices throughout a network with off box processes that interact with the forwarding tables on each device.
Another example is NETCONF, which provides a fast and flexible mechanism to interact with device configuration and policy.</t>
<t> The tradeoff with the device level approach to control flows has to do with benefits and challenges of having control
systems off-board. The benefit of off-board control systems is that the calculation unit can be centralized.
The challenge of the off-board control system has a technical challenge and a deployment challenge.
The technical challenge is that off-board control systems may encounter time-delays and communication failure.
The deployment issues concerns utilizing new protocols for this communication which may also have issues in deployment.
The promised benefits of off-board devices are reduction in operational costs, improving scaling, control, and visiblity.
OpenFlow, for instance, provides a mechanism to replace the dynamic control plane processes on individual forwarding
devices throughout a network with off box processes that interact with the forwarding tables on each device.
Another example is NETCONF, which provides a fast and flexible mechanism to interact with device configuration and policy. </t>
<t> The Interface to Routing System (IRS) interface
provides an interface to all aspects of the routing system as a system. This interface allows the SDN approach
to utilize the existing control plane software without changing it. The IRS system interacts with the control
plane processes to monitor best paths to any destination and to interact with the routing information base (RIB)
or MPLS label information base (LIB) which feeds the forwarding tables the information needed to actually switch
traffic at a local level.</t>
<!-- <t> The framework for IRS is described in <xref target="I-D.atlas-irs-problem-statement" </xref>
<xref target="I-D.ward-irs-framework" </xref>, and
<xref target="I-D.atlas-irs-policy-framework" </xref>. The other write-ups on use cases include:
<xref target="I-D.white-irs-use-case" </xref>,
<xref target="I-D.keyupate-irs-bgp-usescases" </xref>, and
<xref target="I-D.amante-irs-topology-use-cases"</xref>. Proposed requirements include:
<xref target="I-D.medved-irs-topology-requirements" </xref>, and
<xref target="I-D.rfernando-irs-framework-requirement" </xref>. </t>
<t>Please refer to these documents to get acquainted with the background for this use case. </t> -->
<t>Let us turn to the next challenge, the interface to the applciations.</t>
<t> Many academic efforts (e.g. Internet) have examined the benefits in allowing applications to obtain more
network information when making decisions on how connect webs of interfaces. Recently, the IETF ALTO protocol
has been charted to provide resource information for peer-to-peer applications.
Expansions to ALTO's application interface have been proposed to pass information regarding bandwidth
and network topologies. This ALTO work may apply to some large flow Virtual Connections or Virtual Private
networks need. However, these ALTO use cases do not necessarily consider the on-demand issues or IRS.
This document presents these use cases. </t>
<t>This document describes a set of use cases which describe how automated creation of Virtual Connection on Demand (VCoD)
and Virtual Networks On Demand (VNoD) based in SDN logic can be accomplished by using an
interface to the routing system (IRS). </t>
<t> There are several types of network services that can be considered as network services over which
virtual connections or virtual networks can be created. These network services include: optical, Ethernet (VLAN and SPB),
Internet Protocol (IP), Multiprotocol Label Switching (MPLS). Each of these networks can provide
traffic engineered paths, olicy control (e.g. Access control Lists (ACLs)), security services,
or some form of virtual LAN services (VLAN, VxAN, L2/L3 VPN). The examples in this document
focus on the transport and VPN related services that can be abstracted into Virtual Connection (VC)
and Virtual Network (VN). </t>
<t> These abstract services (VC or VN) are logical services that can be mapped to specific services.
For example, a flow can be mapped to a flow such as OpenFlow might provision through a set of networks.
Or a Flow might be mapped to a TE-LSP. These logical services provide a uniform abstract service model
that allows applications to configure VC or VN services independent of the actual network technology implementing it. </t>
<t> The use cases below leverage the SDN architecture and model and the IRS Frmewaork to implement
Virtual Circuit on Demand (VCoD) and Virtual Network on Demand (VNoD). </t>
<t>Please note that this draft builds on the premise that SDN solutions can augment
rather than replace traditional distributed control planes. Each use case is presented in its own section.</t>
</section>
<section title="Virtual Circuit on Demand" toc="default">
<t> </t>
<t>The Virtual circuit on demand (VCoD) first needs to discover where the IRS commissioners acting as controllers are.
After selecting the IRS commissioner which will control the VCoD circuit, the application sends a requests
to create, delete, modify or query circuits. At this point, the IRS Controller takes these requests and performs
the appropriate operations. The discovery protocol and these communications are outside the IRS protocol and framework. The protocol could be ALTO that informs application which IRS commissioner can support VCoD service.</t>
<t> Once the IRS Commissioner is chartered with the task of setting up virtual circuits, the IRS Commission
will communicate with the IRS Agents in the nodes (routing/switching/optial) to set-up these virtual circuits.
In the example topoology below, IRS Commissioner 1 has received a request to set up a Virtual circuit from edge 1 to edge 2.
The IRS commmissioner works with the IRS Agent1 on node 1, the IRS Agent 2 on node 2, the IRS Agent 3 on node 3,
and the IRS Agent 4 on node 4 to set up the virtual circuit. IRS Commissioner 1 is a VCoD capable IRS commissioner
with logic to aid set-up, monitoring, changing, and decommissioning of this circuit. IRS Agents 1-4 contain
the necessary logic to translate the IRS Commissioner's commands to create the virtual circuit's link on their interface. </t>
<t> The IRS framework defines the portion of this system that goes from the VCoD-capable IRS commissioner to/from the VCoD-capable IRS Agents. The IRS Commissioner can request information from the IRS Agent such as topology or interface statics or available circuits, and influence how the IRS Agents create the circuits. The topology information passed between the IRS commission and Agent would include for this application possible virtual connections to a destination and the available bandwidth on that circuit. The interface statistics exchanged could involve historical or instant statistics on exit point performance, jitter, delay. The available of circuits could involve any time-based availabilty for on-demand future usage. </t>
<t>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 a coordinated responses to routing topology
queries has created problems in quickly obtaining and configuring changes for Virtual Circuits. New algorithms
services in routing/switch such as Fast-Reroute of RSVP or IGPs have aided 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
protools to solve what is considered a point case.</t>
<t> The following things need to be supported for this application:
<list style="symbols">
<t>IRS Agents should provide the ability to read the virtual connection topology database for the technology supported. For optical, these are the optical connections and what node they connect to. For MPLS, this is virtual circuit available, and what nodes they connect to. For IP technologies, this could include the GRE tunnels and what interface it connects to. 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. </t>
<t>IRS Agent should provide the ability to influence the configuration of a virtual circuit in a node. </t>
<t>IRS Agent should provide monitor and provide statistics on the virtual connection
to the IRS Commissioner. The IRS commissioner can then determine if the connection falls below a
quality level the application has requested. If the IRS Commissioner does determine the circuit is below the required
quality, it could create another circuit. The IRS Commission may choose to create the second virtual circuit,
transfer flows, and then break the first circuit. </t>
</list>
</t>
<t>Example Topology for Virtual Circuit on Demand (VCoD).</t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
-------------------------
| Application |
---------------------------
| |
| |
+------------------+< Policy +-------------------+< Policy
|IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP
|VC controller | | VN controller |
+------------------+ +-------------------+
| | |-----------+ | |
| | | | |
+--------+ +--------+ +---------+ +----------+
| IRS | | IRS | | IRS | | IRS |
| Agent-1| |Agent-2 | | Agent-3 | | Agent-4 |
|--------| |--------+ +---------+ +----------+
| node 1 | | node 2 | | node 3 | | node 4 |
+--------+ +--------+ +---------+ +----------+
| | | | | |
edge1 |--------| |------------| |
|----edge2
]]>
</artwork>
</figure>
<t> While the set-up of these virtual circuits is possible with current technoloyg,
the lack of the IRS-like framework makes VCoD network complex. With this support,
VCoD may be able to reduce complexity on the individual nodes. </t>
</section>
<section title="Virtual Network on Demand (VNoD)" toc="default">
<t> </t>
<t>Virtual Networks on Demand (VNoD) are simply extensions to the Virtual Connections on Demand concept.
The IRS Commissioner is tasked to create a Virtual network instead of a single connection.</t>
<t> The example sequence would be that the application discovers IRS Commission-2 who is a VNoD via a protocol outside the IRS framework (e.g. ALTO). The IRS Commissioner-2 works with the IRS AGents 1-4 to set-up a virtual network. This involves the following:
<list style="symbols">
<t> gathering potential topology information (in order to create the network, </t>
<t> set-up the virtual network (via influencing configurations on node), </t>
<t> monitoring changes in topology (in order to potential failovers, </t>
<t> influencing changes to virtual network via configurations, and </t>
<t> removing the virtual network after the demand has epxired. </t>
</list>
</t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="center" alt="" width="" height=""><![CDATA[
--------------------------
| Application |
---------------------------
| |
| |
+------------------+< Policy +-------------------+< Policy
|IRS Commissioner-1|< PCE info |IRS Commissioner-2 |< PCEP
|VC controller | | VN controller |
+------------------+ +-------------------+
| | | |
|----------------------------+ | | |
| +------------------ | |
| | | |
+--------+ +--------+ +---------+ +----------+
| IRS | | IRS | | IRS | | IRS |
| Agent-1| |Agent-2 | | Agent-3 | | Agent-4 |
|--------| |--------+ +---------+ +----------+
| node 1 | | node 2 | | node 3 | | node 4 |
+--------+ +--------+ +---------+ +----------+
| | | | | | | | |
| |--------| |------------| | +------+ |-end-point-3
| | |
end-point-1 |
|----end-point2
]]></artwork>
</figure>
<t></t>
<t> This topology shares some configuration needs with the central membership computation for MPLS VPNs from
(draft-white-irs-use-cases) but the mechanisms are not specific to MPlS VPNS.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document has no security issues as just contains use cases.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&I-D.amante-irs-topology-use-cases;
&I-D.atlas-irs-policy-framework;
&I-D.atlas-irs-problem-statement;
&I-D.bernstein-alto-large-bandwidth-cases;
&I-D.medved-irs-topology-requirements;
&I-D.rfernando-irs-framework-requirement;
&I-D.ward-irs-framework;
&I-D.white-irs-policy-framework;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:11:50 |