4. Survivability and Redundancy within the ABNO Architecture
The ABNO architecture described in this document is presented in
terms of functional units. Each unit could be implemented separately
or bundled with other units into single programs or products.
Furthermore, each implemented unit or bundle could be deployed on a
separate device (for example, a network server) or on a separate
virtual machine (for example, in a data center), or groups of
programs could be deployed on the same processor. From the point of
view of the architectural model, these implementation and deployment
choices are entirely unimportant.
Similarly, the realization of a functional component of the ABNO
architecture could be supported by more than one instance of an
implementation, or by different instances of different
implementations that provide the same or similar function. For
example, the PCE component might have multiple instantiations for
sharing the processing load of a large number of computation
requests, and different instances might have different algorithmic
capabilities so that one instance might serve parallel computation
requests for disjoint paths, while another instance might have the
capability to compute optimal point-to-multipoint paths.
This ability to have multiple instances of ABNO components also
enables resiliency within the model, since in the event of the
failure of one instance of one component (because of software
failure, hardware failure, or connectivity problems) other instances
can take over. In some circumstances, synchronization between
instances of components may be needed in order to facilitate seamless
How these features are achieved in an ABNO implementation or
deployment is outside the scope of this document.
5. Security Considerations
The ABNO architecture describes a network system, and security must
play an important part.
The first consideration is that the external protocols (those shown
as entering or leaving the big box in Figure 1) must be appropriately
secured. This security will include authentication and authorization
to control access to the different functions that the ABNO system can
perform, to enable different policies based on identity, and to
manage the control of the network devices.
Secondly, the internal protocols that are used between ABNO
components must also have appropriate security, particularly when the
components are implemented on separate network nodes.
Considering that the ABNO system contains a lot of data about the
network, the services carried by the network, and the services
delivered to customers, access to information held in the system must
be carefully managed. Since such access will be largely through the
external protocols, the policy-based controls enabled by
authentication will be powerful. But it should also be noted that
any data sent from the databases in the ABNO system can reveal
details of the network and should, therefore, be considered as a
candidate for encryption. Furthermore, since ABNO components can
access the information stored in the database, care is required to
ensure that all such components are genuine and to consider
encrypting data that flows between components when they are
implemented at remote nodes.
The conclusion is that all protocols used to realize the ABNO
architecture should have rich security features.
6. Manageability Considerations
The whole of the ABNO architecture is essentially about managing the
network. In this respect, there is very little extra to say. ABNO
provides a mechanism to gather and collate information about the
network, reporting it to management applications, storing it for
future inspection, and triggering actions according to configured
The ABNO system will, itself, need monitoring and management. This
can be seen as falling into several categories:
- Management of external protocols
- Management of internal protocols
- Management and monitoring of ABNO components
- Configuration of policy to be applied across the ABNO system
7. Informative References
[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", Work in Progress, draft-ietf-idr-
ls-distribution-10, January 2015.
[CSO-PCE] Dhody, D., Lee, Y., Contreras, LM., Gonzalez de Dios, O.,
and N. Ciulli, "Cross Stratum Optimization enabled Path
Computation", Work in Progress, draft-dhody-pce-cso-
enabled-path-computation-07, January 2015.
[EON] Gerstel, O., Jinno, M., Lord, A., and S.J.B. Yoo, "Elastic
optical networking: a new dawn for the optical layer?",
IEEE Communications Magazine, Volume 50, Issue 2,
ISSN 0163-6804, February 2012.
[Flood] Project Floodlight, "Floodlight REST API",
[G.694.1] ITU-T Recommendation G.694.1, "Spectral grids for WDM
applications: DWDM frequency grid", February 2012.
[G.709] ITU-T Recommendation G.709, "Interface for the optical
transport network", February 2012.
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", Work in Progress, draft-ietf-i2rs-
architecture-09, March 2015.
[I2RS-PS] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Interface
to the Routing System Problem Statement", Work in
Appendix A. Undefined Interfaces
This appendix provides a brief list of interfaces that are not yet
defined at the time of this writing. Interfaces where there is a
choice of existing protocols are not listed.
o An interface for adding additional information to the Traffic
Engineering Database is described in Section 18.104.22.168. No protocol
is currently identified for this interface, but candidates
- The protocol developed or adopted to satisfy the requirements of
- NETCONF [RFC6241]
o The protocol to be used by the Interface to the Routing System is
described in Section 22.214.171.124. The I2RS working group has
determined that this protocol will be based on a combination of
NETCONF [RFC6241] and RESTCONF [RESTCONF] with further additions
and modifications as deemed necessary to deliver the desired
function. The details of the protocol are still to be determined.
o As described in Section 126.96.36.199, the Virtual Network Topology
Manager needs an interface that can be used by a PCE or the ABNO
Controller to inform it that a client layer needs more virtual
topology. It is possible that the protocol identified for use
with I2RS will satisfy this requirement, or this could be achieved
using extensions to the PCEP Notify message (PCNtf).
o The north-bound interface from the ABNO Controller is used by the
NMS, OSS, and Application Service Coordinator to request services
in the network in support of applications as described in
- It is possible that the protocol selected or designed to satisfy
I2RS will address the requirement.
- A potential approach for this type of interface is described in
[RFC7297] for a simple use case.
o As noted in Section 188.8.131.52, there may be layer-independent data
models for offering common interfaces to control, configure, and
o As noted in Section 3.6, the ABNO model could be applied to
placing multi-segment pseudowires in a network topology made up of
S-PEs and MPLS tunnels. The current definition of PCEP [RFC5440]
and associated extensions that are works in progress do not
include all of the details to request such paths, so some work
might be necessary, although the general concepts will be easily
reusable. Indeed, such work may be necessary for the wider
applicability of PCEs in many networking scenarios.
Thanks for discussions and review are due to Ken Gray, Jan Medved,
Nitin Bahadur, Diego Caviglia, Joel Halpern, Brian Field, Ori
Gerstel, Daniele Ceccarelli, Cyril Margaria, Jonathan Hardwick, Nico
Wauters, Tom Taylor, Qin Wu, and Luis Contreras. Thanks to George
Swallow for suggesting the existence of the SRLG database. Tomonori
Takeda and Julien Meuric provided valuable comments as part of their
Routing Directorate reviews. Tina Tsou provided comments as part of
her Operational Directorate review.
This work received funding from the European Union's Seventh
Framework Programme for research, technological development, and
demonstration, through the PACE project under grant agreement
number 619712 and through the IDEALIST project under grant agreement
125 Nagog Technology Park
Acton, MA 01719
NTT Communications Corporation
NTT Communications Corporation
Y. Richard Yang
Old Dog Consulting