Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7491

A PCE-Based Architecture for Application-Based Network Operations

Pages: 71
Informational
Part 4 of 4 – Pages 62 to 71
First   Prev   None

Top   ToC   RFC7491 - Page 62   prevText

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.
Top   ToC   RFC7491 - 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 policies.
Top   ToC   RFC7491 - 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", <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.
Top   ToC   RFC7491 - Page 65
   [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>.
Top   ToC   RFC7491 - Page 66
   [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>.
Top   ToC   RFC7491 - 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, <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>.
Top   ToC   RFC7491 - Page 68
   [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.
Top   ToC   RFC7491 - 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 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.
Top   ToC   RFC7491 - 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.

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.
Top   ToC   RFC7491 - Page 71

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.edu

Authors' Addresses

Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk