One document matched: draft-ward-i2rs-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!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 I-D.ietf-pce-stateful-pce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pce-stateful-pce.xml">
<!ENTITY I-D.ietf-isis-genapp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-genapp.xml">
<!ENTITY I-D.gredler-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gredler-idr-ls-distribution.xml">
<!ENTITY RFC3137 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3137.xml">
<!ENTITY RFC5250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5250.xml">
<!ENTITY RFC5470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5470.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC5693 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5693.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY I-D.atlas-irs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-irs-problem-statement.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="5"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ward-i2rs-framework-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="I2RS Framework">Interface to the Routing System
Framework</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." role="editor"
surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Thomas Nadeau" initials="T.N." surname="Nadeau">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>tnadeau@juniper.net</email>
</address>
</author>
<author fullname="Dave Ward" initials="D.W." surname="Ward">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>wardd@cisco.com</email>
</address>
</author>
<date year="2013"/>
<!-- If the month and year are both specified and are the current
ones, xml2rfc will fill in the current day for you. If only the
current year is specified, xml2rfc will fill in the current day
and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if
not specified for the purpose of calculating the expiry date).
With drafts it is normally sufficient to specify just the
year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<!--
<workgroup>Routing Area Working Group</workgroup>
-->
<abstract>
<t>This document describes a framework for a standard, programmatic
interface for full-duplex state transfer in and out of the Internet's
routing system. It provides some basic use-cases, lists the type of
information that might be exchanged over the interface, and describes
suggested functionality for the interface to the Internet routing
system.</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>Routers that form the Internet's routing infrastructure
maintain state at various layers of detail and function. For
example, a typical router maintains a Routing Information Base
(RIB), and implements routing protocols such as OSPF, ISIS, BGP
to exchange protocol state and other information about the state
of the network with other routers.</t>
<t>A router also has information that may be required for
applications to understand the network, verify that programmed
state is installed in the forwarding plane, measure the behavior
of various flows, routes or forwarding entries, as well as
understand the configured and active states of the
router. Furthermore, routers are typically configured with
procedural or policy-based instructions that tell them how to
convert all of this information into the forwarding operations
that are installed in the forwarding plane. It is is also the
active state information that describes the expected and
observed operational behaviour of the router.</t>
<t> This document sets out a framework for a common,
standards-based interface to this information. This Interface to
the Routing System (I2RS) facilitates control and diagnosis of
the route manager's state, as well as enabling network
applications to be built on top of today's routed networks. The
I2RS is a programmatic asynchronous interface for transferring
state into and out of the Internet's routing system, and
recognizes that the routing system and a router's OS provide
useful mechanisms that applications could harness to accomplish
application-level goals.</t>
<t>Fundamental to the I2RS are clear data models that define the
semantics of the information that can be written and read. The
I2RS provides a framework for registering for and requesting the
appropriate information for each particular application. The
I2RS provides a way for applications to customize network
behaviour while leveraging the existing routing system.</t>
<t>The I2RS, and therefore this document, is specifically focused on an
interface for routing and forwarding data.</t>
<section title="Functional Overview">
<t>There are three key aspects to the I2RS. First, the interface is a
programmatic interface meaning that it is asynchronous and offers
fast, interactive access. Second, the I2RS gives access to information
and state that is not usually configurable or modeled in existing
implementations or configuration protocols. Third, the I2RS gives
applications the ability to learn additional, structured, filterable
information and events from the router.</t>
<t>I2RS is described as an asynchronous programmatic interface; the
key properties of which are described in Section 5 of <xref
target="I-D.atlas-irs-problem-statement"/>.</t>
<t>Such an interface facilitates the specification of
implicitly non-permanent state into the routing system, that
can optionally be made permanent. In addition, the extraction
of that information and additional dynamic information from
the routing system is a critical component of the interface. A
non-routing protocol or application could inject state into a
network element's OS via the state-insertion aspects of the
interface and that state could then be distributed in a
routing or signaling protocol.</t>
<t>Where existing mechanisms can provide part of the desired
functionality, the coverage and gaps are briefly discussed in this
document.</t>
<t>The existing mechanisms, such as SNMP and NetConf, that allow state
to be written and read do not meet all of the key properties given in
<xref target="I-D.atlas-irs-problem-statement"/> for I2RS. The
overhead of infrastructure is also quite high and many MIBs do not, in
definition or practice, allow writing of state. There is also very
limited capability to add new application-specific state to be
distributed via the routing system.</t>
<t>ForCES is another method for writing state into a router, but its
focus is on the forwarding plane. By focusing on the forwarding plane,
it requires that the forwarding plane be modeled and programmable and
ignores the existence and intelligence of the router OS and routing
system. ForCES provides a lower-level interface than I2RS is intended
to address.</t>
</section>
<section title="Example Use-Cases">
<t>A few brief examples of ways an application could use the I2RS are
presented here. These are intended to give a sense of what could be
done rather than to be primary and detailed motivational
use-cases.</t>
<t><list style="hanging">
<t hangText="Route Control via Indirection: ">By enabling an
application to install routes in the RIB, it is possible that
when, for example, BGP resolves its IGP next-hop via the RIB, that
could be to an application-installed route. In general, when a
route is redistributed from one protocol to another, this is done
via the RIB and such a route could have been installed via the
I2RS interface.</t>
<t hangText="Policy-Based Routing of Unknown Traffic: ">A static
route, installed into the RIB, could direct otherwise unrecognized
traffic towards an application, through whatever appropriate
tunnel was required, for further handling. Such a static route
could be programmed with indirection, so that its outgoing path is
whatever is used by another particular route (e.g. to a particular
server).</t>
<t hangText="Services with Fixed Hours: ">If an application were
to provide services only during fixed time-periods, the
application could install both a specific route on the local
router in the RIB and advertise the associated prefix as being
attached to the local router via the IGP. If the application knew
the fixed hours, the state so installed could be temporal and
automatically removed at approximately the correct time.</t>
<t hangText="Traffic Mirroring: ">The interface to the multicast
RIB could be used to mirror a particular traffic flow to both its
original destination and a data collector.</t>
<t hangText="Static Multicast Trees: ">An application could set up
static (or partially static) multicast flows via entries in the
multicast RIB without requiring an associated multicast protocol.
This could be useful in networks with a fixed topology and
well-planned distribution tree that provides redundancy.</t>
</list></t>
</section>
</section>
<!-- End of Introduction !-->
<section title="Programmatic Interfaces">
<t>A number of management interfaces exist today that allow for the
indirect programming of the routing system. These include proprietary
CLI, Netconf, and SNMP. However, none of these mechanisms allow for the
direct programming of the routing system. Such asynchronous interfaces
are needed to support dynamic time-based applications.</t>
<t>These interfaces should cater to how applications typically interact
with other applications and network services rather than forcing them to
use older mechanisms that are more complex to understand, implement, as
well as operate. The interfaces should allow applications to have
limited, filtered or abstracted knowledge of the network. Authorization
and authentication are also critical so that the I2RS can be used by a
network application that is not completely controlled by the network
operator but is, nonetheless, given some access to I2RS.</t>
<t>One very critical component of the I2RS is developing standard data
models with their associated semantics. While many routing protocols are
standardized, associated data models for them are not yet available.
Instead, each router uses different information, mechanisms, and CLI
which makes a standard interface for use by applications extremely
cumbersome to develop and maintain. Well-known data modeling languages,
such as YANG <xref target="RFC6020"/>, exist, have some in-progress data
models, and might be used for defining the necessary data models for
I2RS; however, more investigation into alternatives is required. It is
understood that some portion (hopefully a small subset) will remain as
proprietary extensions; the data models must support future extensions
and proprietary extensions.</t>
<t>Since the I2RS will need to support remote access between
applications running on a host or server and routers in the network, at
least one standard mechanism must be identified and defined to provide
the transfer syntax, as defined by a protocol, used to communicate
between the application and the routing system. Common functionality
that I2RS needs to support includes acknowledgements, notifications, and
request-reserve-commit.</t>
<t>Appropriate candidate protocols must be identified that reduce the
effort required by applications and, preferably, are familiar to
application developers. Ideally, this should not require that
applications understand and implement existing routing protocols to
interact with I2RS. These interfaces should instead be based on
light-weight, rapidly deployable approaches; technology approaches must
be evaluated but examples could include ReSTful web services, JSON,
XMPP, and XML. These interfaces should possess self-describing
attributes (e.g. a web services interface) so that applications can
quickly query and learn about the active capabilities of a device.</t>
<t>It may be desirable to also define the local syntax (e.g. programming
language APIs) that applications running local to a router can use.</t>
<t>Since evolution is anticipated in I2RS over time, it is important
that versioning and backwards compatibility are basic supported
functionality. Similarly, common consistent error-handling and
acknowledgement mechanisms are required that do not severely limit the
scalability and responsiveness of these interfaces.</t>
</section>
<section title="Common Interface Considerations">
<section title="Capabilities">
<t>Capability negotiation is a critical requirement because different
implementations and software versions will have different abilities.
Similarly, applications may have different capabilities for receiving
exported information.</t>
<t>An I2RS agent will have offer multiple services, each with their
own set of capabilities. Such capabilities may include the particular
data model and what operations can be performed at what scale.</t>
<t>The capabilities negotiated may be filtered based upon different
information, such as the I2RS client application's authorization, I2RS
client application's capabilities, and the desired granularity for
abstraction which the I2RS client application understands. Different
types of authorization may require the router to advertise different
capabilities and restrictions.</t>
<t>The capability negotiation may take place at different levels of
detail based upon the I2RS client and the specific functions in the
I2RS that the I2RS client is negotiating. The network element and
application must use the I2RS to agree upon the proper level of
abstraction for the interaction. For example, when an application
describes a route between two topological items, these items may vary
in detail from a network domain's name at a high level, or down to the
port forwarding specifics of a particular device.</t>
<t>The data-model and capabilities available for an element may depend
upon whether the element is physical or virtual; the virtual/physical
distinction does not matter to I2RS. Similarly, the location of the
element may influence how an application converses with the associated
network element.</t>
</section>
<section anchor="sec_needs"
title="Identity, Authorization, Authentication, and Security">
<t>The identity of applications that wish to manipulate or interrogate
the state of the routing system must be appropriately authorized.
Role-based authorization and authentication is necessary; however,
there are different existing solutions to this that can be
investigated for use in I2RS.</t>
<t>Being able to associate the state and the modifications to a state
with a specific application would aid in troubleshooting and auditing
of the routing system. By associating identity and authorization with
installed state, other applications with appropriate authority can
clean up state abandoned by failed I2RS client applications, if
necessary.</t>
<t>Security of communication between the application and the router is
also critical and must be considered in the design of the mechanisms
to support these programmatic interfaces.</t>
</section>
<section title="Speed and Frequency of State Installation">
<t>A programmatic interface does not by itself imply the frequency of
state updates nor the speed at which the state installation is
required. These are critical aspects of an interface and govern what
an application can use the interface for. The difference between
sub-second responsiveness to millions of updates and a day delay per
update is, obviously, drastic. The key attributes of the programmatic
interface are described in Section 5 of <xref
target="I-D.atlas-irs-problem-statement"/> and include that the
interface must be asynchronous.</t>
<t>For each service in I2RS, it will be necessary to specify expected
scaling, responsiveness, and performance so that applications can
understand the uses to which the I2RS can be used.</t>
<t>I2RS must support asynchronous real-time interactions between the
I2RS client applications and I2RS agent on the network element. I2RS
must assume that there are many unrelated applications that may be
simultaneously using I2RS. This requirement for multi-headed control
has a number of implications. First, the I2RS agent must do
arbitration between state installed by different I2RS clients. Second,
I2RS clients must be able to subscribe to change events that notify
them about changes done to state by other I2RS clients, configuration,
or dynamic routing.</t>
<t>Furthermore, I2RS should construct services that cater to different
scaling and frequency of update parameters: e.g., slow, but detailed
queries of the system, or fast yet higher level (less detailed)
queries or modifications.</t>
</section>
<section title="Lifetime of I2RS-Installed Routing System State">
<t>In routers today, the lifetime of different routing state depends
upon how that state was learned and committed. If the state is
configuration state, then it is ephemeral when just in the running
configuration or persistent when written to the startup configuration.
If the state is learned via a routing protocol or SNMP, it is
ephemeral, lasting only until the router reboots or the state is
withdrawn.</t>
<t>Unlike previous injection mechanisms that implied the state
lifetime, I2RS requires that multiple models be supported for the
lifetime of state it installs. This is because the lifetime or
persistence of state of the routing system can vary based on the
application that programmed it, policies or security authorization of
the application.</t>
<t>To provide flexibility, pre-programming, and handle dependencies,
it is necessary to have multiple models of when a operation is to be
handled. Similarly, there are multiple models for when an operation is
to expire.</t>
<t>There are three aspects to be considered.</t>
<t><list style="hanging">
<t hangText="Persistence ?: ">Does state installed survive reboot?
<list style="hanging">
<t hangText="Persistent: ">State installed by the I2RS client
remains on the I2RS agent's network element across reboots or
restarts of the system. The installed state can be dynamically
removed or manipulated by an application, by configuration, or
by the routing system itself. This state does not appear in
the router's configuration; it is processed after all the
configuration upon a reboot.</t>
<t hangText="Ephemeral: ">State installed by the I2RS client
remains on the I2RS agent's network element in its active
memory until such time as the installed state is either
removed by a routing or signaling protocol, removed by a
configuration initiated by an application, or the router
reboots. In the case of the latter, past state is forgotten
when the router reboots.</t>
</list></t>
<t hangText="Operation Start-Time: ">There are different models
for when an I2RS agent should start an I2RS operation. <list
style="hanging">
<t hangText="Immediate: ">When the operation is received, it
should be acted upon as quickly as reasonable (e.g. queued
with other outstanding requests if necessary).</t>
<t hangText="Temporal: ">An application may provide an
operation that is to be initiated at a particular time. When
the specified time is reached, the operation should be acted
upon as quickly as reasonable. Implementations may, of course,
strive to improve the time-accuracy at which the operation is
initiated.</t>
<t hangText="Triggered: ">The operation should be initiated
when the specified triggering event has happened. A triggering
event could be the successful or failed completion of another
operation. A triggering event could be a system event, such as
an interface up or down, or another event such as a particular
route changing its next-hops.</t>
</list></t>
<t hangText="State Expiration: ">When state is installed by an
I2RS client, there are two different models to consider for when
that state is to be removed. <list style="hanging">
<t hangText="Temporal: ">When state is installed by an I2RS
client, it has an expiration time specified. When that time
has passed, the I2RS agent removes that state from the network
element. The state can also be dynamically removed or
manipulated by an I2RS client, by configuration or the routing
system itself.</t>
<t hangText="Unbounded: ">When state is installed by an I2RS
client, that state does not explicitly expire. The state can
be dynamically removed or manipulated by an I2RS client, by
configuration, or by the routing system itself.</t>
</list></t>
</list></t>
<t>Because it is possible to request operations in models other than
"Immediate" and some of the start-times will be at an unknown future
point (e.g. "Triggered"), it is not feasible to guarantee that the
resources required by an operation will always be available without
reserving them from the time the operation is received. While that
type of resource reservation should be possible, I2RS clients must
also be able to handle an operation failing or being preempted due to
resources or due to a higher priority or better authorized I2RS client
taking ownership of the associated state or resource.</t>
</section>
</section>
<section title="Bidirectional I2RS Services">
<t>I2RS is a bidirectional programmatic interface that allows both
routing and non-routing applications to install, remove, read, and
otherwise manipulate the state of the routing system.</t>
<t>Just as the Internet routing system is not a single protocol or
implementation layer, neither does it make sense for the I2RS to be at a
single layer or reside within a single protocol. For each protocol or
layer, there are different data models, abstractions and interface
syntaxes and semantics required. However with this in mind, it is ideal
that a minimal set of mechanism(s) to define, transfer and manipulate
this state will be specified with as few optional characteristics as
possible. This will foster better interoperability between different
vendor implementations.</t>
<t>Since I2RS is focused on the routing system, the layers of interest
start with the RIB and continue up through the IGPs, BGP, RSVP-TE, LDP,
etc. The intent is neither to provide I2RS services to the forwarding
plane nor to provide I2RS services to application layers.</t>
<t>It is critical that these I2RS servies provide the ability to learn
state, filtered by request, as well as to install state. I2RS assumes
that there will be multiple applications using I2RS and therefore the
ability to read state is necessary to fully know the network element's
state. In general, if an I2RS service allows the setting of state, the
ability to read and modify that state is also necessary.</t>
<section title="Static Routing">
<t>The ability to specify static routes exists via CLI and MIBs but
these mechanisms do not provide a programmatic interface. I2RS solves
this problem by proposing interfaces to the RIB, LFIB, and Multicast
RIBs.</t>
<t>By installing static routes into the RIB layer, I2RS is able to
utilize the existing router OS and its mechanisms for distributing the
selected routes into the FIB and LIB. This avoids the need to model or
standardize the forwarding plane.</t>
<section title="Routing Information Base Service">
<t>The RIB is populated with routes and next-hops as supplied by
configuration, management, or routing protocols. A route has a
preference based upon the specific source from which the route was
derived. Static routes, specified via CLI, can be installed with an
appropriate preference. The FIB is populated by selecting from the
RIB based on policy and tie-breaking criteria.</t>
<t>The I2RS service should allow dynamic reading and writing of
routes into the RIB. There are several important attributes
associated with doing so, as follows:</t>
<t><list style="hanging">
<t hangText="Preference Value: ">This allows decisions between
conflicting routes, whether I2RS-installed or otherwise.
I2RS-installed routes can each be installed with a different
preference value.</t>
<t hangText="Route Table Context: ">There can be different route
table contexts in the RIB. Examples include multiple protocols
(e.g. IPv4, IPv6), multiple topologies, different uses, and
multiple networks (e.g. VRF tables for VPNs). Appropriate
application-level abstractions are required to describe the
desired route table context.</t>
<t hangText="Route or Traffic Identification">The specific IP
prefix or even interface must be specified.</t>
<t hangText="Outgoing Path and Encapsulation: ">It is necessary
to specify the outgoing path and associated encapsulation. This
may be done directly or indirectly. This is one of the more
complex aspects with the following considerations. <list
style="hanging">
<t hangText="Primary Next-Hops: ">To support multi-path
forwarding, multiple primary next-hops can be specified and
the traffic flows split among them.</t>
<t hangText="Indirection: ">Instead of specifying particular
primary next-hops, it is critical to be able to provide the
ability for indirection, such as is used between BGP routes
and IGP routes. Thus, the outgoing path might be specified
via indirection to be the same as another route's.</t>
<t hangText="Encapsulation: ">Associated with each primary
next-hop can be details on the type of encapsulation for the
packet. Such encapsulation could be MPLS, GRE, etc. as
supported by the router.</t>
<t hangText="Protection: ">For fast-reroute protection, each
primary next-hop may have one or more alternate next-hops
specified. Those are to be used when the primary next-hop
fails.</t>
<t hangText="DSCP: ">For QoS, the desired DSCP to be used
for the outgoing traffic can be specified.</t>
</list></t>
</list></t>
<t>It is useful for an application to be able to read out the RIB
state associated with particular traffic and be able to learn both
the preferred route and its source as well as other candidates with
lower preference.</t>
<t>Although there is no standardized model or specification of a
RIB, it may be possible to build an interoperable bi-directional
service without one.</t>
</section>
<section title="Label Forwarding Information Base Service">
<t>The LFIB has a similar role to the RIB for MPLS labeled packets.
Each entry has slightly different information to accommodate MPLS
forwarding and semantics. Although static MPLS can be used to
configure specific state into the LFIB, there is no bidirectional
programmatic interface to program, modify, or read the associated
state.</t>
<t>Each entry in the LFIB requires a MPLS label context (e.g.
platform, per-interface, or other context), incoming label, label
operation, and next-hops with associated encapsulation, label
operation, and so on. Via the I2RS LFIB service, an application
could supply the information for an entry using either a
pre-allocated MPLS label or a newly allocated MPLS label that is
returned to the application.</t>
</section>
<section title="Multicast Routing Information Base Service">
<t>There is no bidirectional programmatic interface to add, modify,
remove or read state from the multicast RIB. This I2RS service would
add those capabilities.</t>
<t>Multicast forwarding state can be set up by a variety of
protocols. As with the unicast RIB, an application may wish to
install a new route for multicast. The state to add might be the
full multicast route information - including the incoming interface,
the particular multicast traffic (e.g. (source, group) or MPLS
label), and the outgoing interfaces and associated encapsulations to
replicate the traffic too.</t>
<t>The multicast state added need not match to well-known protocol
installed state. For instance, traffic received on an specified set,
or all, interfaces that is destined to a particular prefix from all
sources or a particular prefix could be subject to the specified
replication.</t>
</section>
</section>
<section title="Beyond Destination-based Routing">
<t>Routing decisions and traffic treatment is not merely expressable
via destination-based routing or even (S, G) routing, such as in
multicast. Capturing these aspects into appropriate interfaces for the
I2RS provides the ability for applications to control them as
well.</t>
<section title="Policy-Based Routing Service">
<t>A common feature of routers is the ability to specify
policy-based routing (PBR) rules for accepting, dropping, or
differently forwarding particular traffic. This is a very useful
functionality for an application to be able to rapidly add and
remove state into. Such state would indicate the particular traffic
to be affected and its subsequent behavior (e.g. drop, accept,
forward on specified outgoing path and encapsulation, QoS, DSCP
marking, policing, etc.). Such state is made more complex by the
potential importance of ordering among the PBR rules.</t>
<t>While PBR rules can be specified via CLI, this mechanism is not a
streaming programmatic interface nor is there generally the ability
to specify particular time-based lifetimes for each rule.</t>
</section>
<!--
[Alia 18-July-2012]
Bruno's suggestion is to also discuss stateful services (which look
at the entire stream of traffic for a given flow), such as stateful
firewall, NAT, load balancers, etc. and add APIs. I can see the
utility but am not sure of either how we'd model that generically nor
how to connect it cleanly into routing. We should discuss.
-->
<section title="QoS State">
<t>While per-hop behaviors are defined as well as standard DSCP
meanings, the details of QoS configuration are not standardized and
can be highly variable depending upon platform. It is NOT a goal of
this work to standardize QoS configurations. Instead, a data object
model can define push/pull configurations. More investigation is
needed to better describe the details.</t>
</section>
</section>
<section title="Protocol Interactions">
<t>Providing I2RS interfaces to the various routing protocols allows
applications to specify policy, local topology changes, and
availability to influence the routing protocols in a way that the
detailed addition or modification of routes in the RIB does not.</t>
<t>The decision to distribute the routing state via a routing or
signaling protocol depends upon the protocol-layer at which this state
is injected into the routing system. It may also depend upon which
routing domain or domains this information is injected as well.</t>
<t>In addition it is necessary to have the ability to pull state
regarding various protocols from the router, a mechanism to register
for asynchronous events, and the means to obtain those asynchronous
events. An example of such state might be peer up/down.</t>
<section title="IGP Services">
<t>The lack of a programmatic interface to the IGPs limits the
ability of applications to influence and modify the desired behavior
of the IGP.</t>
<t>An application may need to indicate that a router is overloaded
(via ISIS or the method described in <xref target="RFC3137"/>)
because that router does not yet have sufficient state synchronized
or installed into it. When critical state is provided not merely by
routers but also from applications via the I2RS, a synchronization
mechanism can be needed.</t>
<t>The ability for an application to modify the local topology can
be part of this interface. One possibility is to allow modification
of local interface metrics to generally influence selected routes. A
more extensive interface might include the ability to create a OSPF
or ISIS adjacency across a specified interface (virtual or real)
with the appropriate associated encapsulation.</t>
<t>The ability to attach a prefix to the local router would provide
a straightforward method for an application to program a single
router and have the proper routes computed and installed by all
other routers in the relevant domains. Additional aspects to the
prefix attachment, such as the metric with which to attach the
prefix and fast-reroute characteristics, would be part of the
interface.</t>
<t>Beyond such pure routing information, the need for an application
to be able to install state to be flooded via an IGP has already
been recognized. <xref target="I-D.ietf-isis-genapp"/> specifies a
mechanism for flooding generalized application information via ISIS,
but does not describe how an application can generate or consume
this information. Similarly, <xref target="RFC5250"/> specifies
Opaque LSAs for OSPF to provide for application-specific information
to be flooded. An I2RS service and associated data object model
would provide such a mechanism.</t>
<t>Additional investigation will identify other state that
applications may wish to install.</t>
<t>From the IGP, applications via I2RS can extract significant
topological information about the routers, links, and associated
attributes.</t>
</section>
<section title="BGP Service">
<t>BGP carries significant policy and per-application specific
information as well as internet routes. A significant service to BGP
is expected, with different data object models for different
applications. For example, the I2RS service to BGP could provide the
ability to specify the policy on which paths BGP chooses to
advertise. Additionally, the ability to specify information with an
application-specified AFI/SAFI could provide substantial flexibility
and control.</t>
<t>An existing example of application information carried in BGP is
BGP Flowspec <xref target="RFC5575"/> which can be used to provide
traffic filtering and aid in handling denial-of-service attacks.</t>
<t>The ability to extract information from BGP is also quite
critical. A useful example of this is the information available from
BGP via <xref target="I-D.gredler-idr-ls-distribution"/>, which
allows link-state topology information to be carried in BGP.</t>
</section>
<section title="PIM and mLDP Services">
<t>For PIM and mLDP, there are at least two types of state that an
application might wish to install. First, an application might add
an interface to join a particular multicast group. Second, an
application might provide an upstream route for traffic to be
received from - rather than having PIM or mLDP need to consult the
unicast RIB.</t>
<t>Additional investigation will identify other state that
applications may wish to install.</t>
</section>
</section>
<section title="Triggered Sessions and Signaling">
<section title="OAM-related Sessions Interface">
<t>An application may need to trigger new OAM sessions (e.g. BFD,
VCCP, etc.) using an appropriate template. For example, there may be
applications that need to create a new tunnel, verify its
functionality via new triggered OAM sessions, and then bring it into
service if that OAM indicates successful functionality. More
investigation is needed to better describe the details.</t>
</section>
<section title="Dynamic Session Creation">
<t>An application may wish to trigger a peering relationship for a
protocol. For instance, a targeted LDP session may be required to
exchange state installed locally with a remote router. More
investigation is needed to better describe the different cases and
details.</t>
</section>
<section title="Triggered Signaling">
<t>To easily create dynamic state throughout the network, an
application may need to trigger signaling via protocols such as
RSVP-TE. An example of such an application can be a Stateful Path
Computation Element (PCE)<xref target="I-D.ietf-pce-stateful-pce"/>,
which has control of various LSPs that need to be signaled.</t>
<t>More investigation is needed to better describe the different
cases and details.</t>
</section>
</section>
</section>
<section title="Services for Learned Information from the Routing System">
<t>Just as applications need to inject state into the routing system to
meet various application-specific and policy-based requirements, it is
critical that applications be able to also extract necessary state from
the routing system.</t>
<t>A part of each of these services is the ability to specify the
generation of the desired information (e.g., collecting specific
per-flow measurements) and the ability to specify appropriate filters to
indicate the specifics and abstraction level of the information to be
provided</t>
<t>The types of information to extract can be generally grouped into the
following different categories.</t>
<t><list style="hanging">
<t hangText="Topological: ">The need to understand the network
topology, at a suitable abstraction layer, is critical to
applications. Connectivity is not sufficient - the associated costs,
bandwidths, latencies, etc. are all important aspects of the network
topology that strongly influence the decision-making and behavior of
applications.</t>
<t hangText="Measurements: ">Applications require measurements of
traffic and network behavior in order to have a more meaningful
feedback control loop. Such information may be per-interface,
per-flow, per-firewall rule, per-queue, etc.</t>
<t hangText="Events: ">There are a variety of asynchronous events
that an application may require or use as triggering conditions for
starting other operations. An obvious example is interface state
events.</t>
<t hangText="Configuration: ">For some aspects, it may be necessary
for applications to be able to learn about the routing configuration
on a box. This is partially available via various MIBs and NetConf.
What additional information needs to be exported and the appropriate
mechanisms needs further examination.</t>
</list></t>
<t>The need to extract information from the network is not new; there is
on-going work in the IETF in this area. This framework describes those
efforts in the context of the above categories and starts the discussion
of the aspects still required.</t>
<section title="Efforts to Obtain Topological Data">
<t>Topological data can be defined and presented at different layers
(e.g. Layer-2, Layer-3) and with different characteristics exposed or
hidden (e.g. physical or virtual, SRLGs, bandwidth, latency, etc.). It
can also have different states, such as configured but unavailable,
configurable, active, broken, administratively disabled, etc.</t>
<t>To solve the problem of only being able to obtain topological data
via listening to the IGP in each area, BGP-LS <xref
target="I-D.gredler-idr-ls-distribution"/> defines extensions to BGP
so that link-state topology information can be carried in BGP and a
single BGP listener in the AS can therefore learn and distribute the
entire AS's current link-state topology. BGP-LS solves the problem of
distributing topological information throughout the network. While
I2RS may expand the information to be distributed, I2RS addresses the
API aspect of BGP-LS and not the network-wide distribution.</t>
<t>At another level, ALTO <xref target="RFC5693"/> provides
topological information at a higher abstraction layer, which can be
based upon network policy, and with application-relevant services
located in it. The mechanism for ALTO obtaining the topology can vary
and policy can apply to what is provided or abstracted.</t>
<t>Neither of these fully meet the need to obtain detailed, layered
topological state that provides more information than the current
functional status. While there are currently no sufficiently complete
standards, the need for such functionality can be deduced by the
number of proprietary systems that have been developed to obtain and
manage topology; even Element Management Systems start with the need
for learning and manipulating the topology. Similarly, orchestration
layers for applications start with the need to manage topology and the
associated database.</t>
<t>Detailed topology includes aspects such as physical nodes, physical
links, virtual links, port to interface mapping, etc. The details
should include the operational and administrative state as well as
relevant parameters ranging from link bandwidth to SRLG membership.
Layering is critical to provide the topology at the level of
abstraction where it can be easily used by the application.</t>
<t>A key aspect of this service is the ability to easily rate-limit,
filter and specify the desired information to be extracted. This will
help in allowing the service to scale when queries are done.</t>
</section>
<section title="Measurements">
<t>IPFIX <xref target="RFC5470"/> provides a way to measure and export
per-traffic flow statistics. Applications that need to collect
information about particular flows thus have a clear need to be able
to install state to configure IPFIX to measure and export the relevant
flows to the appropriate collectors.</t>
</section>
<section title="Events">
<t>A programmatic interface for application to subscribe to
asynchronous events is necessary. In addition to the interface state
events already mentioned, an application may wish to subscribe to
certain OAM-triggered events that aren't otherwise exported.</t>
<t>A RIB-based event could be reporting when the next-hops associated
with a route have changed. Other events could be used to verify that
forwarding state has been programmed. For example, an application
could request an event whenever a particular route in the RIB has its
forwarding plane installation completed.</t>
<t>When an application registers for events, the application may
request to get only the first such event, all such events, or all
events until a certain time.</t>
<t>The full set of such events, that are not specifically related to
other services, needs to be investigated and defined.</t>
</section>
</section>
<section title="Manageability Considerations">
<t>Manageability plays a key aspect in I2RS. Some initial examples
include: <list style="hanging">
<t hangText="Data Authorization Levels: ">The data-models used for
I2RS need the ability to indicate the required authorization level
for installing or reading a particular subset of data. This allows
control of what interactions each application can have.</t>
<t hangText="Resource Limitations: ">Using I2RS, applications can
consume resources, whether those be operations in a time-frame,
entries in the RIB, stored operations to be triggered, etc. The
ability to set resource limits based upon authorization is
critical.</t>
<t hangText="Configuration Interactions: ">The interaction of state
installed via the I2RS and via a router's configuration needs to be
clearly defined.</t>
</list></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 framework describes interfaces that clearly require serious
consideration of security. The ability to identify, authenticate and
authorize applications that wish to install state is necessary and
briefly described in <xref target="sec_needs"/>. Security of
communications from the applications is also required.</t>
<t>More specifics on the security requirements requires further
investigation.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ken Gray, Adrian Farrel, Bruno
Rijsman, Rex Fernando, Jan Medved, John Scudder, and Hannes Gredler for
their suggestions and review.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the
citation libraries: 1. define an ENTITY at the top, and use
"ampersand character"RFC2629; here (as shown) 2. simply use a PI
"less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref
elements. If you use the PI option, xml2rfc will, by default,
try to find included files in the same directory as the including
file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These
can be either in the local filing system or remote ones accessed
by http (http://domain/dir/... ).-->
<!--
<references title="Normative References">
</references>
-->
<references title="Informative References">
&RFC3137;
&RFC5250;
&RFC5470;
&RFC5575;
&RFC5693;
&RFC6020;
&I-D.ietf-pce-stateful-pce;
&I-D.ietf-isis-genapp;
&I-D.gredler-idr-ls-distribution;
&I-D.atlas-irs-problem-statement;
</references>
<!-- Change Log
v00 2012-07-11 AKA Initial version
v0i 2012-07-25 AKA Adding in Adrian's and Dave Meyer's comments
v01 2013-02-22 AKA Updating to I2RS, adding ref to problem-statement,
other stuff based on discussions
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 02:47:52 |