Networking Reference
In-Depth Information
• Active topology support via BCA used BGP-TE and OpenFlow to gather active
topology information, although the topology that wasn't normalized. In an all-
MPLS solution, where PCE provisioning in the network to accommodate flows was
used, reservations were maintained within the distributed TED. The TED was up‐
dated through the BGP-TE/LS client whenever an LSP is updated or created. In a
mixed network, the application has to manage the reservations on OpenFlow seg‐
ments.
• The topology could be expanded through the use of OpenFlow configuration sup‐
port and MPLS NETCONF/Yang models, albeit Juniper specific, that turn off/on
MPLS or OpenFlow support in additional elements via a NETCONF plug-in.
The real point of the BCA application was the API that exposed the possibilities of
network programmability . Two examples of the API were demonstrated. The first was
a Guava-based visualization application acting like a traditional OSS-like console that
presented the combined OpenFlow-only or PCE-only topology and the reservations in
the system. The system would allow an application using the programmatic interface
to program reservations as well as interrogate the state of the reservations and network
paths. The second was via a Java applet that embeds the API that emulates a video on
demand application. Other applications could then interact with this API.
In the latter stages of the concept period, this applet was moved from being runnable
on a server that connected to various areas of the test topology to a port that became
an Android app that was demonstrated on an Android tablet. This effectively demon‐
strated both a consumer use of the API and how network operators were moving toward
using iPad and Android applications to manage and interact with their networks.
For this application, because the client is not as capable of handling large topologies,
the ALTO client/server interaction was used to limit the topology that would need to
be digested by the tablet app. In effect, the ALTO server would refine the search for a
path to a best server, which was resolved in a first step ALTO query. This is congruent
with the demands of most applications that would most often not want to view the entire
network topology, but instead, an abstraction or otherwise filtered version. This is dis‐
cussed in more detail in Chapter 8 .
Some of the lessons learned in the exercise were:
• Topology is a fundamental data resource provided from network to application,
and topology from multiple sources is hard to normalize from multiple sources,
especially when representing multiple network layers. This is especially true if those
layers are virtualized or require some sort of abstraction, as is the case when viewing
layer 1 (i.e., optical) topology. These results in fact have allowed us to drive some
of the IETF work in topology.
• Policy appears to be a fundamental application service, as it was embedded in every
application generated.
Search MirCeyron ::




Custom Search