One document matched: draft-hares-i2rs-use-case-vn-vc-02.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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 RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.ietf-alto-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-protocol.xml">
<!ENTITY I-D.bernstein-alto-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernstein-alto-topo.xml">
<!ENTITY I-D.keyupate-i2rs-bgp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keyupate-i2rs-bgp-usecases.xml">
<!ENTITY I-D.ji-i2rs-usecases-ccne-service SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ji-i2rs-usecases-ccne-service.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
]>
<?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-i2rs-use-case-vn-vc-02" ipr="trust200902">
<front>
<title abbrev="I2RS Use Cases VCoD VNoD">Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) using Interface to Routing System</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Hickory Hill Consulting</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Mach Chen" initials="M" surname="Chen">
<organization> Huawei Technologies </organization>
<address>
<postal>
<street> Huawei Bld., No.156 Beiqing Rd. </street>
<city> Beijing</city>
<code> 100095 </code>
<country>China </country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<date month="February" year="2014" />
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t>
Software Defined Networks (SDN) provides a way to virtualize and abstract the network and
present the virtual or abstract resources to third-party applications running in software.
Applications can utilize a programmable interface to receive these virtual or abstract resources
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. </t>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t> </t>
<t>The Interface to the Routing System (I2RS) architecture (<xref target="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
replacing the traditional distributed control planes and directly configuring devices via off-board processes. </t>
<t> 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).
The Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) may be used within
hub-spoke networks and improved service routing. In the future, an application enabled
SDN services may provides the Virtual Circuits (VCoD) and Virtual Networks on Demand (VNoD)
for any type of network service. </t>
<t>This document contains a background section, a VCoD use case, a VNoD use case, and notes on future
on-demand network services (connections and network). Those familiar with I2RS problem statement
(<xref target="I-D.ietf-i2rs-problem-statement" />), I2RS architecture (<xref target="I-D.ietf-i2rs-architecture" />),
and the concepts of Virtual Connections (VCs) or Virtual Networks (VNs) may wish to skip directly to the use cases. </t>
<t> SDN is a new to the Internet space. Each new adventure in Internet network services
requires lots of use cases so that the IETF may determine the critical protocols to be developed. </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 services and big flows has been done by service providers statically or with proprietary
processes. 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 Networks 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 programmatic interfaces have been proposed to provide control over individual forwarding devices.
ForCES (<xref target="RFC3746" />) provides mechanisms 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 trade-off 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 both technical challenges and deployment challenges.
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, improved scaling, control, and visibility.
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 (I2RS) 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 I2RS agent 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), and forward the
information to the I2RS client. Applications associated with the I2RS client can compute where
network flows should go, and then instruct I2RS agents in the appropriate nodes to change RIB or LIB
routes to enact the changes to traffic flows.
</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 (I2RS). This document first examines the current use case for I2RS
of improved hub-spoke routing and better service routing using VCoD (section 2), and VNoD (section 3).
Secondly, this document examines the future I2RS use case of VCoD and VNoD for any network
enabled by application or SDN processing.
</t>
<t> A bit of context on abstract services may be useful as a background. </t>
<t> These abstract services (VC or VN) are logical services that can be mapped to specific services.
For example, a virtual circuit may 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> 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), Multi-protocol Label Switching (MPLS). Each of these networks can provide
traffic engineered paths, policy control (e.g. Access control Lists (ACLs)), security services,
or some form of virtual LAN services (VLAN, VxLAN, 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> The use cases below leverage the SDN architecture and model and the I2RS Framework 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) applications 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. This information needs to include for
this application 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. </t>
<t>
The virtual circuits may be obtained via RIB Informational Model (RIB IM)
(<xref target="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. </t>
<t> 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. </t>
<t>
A second option 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 clients can be done via
other IETF protocols (E.g. stateful PCE or ALTO).
</t>
<t> Why I2RS enabled solutions are necessary </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 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.</t>
<t> 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. </t>
<t> What's not in scope for I2RS </t>
<t> 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)
(<xref target="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.
</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 (VCoD) |
+---*------------------------+
| |
| |
+-------*------------+< NETCONF >+-------------------+< 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
]]>
</artwork>
</figure>
<t> The following things need to be supported for this application:
<list style="symbols">
<t>I2RS 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>I2RS Agent should provide the ability to influence the configuration of a virtual circuit in a node. </t>
<t>I2RS Agent should provide monitor and provide statistics on the virtual connection
to the I2RS client. 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. </t>
</list> </t>
<t> What is needed in the RIB IM Model </t>
<t> The RIB IM model (<xref target="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 provides the following information:</t>
<t><list style="symbols">
<t> identifier for interface </t>
<t> egress interface (logical, virtual, or physical) </t>
<t> address of physical interface (IP address or MAC) plus RIB </t>
<t> tunnel encapsulation for interface (IP GRE, MPLS tunnel), </t>
<t> logical tunnel identifier </t>
<t> RIB name (for resolved look-ups) </t>
<t> flags for specialized look-ups (Discard packets, discard with error notification, receive) </t>
</list></t>
<t>The RIB IM model's primitives need to be expanded to include circuit type (p2p, mp2mp),
optical connection information, and additional statistics per virtual circuit.
The RIB IM model's instantiation within the protocol must provide an easy way to specify
queries for this information. </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 I2RS client 2 is tasked to create a Virtual network instead of a single connection.</t>
<t> 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:
<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 expired. </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
|I2RS VNoD client 1|< PCE info |I2RS client 2 |< PCEP
| | | |
+------------------+ +-------------------+
| | | |
|----------------------------+ | | |
| +------------------ | |
| | | |
+--------+ +--------+ +---------+ +----------+
| I2RS | | I2RS | | I2RS | | I2RS |
| 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-i2rs-use-cases) but the mechanisms are not specific to MPLS VPNS.
</t>
</section>
<section title="Automated On Demand Networks" toc="default">
<t> Automated On-Demand networks becomes a reasonable technology within a network
by utilizing the I2RS architecture. While automated
on-demand circuit provisioning and de-provisioning is possible now,
the effort to configure and reconfigure nodes to provide the
Automatic On-Demand circuits can be difficult. With I2RS,
the I2RS client can instruct the I2RS Agents within a network
to create On-Demand circuits and then remove the circuits returning the network to its configured state.
With I2RS enhanced monitoring capability, the monitoring needed
for these state changes is incorporated within the I2RS framework. </t>
<t> The current scope for these Automated On-Demand Circuits
in the IETF's I2RS working group's charter is limited to
hub-spoke networks and service routing. This section discusses
the progress on the I2RS against the use cases, and proposes
additional additional Automated On-Demand Circuits.
</t>
<t> Current Status of the Automated On-Demand Functionality </t>
<t> Both the hub-spoke network and service network may include a
centralized control network element such as
<xref target="I-D.ji-i2rs-usecases-ccne-service" />. These
centralized control network elements may use I2RS access to
individual node's RIB information via the I2RS RIB
Information Model (IM) (<xref target="I-D.ietf-i2rs-rib-info-model" />),
or obtain full network topology information from other protocols
(BGP Route Reflector, PCE (<xref target="RFC4655" />),
or ALTO <xref target="I-D.bernstein-alto-topo" />).
With the recent inclusion of ISIS link-state information into BGP TLVs
via <xref target="I-D.ietf-idr-ls-distribution" />,
all of these sources can provide centralized service can provide
topology maps at the AS and IGP level. </t>
<t> I2RS Information Models (IM) are being proposed which can store:
<list style="symbols">
<t> Network Topologies (IM) <xref target="I.D-medved-i2rs-topology-im" />, and </t>
<t> Service Topologies IM) <xref target="I-D.wu-i2rs-IM-service-topo" />. </t>
</list></t>
<t>Needed Future On-Demand Networks </t>
<t>Large Carrier networks utilize MPLS in a variety of forms
(LDP, static MPLS TE, or dynamic TE LSPS created
by RSVP-TE or CR-LDP). These MPLS technologies can be used to create
Hub-spoke topology and service routing in networks in Carriers,
Enterprise, and Data Centers. The RIB IM supports logical tunnels
of type MPLS as well as IP, GRE, VxLAN and GRE. </t>
<t> Carriers using these MPLS technologies
also use these MPLS and IP networks to support networks for Mobile BackHaul,
on-demand MPLS overlays, and on-demand video conferencing networkings.
</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 it just contains use cases.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC3746;
&RFC4655;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-idr-ls-distribution;
&I-D.ietf-alto-protocol;
&I-D.bernstein-alto-topo;
&I-D.ji-i2rs-usecases-ccne-service;
&I-D.keyupate-i2rs-bgp-usecases;
&I-D.white-i2rs-use-case;
<reference anchor="I-D.wu-i2rs-IM-service-topo">
<front>
<title>An Information Model for Network Topologies</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization/>
</author>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization/>
</author>
<author fullname="Xiaoran Guan" initials="X." surname="Guan">
<organization/>
</author>
<date month="October" year="2003"/>
</front>
<seriesInfo name="ID" value="draft-medved-i2rs-topology-im-01"/>
</reference>
<reference anchor="I.D-medved-i2rs-topology-im">
<front>
<title>An Information Model for Network Topologies</title>
<author fullname="J.Medved" initials="J." surname="Medved">
<organization/>
</author>
<author fullname="N.Bahadur" initials="N." surname="Bahadur">
<organization/>
</author>
<author fullname="A.Clemm" initials="A." surname="Clemm">
<organization/>
</author>
<author fullname="H. Ananthakrishnan" initials="H."
surname="Ananthakrishnan">
<organization/>
</author>
<date month="October" year="2003"/>
</front>
<seriesInfo name="ID" value="draft-medved-i2rs-topology-im-01"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:11:52 |