One document matched: draft-ietf-i2rs-usecase-reqs-summary-02.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 RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5212.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC5623 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5623.xml">
<!ENTITY RFC5693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5693.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-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-sfc-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-problem-statement.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.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.amante-i2rs-topology-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.amante-i2rs-topology-use-cases.xml">
<!ENTITY I-D.bitar-i2rs-service-chaining SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bitar-i2rs-service-chaining.xml">
<!ENTITY I-D.hares-i2rs-use-case-vn-vc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-use-case-vn-vc.xml">
<!ENTITY I-D.chen-i2rs-ts-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chen-i2rs-ts-use-case.xml">
<!ENTITY I-D.zhang-i2rs-mbb-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-i2rs-mbb-usecases.xml">
<!ENTITY I-D.shin-i2rs-usecases-cdni-request-routing SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shin-i2rs-usecases-cdni-request-routing.xml">
<!ENTITY I-D.huang-i2rs-mpls-te-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.huang-i2rs-mpls-te-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.chen-i2rs-mpls-ldp-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chen-i2rs-mpls-ldp-usecases.xml">
<!ENTITY I-D.swhyte-i2rs-data-collection-system SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.swhyte-i2rs-data-collection-system.xml">
<!ENTITY I-D.krishnan-i2rs-large-flow-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.krishnan-i2rs-large-flow-use-case.xml">
<!ENTITY I-D.hares-i2rs-bgp-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-bgp-im.xml">
<!ENTITY I-D.medved-i2rs-topology-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.medved-i2rs-topology-requirements.xml">
<!ENTITY I-D.hares-i2rs-info-model-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-policy.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.hares-i2rs-net-element-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-net-element-im.xml">
<!ENTITY I-D.lapukhov-bgp-routing-large-dc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lapukhov-bgp-routing-large-dc-06.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-ietf-i2rs-usecase-reqs-summary-02" ipr="trust200902">
<front>
<title abbrev="I2RS Use Cases Req">Summary of I2RS Use Case Requirements </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<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 year="2016"/>
<area>Routing</area>
<workgroup>i2rs</workgroup>
<abstract>
<t>The I2RS Working Group (WG) has described a set of use cases that
the I2RS systems could fulfil. This document summarizes these use cases.
It is designed to provide requirements that will aid
the design of the I2RS architecture, Information Models, Data Models,
Security, and protocols. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The <xref target="I-D.ietf-i2rs-architecture "> Architecture for the
Interface to the Routing System</xref> allows for a mechanism where the distributed
control plane can be augmented by an outside control plane through an
open, accessible interface. This document summarizes the
use case requirements for theI2RS client-I2RS Agent exchange found
in the following documents:
<list style="symbols">
<t>Protocol Independent described in <xref target="I-D.white-i2rs-use-case"></xref></t>
<t>BGP described in <xref target="I-D.keyupate-i2rs-bgp-usecases"></xref></t>
<t> IGP protocols as described in [draft-ietf-wu-i2rs-igp-usecases] </t>
<t>Control of Forwarding Path by Central Control Network Element (CCNE)
<xref target="I-D.ji-i2rs-usecases-ccne-service"></xref></t>
<t>Virtual Connections and Virtual Networks described in <xref target="I-D.hares-i2rs-use-case-vn-vc"></xref></t>
<t>Topology use cases <xref target="I-D.amante-i2rs-topology-use-cases"></xref></t>
<t>Topology requirements <xref target="I-D.medved-i2rs-topology-requirements"></xref></t>
<t>Service chaining described in <xref target="I-D.bitar-i2rs-service-chaining"></xref></t>
<t>Traffic Steering described in <xref target="I-D.chen-i2rs-ts-use-case"></xref></t>
<t>MPLS TE Networks described in <xref target="I-D.huang-i2rs-mpls-te-usecases"></xref></t>
<t>MPLS LDP Networks described in <xref target="I-D.chen-i2rs-mpls-ldp-usecases"></xref></t>
<t>Mobile BackHaul Use cases described in <xref target="I-D.zhang-i2rs-mbb-usecases"></xref></t>
<t>Large Flows use case described in <xref target="I-D.krishnan-i2rs-large-flow-use-case"></xref></t>
<t>Large Data Collection Systems Use cases described in <xref target="I-D.swhyte-i2rs-data-collection-system"></xref></t>
<t> CDNI requesting routing <xref target="I-D.shin-i2rs-usecases-cdni-request-routing"></xref></t>
</list>
</t>
<t>Each group of use cases is presented in its own document. Each use case
is labeled with an identifier TTT-REQ-nn where TTT represents
the type of use case. The abbreviations for TTT are:
<list style="symbols">
<t>PI - Protocol Independent</t>
<t>BGP - BGP </t>
<t> IGP - IGP protocols </t>
<t>CCNE - CCNE control of forwarding path </t>
<t>VCoD - Virtual Connections on Demand </t>
<t>VNoD - Virtual Networks on Demand </t>
<t>Topo - Topology Information </t>
<t>VT-TMD - Virtual Topology: Topology Data Model </t>
<t>VT-TDM-IP - Virtual Topology: Topology Data Mode for IP/MPLS </t>
<t>SFC - Service Chaining requirements </t>
<t>TS - Traffic Steering </t>
<t>MPLS-LDP - MLPS Topologies supported by LDP </t>
<t>MPLS-TE - MPLS-TE topologies </t>
<t>MBH - Mobile Back-Haul </t>
<t>L-Flow - Large Flows </t>
<t>L-Data - Large Data Collection </t>
<t>CDNI - CDNI networks </t>
</list>
</t>
<t>
Each use case is also augmented with a notation signifying whether it
is in or out of scope with regard to the current I2RS charter:
<list style="symbols">
<t> IC: In charter </t>
<t> OC: Out of charter </t>
<t> NA: not applicable to I2RS protocol, agent, client or models.
Usually related to specific client-side app requirements. </t>
<t> ??: indicates this item needs additional classification aid
from the WG.</t>
</list>
In some cases a specific draft may be out of charter, but
(sub)components of it's requirement set may be in charter. In
charter. As such, (IC|OC|NA) designations may appear at the draft
level, at the requirement level, or at the sub requirement level.
In instances where designations do not appear at more specific level,
the designation at the parent level should be considered to be
inherited.
</t>
</section>
<section title="Protocol Independent Use Case Requirements" toc="default" >
<t>
This is a summary of the I2RS requirements found in the Protocol Independent Use Cases
described in: <xref target="I-D.white-i2rs-use-case"></xref> (IC):
<list style="symbols">
<t>PI-REQ01 (IC): The ability to monitor the available routes installed in the RIB
of each forwarding device, including near real time notification of
route installation and removal. This information must include the
destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), the metric of the
installed route, and an identifier indicating the installing
process.</t>
<t>PI-REQ02 (IC): The ability to install source and destination based routes in the
local RIB of each forwarding device. This must include the ability
to supply the destination prefix (NLRI), the source prefix (NLRI), a
table identifier (if the forwarding device has multiple forwarding
instances), a route preference, a route metric, a next hop, an
outbound interface, and a route process identifier.</t>
<t>PI-REQ03 (IC): The ability to install a route to a null destination, effectively
filtering traffic to this destination.</t>
<t>PI-REQ04(??): The ability to interact with various policies configured on the
forwarding devices, in order to inform the policies implemented by
the dynamic routing processes. This interaction should be through
existing configuration mechanisms, such as NETCONF, and should be
recorded in the configuration of the local device so operators are
aware of the full policy implemented in the network from the running
configuration.</t>
<t>PI-REQ05 (OC): The ability to interact with traffic flow and other network
traffic level measurement protocols and systems, in order to
determine path performance, top talkers, and other information
required to make an informed path decision based on locally
configured policy.</t>
<t>PI-REQ06 (IC): The ability to install destination based routes in the local RIB
of each forwarding device. This must include the ability to supply
the destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), a route preference, a
route metric, a next hop, an outbound interface, and a route process
identifier.</t>
<t>PI-REQ07 (IC): The ability to read the local RIB of each forwarding device,
including the destination prefix (NLRI), a table identifier (if the
forwarding device has multiple forwarding instances), the metric of
each installed route, a route preference, and an identifier
indicating the installing process.</t>
<t>PI-REQ08 (IC): The ability to read the tables of other local protocol processes
running on the device. This reading action should be supported
through an import/export interface which can present the information
in a consistent manner across all protocol implementations, rather
than using a protocol specific model for each type of available
process.</t>
<t>PI-REQ09 (OC for some protocols): The ability to inject information directly into the local tables
of other protocol processes running on the forwarding device. This
injection should be supported through an import/export interface
which can inject routing information in a consistent manner across
all protocol implementations, rather than using a protocol specific
model for each type of available process.</t>
<t>PI-REQ10 (OC): The ability to interact with policies and configurations on the
forwarding devices using time based processing, either through timed
auto-rollback or some other mechanism. This interaction should be
through existing configuration mechanisms, such as NETCONF, and
should be recorded in the configuration of the local device so
operators are aware of the full policy implemented in the network
from the running configuration.</t>
<t>PI-REQ-11 (IC) The ability to update the Local RIB with varying
levels of checks on the route. These checks can be simply
minimal reception checks (TLVs align corrrectly), all non-referential checks
(do not do leafref, MUST, instance identifiers), do referential checks.
</t>
</list></t>
</section>
<section title="BGP Use Case Requirements" toc="default" >
<t> This is a summary of the requirements listed in <xref target="I-D.keyupate-i2rs-bgp-usecases"></xref> are (IC):
<list style="symbols">
<t>BGP-REQ01 (IC): I2RS client/agent exchange SHOULD support the read, write and quick notification of status of the
BGP peer operational state on each router within a given Autonomous System (AS). This operational status
includes the quick notification of protocol events that proceed a destructive tear-down of BGP session </t>
<t>BGP-REQ02 (IC): I2RS client SHOULD be able to push BGP routes with custom cost communities
to specific I2RS agents on BGP routers for insertion in specific BGP Peer(s)
to aid Traffic engineering of data paths. These routes SHOULD be tracked by
the I2RS Agent as specific BGP routes with customer cost communities.
These routes (will/will not) installed via the RIB-Info. </t>
<t>BGP-REQ03 (IC): I2RS client SHOULD be able to track via read/notifications
all Traffic engineering changes applied via I2RS agents to BGP route processes
in all routers in a network.
</t>
<t>BGP-REQ04 (IC): I2RS Agents SHOULD support identification of routers as BGP ASBRs, PE routers, and IBGP routers. </t>
<t>BGP-REQ05 (IC): I2RS client-agent SHOULD support writing traffic flow specifications
to I2RS Agents that will install them in associated BGP ASBRs and the PE routers.</t>
<t>BGP-REQ06 (IC): I2RS Client SHOULD be able to track flow specifications installed within a IBGP Cloud within
an AS via reads of BGP Flow Specification information in I2RS Agent, or via notifications from I2RS agent </t>
<t>BGP-REQ07 (IC): I2RS client-agent exchange SHOULD support the I2RS client
being able to prioritize and control BGP's announcement of
flow specifications after status information reading BGP ASBR and PE router's capacity.
BGP ASBRs and PE routers functions within a router MAY forward
traffic flow specifications received from EBGP speakers to I2RS agents, so
the I2RS Agent SHOULD be able to send these flow specifications from EBGP sources to
a client in response to a read or notification.</t>
<t>BGP-REQ08 (IC): I2RS Client SHOULD be able to read BGP route filter information from
I2RS Agents associated with legacy BGP routers, and write filter information
via the I2RS agent to be installed in BGP RR. The I2RS Agent SHOULD be able
to install these routes in the BGP RR, and engage a BGP protocol action to
push these routers to ASBR and PE routers.
</t>
<t>BGP-REQ09 (IC): I2RS client(s) SHOULD be able to request the I2RS agent to read BGP routes
with all BGP parameters that influence BGP best path decision, and write
appropriate changes to the BGP Routes to BGP and to the RIB-Info
in order to manipulate BGP routes</t>
<t>BGP-REQ10 (IC): I2RS client SHOULD be able instruct the I2RS agent(s) to notify
the I2RS client when the BGP processes on an associated routing system
observe a route change to a specific set of IP Prefixes and associated prefixes.
Route changes include: 1) prefixes being announced or withdrawn,
2) prefixes being suppressed due to flap damping, or
3) prefixes using an alternate best-path for a given IP Prefix.
The I2RS agent should be able to notify the client via publish or
subscribe mechanism.
</t>
<t>BGP-REQ11 (IC): I2RS client SHOULD be able to read BGP route information from BGP routers
on routes in received but rejected from ADJ-RIB-IN due to policy,
on routes installed in ADJ-RIB-IN, but not selected as best path, and
on route not sent to IBGP peers (due to non-selection). </t>
<t>BGP-REQ12 (IC): I2RS client SHOULD be able to request the I2RS agent to read installed BGP Policies.</t>
<t>BGP-REQ13 (IC): I2RS client SHOULD be able to instruct the I2RS Agent to write BGP Policies into the running
BGP protocols and into the BGP configurations.
</t>
<t> BGP-REQ14 (IC): I2RS client-agent SHOULD be able to read BGP statistics associated with Peer, and
to receive notifications when certain statistics have exceeded limits. An example of one of these
protocol statistics is the max-prefix limit. </t>
<t>BGP-REQ15 (IC): The I2RS client via the I2RS agent MUST have the ability to read the loc-RIB-In BGP table that gets all the routes
that the CE has provided to a PE router.</t>
<t>BGP-REQ16 (IC): The I2RS client via the I2RS agent MUST have the ability to install destination based routes in the local RIB of the PE devices.
This must include the ability to supply the destination prefix (NLRI), a table identifier, a route preference, a route metric,
a next-hop tunnel through which traffic would be carried</t>
<t>BGP-REQ17 (IC): The I2RS client via the I2RS agent SHOULD have the the ability to read the loc-RIB-in BGP table to
discover overlapping routes, and determine which may be safely marked for removal.</t>
<t>BGP-REQ18 (IC): The I2RS client via the I2RS Agent SHOULD have the ability to modify filtering rules and initiate a re-computation of
the local BGP table through those policies to cause specific routes to be marked for removal at the outbound eBGP edge.</t>
</list>
</t>
</section>
<section title="IGP Use Cases" toc="default">
<t> This is a summary of the requirements listed in (ietf-draft-wu-ir2s-igp-usecases-00.txt) (OC):</t>
<t>
<list style="symbols">
<t> IGP-REQ-01 (OC): I2RS Client/Agent SHOULD Be able to read/write the
the unique IGP identification for router within an AS (router-id,
system-id, or others). I2RS agents may notify the I2RS client of
the detection of another router with the same unique ID. </t>
<t> IGP-REQ-02 (OC): I2RS Client SHOULD BE able to aid in IGP
table reduction by actively monitoring IGP tables and by allowing
changes to the IGP configuration in order to partition the IGPS
and place ABRs and ASBRs. The I2RS Client/Agent exchange must allow
for a rapid cycle of querying of IGP topology information and
downloading of a new protocol configuration or updating of
IGP nexthops in RIBs and FIBs to rapidly
switch to new temporary IGP topologies. These alternate
topologies may be calculated by a application attached to the i2rs client
and updated to the i2rs agent, or determined at the i2rs agent.
</t>
<t> IGP-REQ-03 (OC): I2RS protocol and models should support Loop-Free Alternative (LFAs)
<xref target="RFC5286"></xref> deployments in
in pure IP and MPLS/LDP networks to provide single-point-failure protection for unicast
traffic. This includes the configuration, monitoring of LFA changes,
and letting off-line pre-computed paths for LFA backup of all
links and prefixes in the network and calculating the protection
coverage and recognizing optimization to be downloaded to
appropriate devices via the I2RS interface (Client-Agent).
Again, it is important to have deployment of changes followed
by real-time feedback. </t>
<t>IGP-REQ-04 (OC): The I2RS programmatic interface SHOULD allow the balancing of both
ECMP traffic flows and end-to-end traffic flows in the IGP. The I2RS
SHOULD support monitoring of the dynamic traffic flow in the network,
and the query of the maximum capacity of the network. This include
the I2RS client's transmission to the I2RS agent of updated
configuration after an off-line optimization to either spread traffic
(across ECMP pathways) or aggregation of traffic onto a single path so
the rest of the devices may power off saving power (and money.
</t>
<t> IGP-REQ-05 (OC): The I2RS interface (protocol and data models)
SHOULD use the subscription mechanism to filter the topology changes to interested events
and use the publish mechanism to control the pace these events are
notified. This filtering should protect the I2RS Client or even
applications who depend on topology data from being drowned by
massive original events or duplicate events from different sources </t>
<t>IGP-REQ-06 (OC): Since IGP protocol is essential to the whole network, the I2RS
Clients SHOULD monitor about the protocol's running status before
forwarding is impacted. Performance data can be collected through
collecting static configuration and observing dynamic status. Static
data includes the number of instances, interfaces, nodes in the
network and etc. Dynamic data includes adjacency status, the number
of entries in link-state database and in the routing table, the
calculation status, the overload status, the graceful switch-over status,
and others </t>
<t>IGP-REQ-07 (OC): The I2RS interface (protocol and IMs) should support a mechanism where the
I2RS Clients can subscribe to the I2RS Agent's notification of
critical node IGP events. For example, link-state database or routing
table is under the status of overflow or the overflow status is
released, the calculation continues for a long time, the system is
under graceful reboot. </t>
<t> IGP-REQ-08 (OC): The I2RS interface (protocol and IMs) should
support the reporting of IGP statistic such as
dropped packet statistics. These statistics will aid detection
of network failures or secruity attacks. </t>
</list>
</t>
</section>
<section title="CCNE Use Cases" toc="default">
<t>The use cases in I2RS Use Cases for Control of the Forwarding
Path by a Central Control Network Element (CCNE) <xref target="I-D.ji-i2rs-usecases-ccne-service"></xref> indicate the
following requirements for I2RS (OC):
<list style="symbols">
<t>CCNE-REQ-01 (IC): 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. </t>
<t>CCNE-REQ-02 (IC for some constraints): I2RS client should be able to set resource constraints
at the I2RS Agent, and receive status information on the
setting of resource constraints.</t>
<t>CCNE-REQ-03 (IC for some constraints): I2RS interface should be able to set service goal value to
CCNE.</t>
<t>CCNE-REQ-04 (OC): I2RS client should be able support information models
that allow re-optimization traffic model at at CCNE .</t>
<t>CCNE-REQ-05 (IC): I2RS client should be able to receive notification at
the CCNE, and be able to send status to the I2RS agent. </t>
<t>CCNE-REQ-06 (NA): I2RS client should work in parallel with traditional
network management or OAM protocols sent to the general NE.
</t>
<t>CCNE-REQ-07 (NA): 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). </t>
</list>
</t>
</section>
<section title="Topology Related Use Cases" toc="default" >
<t>This section describes Topology or Virtual Topology related
requirements the I2RS interface (protocol and information model (IM)
included in the following types of use cases:
<list style="symbols">
<t> Virtual Connections on Demand: VCoD-REQ </t>
<t> Virtual Networks on Demand: VNoD-REQ </t>
<t> Virtual Topology Information Topo-REQ </t>
<t> Virtual Topology Data Model: VT-TDM-REQ </t>
<t> Virtual Topology IP Data Model: VT-TDMIP-REQ </t>
<t> Virtual Topology Network Element: VT-NE-REQ (TMF-GEN-1) </t>
</list> </t>
<section title="Virtual Connection Use Case Requirements">
<t>
<list style="symbols">
<t>VCoD-REQ01 (OC): 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. </t>
<t>VCoD-REQ02 (OC): I2RS Agent SHOULD provide the ability to influence the configuration of a virtual circuit in a node. </t>
<t>VCoD-REQ03 (OC): 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. </t>
</list>
</t>
</section>
<section title="Virtual Network Use Case Requirements">
<t>
The requirements for the Virtual Networks on Demand (VCoD) are:
<list style="symbols">
<t>VT-VN-REQ01 (IC): I2RS Agents 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. </t>
<t>VNoD-REQ02 (IC): I2RS Agent SHOULD provide the ability to influence the configuration of a virtual circuit in a node. </t>
<t>VNoD-REQ03 (IC): 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. </t>
<t>VNoD-REQ04 (IC): I2RS Agent SHOULD provide the ability to influence the configuration of a virtual network in a node. </t>
<t>VNoD-REQ05 (OC): 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. </t>
<t>VNoD-REQ06 (IC): 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 or CR-LDP). </t>
<t> VNoD-REQ07 (IC): 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. </t>
<t> VNoD-REQ08 (IC): 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. </t>
</list>
</t>
</section>
<section title="Topology Use Case" >
<t> The requirements in <xref target="I-D.amante-i2rs-topology-use-cases"></xref>
topology use cases focus around the architecture of topology manager,
orchestration manager, and policy in the figure below (IC):
<figure>
<artwork>
+---------------+
+----------------+ |
| Applications |-+
+----------------+
^ Websockets, ReST, XMPP...
+------------------------+-------------------------+
| | |
+------------+ +------------------------+ +-------------+
| Policy |<----| Topology Manager |---->|Orchestration|
| Manager | | +--------------------+ | | Manager |
+------------+ | |Topology Information| | +-------------+
| | Model | |
| +--------------------+ |
+------------------------+
^ ^ ^
Websockets, ReST, XMPP # | * Websockets, ReST, XMPP
####################### | ************************
# | *
+------------+ | +------------+
| Statistics | | | Inventory |
| Collection | | | Collection |
+------------+ | +------------+
^ | I2RS, NETCONF, SNMP, ^
| | TL1 ... |
+------------------------+------------------------+
| | |
+---------------+ +---------------+ +---------------+
|Network Element| |Network Element| |Network Element|
| +-----------+ | | +-----------+ | | +-----------+ |
| |Information| |<-LLDP->| |Information| |<-LMP-->| |Information| |
| | Model | | | | Model | | | | Model | |
| +-----------+ | | +-----------+ | | +-----------+ |
+---------------+ +---------------+ +---------------+
</artwork>
</figure>
</t>
<t>
<list style="symbols">
<t> Topo-REQ-01 (IC): The Topology Manager Should be able to collect
topological information via the I2RS Client-Exchange exchange
from a variety of sources in a normalized topological model. These sources can be:
<list style="symbols">
<t> Live Layer IGP IGPs with information about the active topology
such as the LSDB database or IGP updates, </t>
<t> The I2RS must enable the inventory system information to query for
information about network components which are not
not visible to active L3. These systems can be active or
simply invisible to the L3. Examples of this are
L2 Ethernet switches or ROADMS. </t>
<t> Statistic Collection systems that provide traffic
information, such as traffic demands or link utilizations. </t>
</list> (from section 3.2) </t>
<t>Topo-REQ-02 (OC): Topology information is provided from Clients to
high-layer applications via a northbound interface (such as
ReST, Websockts, or XMPP.</t>
<t> Topo-REQ-03 (IC): Topology Manager should be able to collect and
keep current topology information for multiple layers of the
network: Transport, Ethernet and IP/MPLS,
as well as information for multiple Layer 3 IGP areas and multiple
Autonomous Systems (ASes). This information must contain cross-layer
unerlying Shared Risk Link Groups (SRLG) within transport or
Ethernet layers. (from section 3.2)
</t>
<t> Topo-REQ-04 (OC): Topology manager be able to use I2RS Client-Agent protocol to
to collect dynamic inventory information from network elements.
An example of these protocols are the Link Layer discovery protocols
(LLDP, LMP, etc.) which automatically identify remote nodes and ports. (from section 3.2) </t>
<t>Topo-REQ-05 (IC):I2RS Should enable the Policy manager to query and store
the following types of policies:
<list>
<t> Policies that contain Logical identifier Numbering in order
to correlate IP Prefixes to
<list style="symbols">
<t> link based on link type (P-P, P-PE, or PE-CE), </t>
<t> IGP Area </t>
<t> L2 VLAN assignments </t>
</list></t>
<t> Routing Configuration policies that correlate:
<list style="symbols">
<t> OSPF area/ISIS Net-ID to Node (type) </t>
<t> BGP node related policies (aggregation routes at node,
max-prefix (per node), or AFI/SAFI per node </t>
<t> Security policies - with ACLs or rate-limits </t>
<t> Network Component access policies (for management </t>
</list> </t>
</list> (from section 3.3) </t>
<t> Topo-REQ-06 (OC): I2RS should enable a orchestration manager
attached to an I2RS client to communicate with I2RS agents into order to
stitch together End-to-end services for network bandwidth optimization,
load balancing, and Class-of-Service with point services (Firewall or NAT)
within the end-to-end service). The orchestration manager should
also be able to immediately schedule any of these resources via the I2RS-Client
I2RS agent exchange. (from section 3.4) </t>
<t> Topp-REQ-07 (OC): The I2RS exchange should enable a statistics collector to
collect statistics from the routing function of the network nodes and
archive and aggregate the statistics into a statistics warehouse.
Statistics must be given and stored in an normalized form.
Metadata must be stored with the statistics. (from section 4.1.1.2)
(Editor: there is some suggestion of periodic reports) </t>
<t> Topo-REQ-08 (IC): I2RS Client-I2RS agent exchange must be provide
enough interoperability that the Topology manager, Policy manager, and inventory systems
can be available from different vendors </t>
<t>Topo-REQ-09 (IC): TE tunnels must be able to be created by the exchange between
the I2RS client and the I2RS agent. (from section 4.1.1) </t>
<t>Topo-Req-10 (NA): I2RS must provide a common and up-to-date normalized
view of the topologies that that support security
auditing, and IP/MPLS Provisioning (L2/L3) which includes:
<list style="symbols">
<t> Identifying Service PE's in all markets/cities where the customer has
identified they want service, </t>
<t> Identifying one or more existing Servies PE's in each city with
connectivity to the access network(s) ( e.g.: SONET/TDM) used to
deliver the PE-CE tail circuits to the Service's PE), </t>
<t> Obtain via query/notification the available
capacity on Services PE in both the PE-CE access interface
and its uplinks to terminate the tail circuit </t>
<t> Providing the context in I2RS for an iterative query mechanism
needed by I2RS client attached to the the Topology
to narrow down the scope of resources to the set of Services
PEs with the appropriate uplink bandwidth and access circuit
capability plus capacity to realize the requested VPN service. </t>
</list> (from section 4.1.2) </t>
<t> Topo-REQ-11 (NA): The VPN application attached to the I2RS client
should be able to hand the I2RS Client a candidate list of
Service PE's and associated access circuits to set up a
Customer's VPN service into the network. (from section 4.1.3) [Editor's note
This request shares requirements with VCoD-REQ-01.] </t>
<t> Topo-REQ-12 (NA): The Topology Manager associated with the I2RS client
must be able to use the normalized view of the network to set up
additional queries (or notification publications) to provide an
accurate and comprehensive picture in order a) diagnose faults/failures, and
b) augment the network with additional services, and
c) provide network topology maps for different purposes.
(from section 4.1.3) </t>
<t> Topo-REQ-13 (IC):The I2RS client-agent exchange and informational models
should support a Virtual Network Topology (VNT) comprise of one or more LSPS
and lower layer resources. The VNT of MPLS must be able to link lower layer
resources with the higher layer, and present a normalize form the the PCE
as defined <xref target="RFC5623"></xref>.</t>
<t> Topo-REQ-14 (OC): The I2RS client-agent protocol and models should support
the use of a PCE to compute MPLS-TE paths within an "domain" (IGP area), or
across multiple "domains" (multi-area AS, multiple ASes") as specified in
<xref target="RFC4655"></xref>. This means the PCE Informational model should support:
<list style="symbols">
<t> enhanced computation in the single IGP domain </t>
<t> cross-AS path computation based on the multiple
entrance of exit points from an AS, </t>
<t> linking multiple PEs in multiple domains together, and </t>
<t> synchronization of TED associated with the PCE to the
topology manager (via I2RS client/messages), and </t>
<t> sending read/writes to the head-end-nodes </t>
</list>
(section 4.3)
</t>
<t> Topo-REQ-15 (OC): the I2RS protocol and Information models
should support the ALTO (<xref target="RFC5693"></xref>)
generation of abstract network topology models and the APIs
it support over web-service API. The ALTO abstract network topology
comes in two forms: Network Map (based prefix-to PID mapping), and
Cost map. The ALTO map is automatically generated from
BGP and IGP data which the ALTO server queries from the network
and makes available to applications via web-service API. (from section 4.4)
</t>
</list>
</t>
</section>
<section title="Virtual Topology Data Model">
<t>The <xref target="I-D.medved-i2rs-topology-requirements"></xref>
specifies the following Topology Data Model requirements (IC):
<list>
<t> VT-TDM-REQ1 (IC): The topology data model MAY be able to describe topology
and characteristics of the following layers:
<list style="symbols">
<t>Optical DWDM (optional) (OC), </t>
<t>Optical OTN (optional) (OC), </t>
<t>L2 (Aggregated links, L2 topologies) (IC), </t>
<t>IP/MPLS (IC), </t>
<t>VPNs (IC), and </t>
<t>Services (such as cloud services, or CDNs).</t>
</list>
</t>
<t> VT-TDM-REQ2 (IC): The topology data model MUST support multiple Autonomous System deployments.</t>
<t> VT-TDM-REQ3 (IC): The I2RS topology data model must support include topology information from
multiple Administrative Domains or multiple elements into a single common format. </t>
<t> VT-TDM-REQ4 (IC): The I2RS topology data model MUST be able to convey enough information
so that an I2RS client can correlate topologies in different layers and multiple Autonomous Systems.
</t>
<t>VT-TDM-REQ5 (NA): The topology data model MUST support multi-layer group of elements as a means of
coalescing different SFF Nodes and links into a network layers from various layers.
For example, links with IPv4 addresses might represent Layer 3 of the network topology while
links with Ethernet MAC addresses might represent Layer 2.
</t>
<t>VT-TDM-REQ6 (IC): The topology model should allow association between components of different layers.
For example, Layer 2 port may have several IPv4/IPv6 interfaces. The Layer-2 port and the IPv4/IPv6
interfaces would have an association.
</t>
<t>VT-TDM-REQ7 (NA): The topology model MUST represent both inactive and active topologies in the topology
Data base. Inactive topologies may include new line cards, ports in down state, etc. </t>
<t>VT-TMF-DM-REQ8 (NA): The topology data model MUST be hierarchical and MUST support summarization
of sub-topologies. Topology summarization and creation of abstract topologies can be provided
by either by the application associated with the I2RS client, or by the I2RS Agent prior to
transmission to the I2RS client.
</t>
<t>VT-TDM-REQ9 (IC): The topology data model MUST be able to describe abstract topologies.
Abstract topologies can contain real and abstract nodes and real and abstract links.
An abstract topology MAY be used by a provider to describe characteristics of a transit
network (bandwidth, delay, protection, etc.)
</t>
<t> VT-TDM-REQ10 (OC): The topology data model MUST support dynamic data, such as link and node
utilizations (perhaps as optional attributes). </t>
<t> VT-TDM-REQ11a (??): The topology data model MUST allow I2RS client-agent to be able to identify
and query for the path between two nodes. </t>
<t> VT-TDM-REQ11b (OC): The topology data model should support the I2RS Client requesting the I2RS Agent
to trace the path at all network layers that participate in the delivery of packets between two nodes.
This trace MAY involve either an I2RS Agent information trace or the I2RS Agent requesting the routing
function trace the path at multiple levels (L3/L2.5/L2/L1)
</t>
<t> VT-TDM-REQ12 (IC): The topology data model MUST support multiple BGP Autonomous Systems and multiple
IGP areas. Support for multiple administrative domains is for further study. </t>
<t> VT-TDM-REQ13 (IC): The topology data model MUST be human-friendly, i.e. not SNMP MIBs, but something much
more analogous to YANG models. </t>
<t> VT-TDM-REQ14 (IC): The data model SHOULD support topology abstraction, allowing clients that consume
topology information in a constrained manner. For example, a client wishing to view only interfaces
and nodes present in a sub-graph of the Layer 3 topology should be able to specify an interest in this
subset of information rather than having to read out and parse through the entire set of links and nodes.
</t>
</list>
</t>
</section>
<section title="Virtual Topology IP Data Model">
<t>The <xref target="I-D.medved-i2rs-topology-requirements"></xref> specifies the
following requirements for the Virtual Topology IP Data Model's IP/MPLS links and topologies (IC):
<list style="symbols">
<t>VT-TDM-IP-REQ1 (IC): The I2RS topology data model for the IP/MPLS layer MUST
support both link topology and prefixes, </t>
<t>VT-TDM-IP-REQ2 (IC): The I2RS agent may import topology information from the routing processes,
IGP process, BGP-LS information, or management processes. </t>
<t> TM-DM-IP-REQ3 (IC): The I2RS SFC Data model must support links that are IP/MPLS with the
following attributes:
<list style="symbols">
<t> local and Remote anchor node IDs (Router ID, AS#, Area ID, MT topology),</t>
<t> metrics, </t>
<t> admin group, </t>
<t> max bandwidth links </t>
<t> unreserved/utilized bandwidth </t>
<t> link-protection type </t>
<t> MPLS protocol mask </t>
<t> link prefix </t>
<t> link characteristics (BW, Delay, error rate) </t>
<t> Link Description, and </t>
<t> Link-specific timers (Hello and Holddown).</t>
</list>
</t>
</list>
</t>
</section>
<section title="Virtual Topology Network Element">
<t>
The <xref target="I-D.medved-i2rs-topology-requirements"></xref>
specifies the following requirements (IC):
<list style="symbols">
<t>VT-NE-01 (IC): Each network element should contain an inventory data base which should be a
definitive source of information with respect to the physical HW and Logical, logically significant
identifiers (E.g. VLANs). The I2RS client should be able to import data from this DB into the I2RS Node IM or SFC IM.
</t>
<t>VT-NE-02 (IC): The inventory DB of the network element should
be augmented with the physical properties associated with the ports/interfaces that are
directly connected to the device (BW, media type). The I2RS client
should be able to import data from this augmented DB into the
I2RS Node IM or SFC IM. </t>
<t> NE-3 (NA): The I2RS client may write information into the NE inventory
data base via the Network-element Data Model that the network element
may not be able to learn on its own. This information may include the
physical location (address), rack/bay information.</t>
</list>
</t>
</section>
</section>
<section title="Requirements from SFC Use Cases" toc="default" >
<t> The SFC use case document in <xref target="I-D.bitar-i2rs-service-chaining"></xref>
suggests that the following requirements (OC):
<list style="hanging">
<t hangText="SFC-Use-REQ01 (IC):Address" ><vspace blankLines="1" /> has the following address requirements:
<list style="symbols">
<t>IP address </t>
<t> service-node tuple (service node IP address, Host system address)</t>
<t> host-node tuple (hosting system IP-address, system internal identifier)</t>
</list>
</t>
<t hangText="SFC-Use-REQ02 (IC):Supported Service Types"><vspace blankLines="1" /> SHOULD
include: NAT, IP Firewall, Load balancer, DPI, and others</t>
<t hangText="SFC-Use-REQ03 (IC):Virtual contexts"><vspace blankLines="1" /> SHOULD include:
<list style="symbols">
<t> Maximum Number of virtual contexts supported </t>
<t> Current number of virtual contexts in use </t>
<t> Number of virtual contexts available </t>
<t> Supported Context (VRF) </t>
</list></t>
<t hangText="SFC-Use-REQ04 (IC): Customers currently on node"><vspace blankLines="1" /></t>
<t hangText="SFC-Use-REQ05 (IC): Customer Support Table (per customer ID)">
<list style="symbols">
<t>Customer-id </t>
<t> List of supported Virtual Contexts </t>
</list></t>
<t hangText="SFC-Use-REQ06 (OC): Service Resource table"><vspace blankLines="1" /> which includes:
<list style="symbols">
<t> index: Comprised of service node, virtual context, service type </t>
<t> service bandwidth capacity </t>
<t> supported packet rate (packets/second) </t>
<t> supported bandwidth (kps) </t>
<t> IP Forwarding support: specified as routing-instance(s), RIBs, Address-families supported </t>
<t> Maximum RIB-size (WG Note: problematic)</t>
<t> Maximum Forward Data Base size (WG Note: problematic)</t>
<t> Maximum Number of 64 bit statistics counters for policy accounting </t>
<t> Maximum number of supported flows for services (WG Note: problematic) </t>
</list></t>
<t hangText="SFC-Use-REQ07 (IC): Virtual Network Topology (VNT)"><vspace blankLines="1" /> which includes:
<list style="symbols">
<t> number of access points to which service topology applies </t>
<t> topology of access points </t>
</list>
</t>
</list>
</t>
</section>
<section title="Requirements from Traffic Steering Use Cases">
<t>The requirements from the Traffic Steering use case described in <xref target="I-D.chen-i2rs-ts-use-case"></xref>
are (OC):
<list style="symbols">
<t>TS-REQ01 (IC): The I2RS Client-Agent must be able to collect the topology (especially the exit links)
and the traffic load of each link; </t>
<t>TS-REQ02 (IC): The I2RS Client-Agent must be able to read the local rib of each DC/Metro gateway and
the policies deployed on each gateway;</t>
<t>TS-REQ03 (IC): The I2RS Client-Agent must be able to add or delete or modify the relevant rib items and
relevant polices to steer the traffic as expected; and adjust traffic placement. </t>
<t>TS-REQ-04 (IC): The I2RS Client-Agent must have the ability to collect the LSP information either from the PCE
or directly from network devices;</t>
<t>TS-REQ-05 (OC): The I2RS Client-Agent must have the ability to collect the traffic matrix of the network, this
is used to help the I2RS client to determine how to adjust the
traffic placement;</t>
<t>TS-REQ-06 (IC): The I2RS Client-Agent must have the ability to read the rib information and relevant policies
of each network node;</t>
<t>TS-REQ-07 (OC):collect the topology and segment information
needed to help the I2RS client to compute the end-to-end
path;</t>
<t>TS-REQ-08 (OC):read rib (especially the segment routing rib)
information;</t>
<t>TS-REQ-09 (??): add/delete/modify the segment rib, this finally
determines how the traffic is forwarded.</t>
</list> </t>
</section>
<section title="Requirements from MPLS TE Networks Use Cases">
<t>Theses are the requirements from the Traffic Steering use case described
in <xref target="I-D.huang-i2rs-mpls-te-usecases"></xref> (OC):
<list style="symbols">
<t>MPLS-TE-REQ-01 (OC): Network programming software managing the static CR-LSP
devices may incorporate an I2RS Client along with
a path calculation entity, a label management entity, and
a bandwidth management entity. The I2RS Client should be abl to communicate
the static configuration to the network nodes, and monitor the
status of the CR-LSPs. </t>
<t>MPLS-TE-REQ-02 (OC): The I2Client should be able to
synchronously send the configuration for all of the network nodes from
egress node to ingress node via the I2RS Agents attached to each node, and
be able to delay the final ingress node configuration until all the I2RS AGents
on all other nodes toward the egress have denoted a successful path set-up.
</t>
<t>MPLS-TE-REQ-03 (OC): MPLS TE defines abundant constraints such as explicit path,
bandwidth, affinity, SRLG, priority, hop limit, and others. The I2RS Client
Agent exchange should be able to signal concurrent local path calculation could obtain an
optimized result and allow more services to be held in a TE network.
The I2RS Agent should be able to trigger a global concurrent
re-optimization at a specific time on multiple nodes by communicating with
each node's I2RS agent. </t>
<t> MPLS-TE-REQ-04 (NA): The I2RS client should be able to
manually calculate a re-optimization of the the MPLS TE network
and send the new constraints including the calculated path to each node via the I2RS agent
with an indication to re-signal the TE LSPs with make-before-break method. </t>
<t> MPLS-TE-REQ-05 (OC): With I2RS, the node's I2RS agent should be able to
send to an I2RS client a status notification that not enough resources exist
for a back up LSP and TE tunnel. Upon receiving this notification the I2RS client should be
able to trigger concurrent calculation for the failed path calculation of
the backup LSP or TE tunnel and send the updated paths
to I2RS agents with a command to re-signal the TE LSPS with make-before-break
Method.
</t>
<t>MPLS-TE-REQ-06 (NA): With I2RS, upon receipt the failure notification from an I2RS Agent,
the I2RS client would create a global concurrent optimization to handle
the failure event. This would occur by the I2RS client signalling the
I2RS agents on all nodes to: a) trigger a new concurrent calculation of
the backup LSP or TE tunnel via failed path calculation, and
b) re-signal updates to the TE LSPs process with a make-before-break method.
</t>
<t>MPLS-TE-REQ-07 (NA): Upon receiving a signal an upgrade event signal
(from operator), the I2RS client
could calculate another path for the affected TE tunnels to deviate
traffic away from the resource being upgraded, and then
send the request to I2RS agents on the appropriate
nodes to move the traffic. After the upgrade completes, the
I2RS client can simply remove I2RS configurations causing the
traffic to revert to the original path. Or, the I2RS can
re-optimize the TE tunnels for another pathways (E.g.
as a part of a sequence of upgrades). </t>
<t>MPLS-TE-REQ-08 (OC): I2RS agents can notify
I2RS Clients of impending or existing MPLS TE overload conditions
that might cause TE LSP rejections. This overload conditions
include: due to CPU, memory, LSP label space, or LSP numbers.
</t>
<t>MPLS-TE-09 (IC): Automatic bandwidth adjustment applications can also
be linked to the I2RS clients need to monitor the traffic
on TE tunnels in order to provide traffic analysis. The I2RS client
should be able to read the TE Tunnel topology and the bandwidth
analysis in order to automatically calculate
a new path for the TE tunnel if it is needed. The I2RS Client
also needs to be able to the I2RS agents in the nodes to
install the new TE Tunnels with the make-before-break option. </t>
<t>MPLS-TE-REQ-10 (IC): With I2RS, the node failure or link failure can be part of the
notification stream sent by an I2RS Agent to an I2RS Client on
a centralized server gathering information. </t>
<t> MPLS-TE-REQ-11 (IC): The I2RS client can notify the I2RS agents on specific nodes (or devices)
to re-signal TE LSPs one by one if there is a resource dependency. </t>
<t> MPLS-TE-REQ-12 (IC): The I2RS Client can gather the TE LSPs' state from I2RS Agents
on all nodes in order to coordinate such handling of LSP resources.
</t>
<t>MPLS-TE-REQ-13 (OC): The I2RS Clients collecting information from I2RS Agents
can be arranged in a hierarchy to provide scaling of collections.
An application hosting an I2RS client collecting information
from I2RS Agents on nodes can have an I2RS Agent that reports
combined information to a single location.
</t>
</list> </t>
</section>
<section title="Requirements from MPLS LDP Networks Use Cases">
<t>These are the I2RS requirements for the MPLS LDP use case
described in <xref target="I-D.chen-i2rs-mpls-ldp-usecases"></xref>:
<list style="symbols">
<t>MPLS-LDP-REQ-01 (IC): The I2RS Client-agent exchange should allow
the distribution of the configuration for PWE3, MPLS LDP and associated protocols
to be distributed from a central location where the global PWE3
provisioning information could be stored. The I2RS Client-Agent exchange should
also be able to push the configuration of the local LDP
LSR ID and peer addresses to set up the targeted session to the
pseudowire endpoints. </t>
<t> MPLS-LDP-REQ-02 (IC): When an the end-user wants
to disable IPoMPLS (IP over MPLS) application on a L2VPN/PW Targeted
LDP session, the I2RS Client-I2RS agent should be able to set type
of application over the established LDP
session. In this way LDP speaker can only advertise to its peer the
application data which the user is interested in.
</t>
<t>MPLS-LDP-REQ-03 (OC): The I2RS Agent notifications should allow
an I2RS client to subscribe to a stream of state changes
regarding the LDP sessions or LDP LSPs from the I2RS Agent.
Specifically it is important that LDP session is tract for
sessions state coming up or going down.
The I2RS Client-I2RS Agent exchange should allow additional
queries to the AGent to determine a) why the service is invalid, b) calculating whether
an alternate path should be switched to, and c) determining how
to switch to other links or nodes in order to recover from the
link failure or node failure.
</t>
<t> MPLS-LDP-REQ04 (IC): The I2RS interface provides way to monitor and control
the limited resources on these access devices. The I2RS client
should be able to instruct the I2RS agent in each of these devices
to set the maximum number of LDP LSPs in each device prior to enabling
LDP on the devices. The I2RS client should also be able to enable a notification
service on each device with a with a warning threshold.
Once the number of LDP LSPs reaches the threshold,
the I2RS agent will send a notification message to the
I2RS client. Often the I2RS client will be associated a
network management agent that can determine what next steps need to be done based on
policy or operator input. </t>
</list>
</t>
</section>
<section title="Requirements from Mobile Backhaul Ues Cases">
<t>Mobile BackHaul Use cases described in [draft-ietf-zhang-mbb-usecases-01] are:
<list style="symbols">
<t>MBH-REQ-01 (OC): The I2RS client-agent communication can distribute
position-critical changes to IGP nodes using this global knowledge to
quicken changes to support traffic during failures or traffic
overloads. To enable this feature, the I2RS Clients-Agent communication needs
to pass information on which IGP process or Level or Area the given
node and links belong to.</t>
<t> MBH-REQ-02 (OC): I2RS must allow operators to use of I2RS clients to
distribute time-critical changes in configuration to I2RS agents
associated with each routing node. This feature will simplify and
automate configuration and monitoring of a mobile backhaul network to
allow it to readily adapt to changing network sizes (and scales) and
radio applications.</t>
<t>MBB-REQ-03 (OC): I2RS Clients-Agent communication needs to pass
information on:
<list style="symbols">
<t>T-LDP configurations and status;</t>
<t>BGP peer configurations, peer topologies and status;</t>
<t>BGP-based LSP topologies and status;</t>
<t>Reset VPN topologies, and per node configurations;</t>
</list></t>
<t>MBB-REQ04 (IC): Route policy enforcement in mobile backhaul networks
needs to be more dynamic and flexible than the current methods take
hours (or even days) to configure route policy across a network.
The I2RS interface must provide a programmatic way to configure
(both policy and device) and monitor thousands of devices individually
whose configuration is based on the devices role (such as ASRSs in one
AS, ASBRs between ASs and other service-touch nodes).</t>
<t>MBB-REQ-05 (NA): I2RS clients should be able to contact I2RS agents on
nodes to query role-based information from the network status. After
collecting the status, the I2RS client can develop the BGP policies
based on role information and push the BGP policies to the I2RS agents
that would load the alternate policies into the network device. The
I2RS Agents loading the alternate policies could then send status back
to the I2RS Client.</t>
<t>MBH-REQ06 (??): I2RS clients can provide centralized control of many
network devices via the I2RS Client-Agent communication. The I2RS
programmatic interface can automate the collection and analysis of
each device's capability so that the centralized I2RS client could
calculate the optimal LSP path and distribute the configuration to
individual devices. Automation of the collection of device capability
should be available as query, notification, or a published stream.</t>
<t>MBH-REQ07 (NA): While the I2RS RIB Information Model [<xref
target="I-D.ietf-i2rs-rib-info-model"/>] provides for routes with
tunnels or MPLS LSP, the features defined in this model are not
sufficient to configure both types of LSPs needed for the VPN
technology in mobile backhaul networks. Additional I2RS Informational
models need to be created to support these features.</t>
<t>MBH-REQ08 (NA): The hierarchical protection architecture in mobile
backhaul network offer high network reliability and more flexibility
to meet the various needs of the tunnels and services. The I2RS
interface in this use case is needed to automate the configuration and
monitoring so that tunnel protection and service protection interwork
in a flexible and reliable manner.</t>
<t>MBB-REQ09 (OC): The I2RS architecture (client-agent) should allow the
two features for network monitoring naturally in its basic modes:
<list style="symbols">
<t>allow a combination of multi-layer network monitor tools with
exact detection parameters to be configured on the network
device</t>
<t>Facilitate the reporting the detection result as notification
or publication stream</t>
</list>It is important the result of these features allow the
outages and traffic congestion or discards to be detected real-time
with I2RS Client(s) in each node, and the detection result will be
reported to the I2RS agents to get the exact status of the
network.</t>
</list>
</t>
</section>
<section title="Requirements from Large Data Flows are">
<t>Each of these requirements has been given an an ID number of L-Flow-nn for ease of reference. </t>
<t>The requirements from the Large Data Flows use case described in
<xref target="I-D.krishnan-i2rs-large-flow-use-case"></xref> are (IC):
<list>
<t>L-Flow-REQ-01 (IC): For redirecting large flows to a specific component, a PBR
entry should be programmable for the flow with its nexthop that
identifies the specific LAG or ECMP component. </t>
<t> L-Flow-REQ-02 (IC): For adjusting the weights used to distribute traffic across
components of the LAG or ECMP, I2RS should provide a programmable mechanism should
be provided that identifies ECMP entries and is able to
associate weights that can be programmed for each of the
components. To do this in a scalable fashion, it would be
useful to have the notion of an ECMP nexthop that is used by
multiple routes </t>
<t>L-Flow-REQ-03 (IC): The I2RS interface (protocol/IMs) should
allow for a globally optimal path is programmed
in the IP network using hop-by-hop PBR rules. These PBR rules
may include:
<list style="symbols">
<t> Being able to adjust the weights of the ECMP table for
different nexthops should be adjusted to factor the
large flows </t>
<t> Being able to address an ECMP group, so that
all routes sharing an ECMP group are addressed together. </t>
<t>the ability to program PBR entries at the edge LSR, and </t>
<t>the ability to program new LSPs in the network.</t>
</list>
</t>
<t>L-Flow-REQ-04 (OC): The I2RS protocol should be able to invoke the link aggregation
IEEE 802.1AX Marker Protocol via the I2RS protocol. This is useful
during a period of rebalancing occurs before flows are moved. </t>
<t> L-Flow-REQ-05 (IC): The I2rs protocol should allow Quality of Service (QoS) actions such as
rate-limiting, re-marking, or discarding can be performed on the
flows based on configured policies and nexthop redirection actions to
be programmed, and to be programmed independently of of each other.
</t>
<t> L-Flow-REQ-06 (IC): Once a large flow has been detected,
I2RS must be used to modify the forwarding tables in the router
to:
<list style="symbols">
<t> In the case of large flow load balancing, be able to
redirecting the large flow to a particular member with the LAG
or ECMP group and readjusting the weights of the other members
to account for the large flow </t>
<t> In the case of DDoS mitigation, the action involves rate
limiting, remarking or potentially discarding the large flow in
question.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Large Data Collection Systems">
<t>The requirements from the Large Data Collection Systems Use cases described in
[draft-swhyte-i2rs-data-collection-system] are (OC):
<list>
<t>L-Data-REQ-01 (OC): I2rs must be able to collect large data set from
the network with high frequency and resolution
with minimal impact to the device's CPU and memory.</t>
<t>L-Data-REQ-02 (IC): I2RS must be able to use a database model where
the data on the network node must be able to be described
in the I2RS exchange as the data plus the structure of the data.
The I2RS management system consumes and understand the data
only after it consumes and understand the database model or
has been trained by vendor published model</t>
<t>L-Data-REQ-03 (IC): I2RS should use a pub-sub model which
allows scaling plus push or pull of data.</t>
<t>L-Data-REQ-04 (IC): I2RS should support capability negotiation to
inform a subscriber of the options for publication of data.
The options include transport, security, and error handling. </t>
<t>L-Data-REQ-05 (IC): The I2RS data tansfer should be format agnostic.
This means the publisher and subscriber may agree upon XML, JSON, MTL, protobufs
or any other format. </t>
<t> L-Data-REQ-06 (IC): I2RS Transports must be able to be chosen by
a I2RS Client-I2RS Agent pair. An I2RS Client-I2RS Agent pair
should be allowed to negotiate the transport options from a list of options. </t>
<t>L-DATA-REQ-07 (IC): The I2RS interface (protocol and IMs) should
allow a subscribe to select portions of the data model. </t>
<t>L-Data-REQ-08 (IC): The I2RS interface (protocol and IMs) should
allow for multiple publish subscriptions at a time. </t>
<t> L-Data-REQ-09 (IC): Timestaps should be associated with data that
requires it. Not all data will require a time stamp. Additional
time stamps may be added. </t>
<t> L-Data-REQ-10 (IC): The I2RS should support the query and "introspection"
of the data model. The Introspections provides support for data verification,
easier inclusion in legacy data, and easier merging with data streams. </t>
<t>L-Data-REQ-11 (IC): After the I2rs Client-Agent have exchanged
capabilities, a database model, and filters used to select
elements of the model to subscribe to, the
framework should support a standard way to register for all the data
desired, using whatever capabilities were advertised by the node.
Once registration is complete, the control channel can be closed.
Ensuring subscriptions are correct, complete, and replicated or not,
is up to the overall system and not the agent on the network node.</t>
<t>L-Data-REQ-12 (IC): The I2RS interface should support user subscriptions
to data with the following parameters:
<list style="symbols">
<t> push of data synchronously or asynchronously via registered
subscriptions </t>
<t> pull data off in a one-shot pull or in multiple sequences </t>
<t> provide dynamic subscriptions that can be setup via IPFIX feed </t>
<t> support of subscriber and consumer I2RS Client-agent pairs </t>
<t> allow remapping of a node's databases </t>
</list>
</t>
<t>L-Data-REQ-13 (IC): The I2RS interface must handle and report
errors that occur with data subscription, stale data, repeated
transport failures, and other (yet unknown) errors </t>
</list>
</t>
</section>
<section title="CDNI" toc="default">
<t>The requirements from the Content Delivery Network Interaction described in
<xref target="I-D.shin-i2rs-usecases-cdni-request-routing"></xref> are (OC):
<list style="symbols">
<t>CDNI-REQ-01 (OC): The I2RS interface should support two CDNI functionalities [I-D.ietf-cdni-framework]:
<list style="symbols">
<t> Request Routing Interface - Footprint and Capabilities Advertisement;
the asynchronous advertisement of footprint and capabilities by
a dCDN that allows a uCDN to decide whether to redirect particular
user requests to that dCDN via the ALTO protocol; and
</t>
<t> Request Routing Interface - Redirection;
the synchronous operation of actually redirecting a user request
via I2RS manipulation of the routing plane.
</t>
</list>
</t>
<t> CDNI-REQ-02 (OC): The I2RS (Protocol and IM) should provide facilities to
enable the query/response of information from an ALTO services in a node routing functions
so that the upstream CDN provider can select a proper
downstream CDN provider for a given end user request.</t>
<t> CDNI-REQ-03 (OC): I2RS (protocol and IM) should provide facilties to enable
I2RS can help the upstream CDN provider to redirect a content request
message to a downstream CDN provider for a given end user request as
with the following features:
<list style="symbols">
<t> The uCDN relays this message between I2RS Clients and I2RS agents with content
distribution metadata, and queries the dCDN whether user request message can be delivered.
This query can have multiple dDCN that the user message can be delivered to.</t>
<t> the I2RS agent associated with the dCDN delivery requests indicating which dCDN (if any)
the user message can be delivered to. </t>
<t> Allow dCDN to be managed to deliver content by having the messages to
signal back to the uCDN the (destination (?)) iP address for the content,
on the dCDN, and the pathway between the uCDN for surrogate deliver via
the dCDN of user data. Part of this management is the passing of URL of the
surrogate in dCDN (for HTTP Redirection to be transmitting) back from the
dCDN to the uCDN so the uCDN can inform the end user. </t>
</list>
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3746;
</references>
<references title="Informative References">
&RFC4655;
&RFC5212;
&RFC5286;
&RFC5623;
&RFC5693;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-im;
&I-D.ietf-sfc-problem;
&I-D.white-i2rs-use-case;
&I-D.amante-i2rs-topology-use-cases;
&I-D.keyupate-i2rs-bgp-usecases;
&I-D.krishnan-i2rs-large-flow-use-case;
&I-D.bitar-i2rs-service-chaining;
&I-D.hares-i2rs-use-case-vn-vc;
&I-D.chen-i2rs-ts-use-case;
&I-D.chen-i2rs-mpls-ldp-usecases;
&I-D.medved-i2rs-topology-requirements;
&I-D.shin-i2rs-usecases-cdni-request-routing;
&I-D.zhang-i2rs-mbb-usecases;
&I-D.huang-i2rs-mpls-te-usecases;
&I-D.ji-i2rs-usecases-ccne-service;
&I-D.lapukhov-bgp-routing-large-dc;
&I-D.swhyte-i2rs-data-collection-system;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:41 |