tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7491


A PCE-Based Architecture for Application-Based Network Operations

Part 4 of 4, p. 62 to 71
Prev RFC Part


prevText      Top      Up      ToC       Page 62 
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.

Top      Up      ToC       Page 63 
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

Top      Up      ToC       Page 64 
   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
              Progress, draft-ietf-i2rs-problem-statement-06,
              January 2015.

Top      Up      ToC       Page 65 
   [ONF]      Open Networking Foundation, "OpenFlow Switch Specification
              Version 1.4.0 (Wire Protocol 0x05)", October 2013.

              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", Work in Progress, draft-ietf-pce-pce-initiated-
              lsp-03, March 2015.

   [RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", Work in Progress, draft-ietf-netconf-
              restconf-04, January 2015.

   [RFC2748]  Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
              R., and A. Sastry, "The COPS (Common Open Policy Service)
              Protocol", RFC 2748, January 2000,

   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
              for Policy-based Admission Control", RFC 2753,
              January 2000, <>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001,

   [RFC3292]  Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
              "General Switch Management Protocol (GSMP) V3", RFC 3292,
              June 2002, <>.

   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3412,
              December 2002, <>.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              January 2003, <>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003, <>.

Top      Up      ToC       Page 66 
   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004,

   [RFC3985]  Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005,

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              August 2006, <>.

   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
              "Label Switched Path Stitching with Generalized
              Multiprotocol Label Switching Traffic Engineering (GMPLS
              TE)", RFC 5150, February 2008,

   [RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
              Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
              July 2008, <>.

   [RFC5254]  Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
              "Requirements for Multi-Segment Pseudowire Emulation Edge-
              to-Edge (PWE3)", RFC 5254, October 2008,

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008,

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008,

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              December 2008, <>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009,

   [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009, <>.

Top      Up      ToC       Page 67 
   [RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
              "Preserving Topology Confidentiality in Inter-Domain Path
              Computation Using a Path-Key-Based Mechanism", RFC 5520,
              April 2009, <>.

   [RFC5557]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
              Computation Element Communication Protocol (PCEP)
              Requirements and Protocol Extensions in Support of Global
              Concurrent Optimization", RFC 5557, July 2009,

   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, September 2009,

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009, <>.

   [RFC5810]  Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
              Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
              J.  Halpern, "Forwarding and Control Element Separation
              (ForCES) Protocol Specification", RFC 5810, March 2010,

   [RFC6007]  Nishioka, I. and D. King, "Use of the Synchronization
              VECtor (SVEC) List for Synchronized Dependent Path
              Computations", RFC 6007, September 2010,

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010, <>.

   [RFC6107]  Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
              Dynamically Signaled Hierarchical Label Switched Paths",
              RFC 6107, February 2011,

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011,

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, June 2011,

Top      Up      ToC       Page 68 
   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, September 2012,

   [RFC6805]  King, D., Ed., and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              November 2012, <>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, September 2013,

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, September 2014,

   [RFC7297]  Boucadair, M., Jacquenet, C., and N. Wang, "IP
              Connectivity Provisioning Profile (CPP)", RFC 7297,
              July 2014, <>.

              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", Work in Progress,
              draft-ietf-pce-stateful-pce-10, October 2014.

   [TL1]      Telcorida, "Operations Application Messages - Language For
              Operations Application Messages", GR-831, November 1996.

              TeleManagement Forum, "Multi-Technology Operations Systems
              Interface (MTOSI)",

   [YANG-Rtg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", Work in Progress, draft-ietf-netmod-routing-
              cfg-17, March 2015.

Top      Up      ToC       Page 69 
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  No protocol
      is currently identified for this interface, but candidates

      - The protocol developed or adopted to satisfy the requirements of
        I2RS [I2RS-Arch]

      - NETCONF [RFC6241]

   o  The protocol to be used by the Interface to the Routing System is
      described in Section  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, 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, there may be layer-independent data
      models for offering common interfaces to control, configure, and
      report OAM.

Top      Up      ToC       Page 70 
   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
   number 317999.

Top      Up      ToC       Page 71 

   Quintin Zhao
   Huawei Technologies
   125 Nagog Technology Park
   Acton, MA  01719
   United States

   Victor Lopez
   Telefonica I+D

   Ramon Casellas

   Yuji Kamite
   NTT Communications Corporation

   Yosuke Tanaka
   NTT Communications Corporation

   Young Lee
   Huawei Technologies

   Y. Richard Yang
   Yale University

Authors' Addresses

   Daniel King
   Old Dog Consulting


   Adrian Farrel
   Juniper Networks