RFC 7491
A PCE-Based Architecture for Application-Based Network Operations
Pages: 71
Informational
Informational
Part 4 of 4 – Pages 62 to 71
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 resiliency. 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 policies.
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 system7. 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", <http://www.projectfloodlight.org>. [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. [I2RS-Arch] 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.
[ONF] Open Networking Foundation, "OpenFlow Switch Specification Version 1.4.0 (Wire Protocol 0x05)", October 2013. [PCE-Init-LSP] 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, <http://www.rfc-editor.org/info/rfc2748>. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>. [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, <http://www.rfc-editor.org/info/rfc3209>. [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002, <http://www.rfc-editor.org/info/rfc3292>. [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, <http://www.rfc-editor.org/info/rfc3412>. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>. [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, <http://www.rfc-editor.org/info/rfc5150>. [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, <http://www.rfc-editor.org/info/rfc5212>. [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, <http://www.rfc-editor.org/info/rfc5254>. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008, <http://www.rfc-editor.org/info/rfc5277>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008, <http://www.rfc-editor.org/info/rfc5394>. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>. [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[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, <http://www.rfc-editor.org/info/rfc5520>. [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, <http://www.rfc-editor.org/info/rfc5557>. [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, <http://www.rfc-editor.org/info/rfc5623>. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>. [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, <http://www.rfc-editor.org/info/rfc5810>. [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, September 2010, <http://www.rfc-editor.org/info/rfc6007>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>. [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, <http://www.rfc-editor.org/info/rfc6805>. [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, <http://www.rfc-editor.org/info/rfc7011>. [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, <http://www.rfc-editor.org/info/rfc7285>. [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, July 2014, <http://www.rfc-editor.org/info/rfc7297>. [Stateful-PCE] 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. [TMF-MTOSI] TeleManagement Forum, "Multi-Technology Operations Systems Interface (MTOSI)", <https://www.tmforum.org/MTOSI/2319/home.html>. [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.
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 2.3.2.3. No protocol is currently identified for this interface, but candidates include: - 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 2.3.2.8. 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 2.3.2.10, 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 Section 2.3.2.11. - 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 2.3.2.14, there may be layer-independent data models for offering common interfaces to control, configure, and report OAM.
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.Acknowledgements
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.
Contributors
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States EMail: qzhao@huawei.com Victor Lopez Telefonica I+D EMail: vlopez@tid.es Ramon Casellas CTTC EMail: ramon.casellas@cttc.es Yuji Kamite NTT Communications Corporation EMail: y.kamite@ntt.com Yosuke Tanaka NTT Communications Corporation EMail: yosuke.tanaka@ntt.com Young Lee Huawei Technologies EMail: leeyoung@huawei.com Y. Richard Yang Yale University EMail: yry@cs.yale.eduAuthors' Addresses
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk