A PCE-based Architecture for Application-based Network Operations
draft-farrkingel-pce-abno-architecture-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7491.
|
|
|---|---|---|---|
| Authors | Daniel King , Adrian Farrel | ||
| Last updated | 2013-07-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
OPSDIR Early review
(of
-11)
by Tina Tsou
Has issues
|
||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 7491 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-farrkingel-pce-abno-architecture-05
draft-farrkingel-pce-abno-architecture-05.txt July 2013 +---------------------+ | NMS/OSS | +----------+----------+ ^ | +----------+----------+ | ABNO Controller | | | +---------------------+ Figure 21: ABNO Sends Solution to the NMS/OSS 3. The concurrently computed solution received from the PCE is sent back to the NMS/OSS by the ABNO Controller. The NMS/OSS user can then check the candidate paths and either provision the new services, or save the solution for deployment in the future. 3.5 Adaptive Network Management (ANM) The ABNO architecture provides the capability for reactive network control of resources based on classification, profiling and prediction based on current demands and resource utilization. Server-layer transport network resources, such as Optical Transport Network (OTN) time-slicing [G.709], or the fine granularity grid of wavelengths with variable spectral bandwidth (flexi-grid) [G.694.1], can be manipulated to meet current and projected demands in a model called Elastic Optical Networks (EON). EON provides spectrum-efficient and scalable transport by introducing flexible granular grooming in the optical frequency domain. This is achieved using arbitrary contiguous concatenation of optical spectrum that allows creation of custom- sized bandwidth. This bandwidth is defined in slots of 12,5GHz. Adaptive Network Management (ANM) with EON allows appropriately- sized optical bandwidth to be allocated to an end-to-end optical path. In flexi-grid, the allocation is performed according to the traffic volume or following user requests, and can be achieved in a highly spectrum-efficient and scalable manner. Similarly, OTN provides an adaptive and elastic provisioning of bandwidth on top of wavelength switched optical networks (WSON). To efficiently use optical resources, a system is required which can monitor network resources, and decide the optimal network configuration based on the status, bandwidth availability and user service. We call this ANM. King & Farrel [Page 41] draft-farrkingel-pce-abno-architecture-05.txt July 2013 3.5.1. ANM Trigger There are different reasons to trigger an adaptive network management process, these include: o Measurement: traffic measurements can be used in order to cause spectrum allocations that fit the traffic needs as efficiently as possible. This function may be influenced by measuring the IP router traffic flows, by examining traffic engineering or link state databases, by usage thresholds for critical links in the network, or by requests from external entities. Nowadays, network operators have active monitoring probes in the network, which store their results in the OSS. The OSS or OAM Handler components activate this measurement-based trigger, so the ABNO Controller would not be directly involved in this case. o Human: operators may request ABNO to run an adaptive network planning process via a NMS. o Periodic: adaptive network planning process can be run periodically to find an optimum configuration. An ABNO Controller would receive a request from OSS or NMS to run an adaptive network manager process. 3.5.2. Processing request and GCO computation Based on the human of periodic trigger requests described in the previous Section, the OSS or NMS will send a request to the ABNO Controller to perform EON-based GCO. The ABNO Controller will select a set of services to be reoptimized and choose an objective function that will deliver the best use of network resources. In making these choices, the ABNO Controller is guided by network-wide policy on the use of resources, the definition of optimization, and the level of perturbation to existing services that is tolerable. Much as in Section 3.5, this request for GCO is passed to the PCE. The PCE could then consider the end-to-end paths and every channel's optimal spectrum assignment in order to satisfy traffic demands and optimize the optical spectrum consumption within the network. The PCE will operate on the TED, but is likely to also be stateful so that it knows which LSPs correspond to which waveband allocations on which links in the network. Once PCE arrives at an answer, it returns a set of potential paths to the ABNO Controller which passes them on to the NMS or OSS to supervise/select the subsequent path set-up/modification process. King & Farrel [Page 42] draft-farrkingel-pce-abno-architecture-05.txt July 2013 This exchange is shown in Figure 22. Note that the figure does not show the interactions used by the OSS/NMS for establishing or modifying LSPs in the network. +---------------------------+ | OSS or NMS | +-----------+---+-----------+ | ^ V | +------+ +----------+---+----------+ |Policy+->-+ ABNO Controller | |Agent | | | +------+ +----------+---+----------+ | ^ V | +-----+---+----+ + PCE | +--------------+ Figure 22: Adaptive Network Management with human intervention 3.5.3. Automated Provisioning Process Although most of network operations are supervised by the operator, there are some actions, which may not require supervision, like a simple modification of a modulation format in a Bit rate variable transponder (BVT) (to increase the optical spectrum efficiency or reduce energy consumption). In this processes, where human intervention is not required, PCE sends provisioning manager new configuration to configure the network elements. King & Farrel [Page 43] draft-farrkingel-pce-abno-architecture-05.txt July 2013 +------------------------+ | OSS or NMS | +-----------+------------+ | V +------+ +----------+------------+ |Policy+->-+ ABNO Controller | |Agent | | | +------+ +----------+------------+ | V +------+------+ + PCE | +------+------+ | V +----------------------------------+ | Provisioning Manager | +----------------------------------+ Figure 23: Adaptive Network Management without human intervention 3.6 Pseudowire Operations and Management Pseudowires in an MPLS network [RFC3985] operate as a form of layered network over the connectivity provided by the MPLS network. The pseudowires are carried by LSPs operating as transport tunnels, and planning is necessary to determine how those tunnels are placed in the network and which tunnels are used by any pseudowire. This section considers four use cases: multi-segment pseudowires, path-diverse pseudowires, path-diverse multi-segment pseudowires, and pseudowire segment protection. Section 3.6.4 describes the applicability of the ABNO architecture to these four use cases. 3.6.1 Multi-Segment Pseudowires [RFC5254] described the architecture for multi-segment pseudowires. An end-to-end service, as shown in Figure 24, can consist of a series of stitched segments shown on the figure as AC, PW1, PW2, PW3, and AC. Each pseudowire segment is stitched at a 'stitching PE' (S- PE): for example, PW1 is stitched to PW2 at S-PE1. Each access circuit (AC) is stitched to a pseudowire segment at a 'terminating PE' (T-PE): for example, PW1 is stitched to the AC at T-PE1. Each pseudowire segment is carried across the MPLS network in an LSP operating as a transport tunnel: for example, PW1 is carried in LSP1. The LSPs between PEs may traverse different MPLS networks with the King & Farrel [Page 44] draft-farrkingel-pce-abno-architecture-05.txt July 2013 PEs as border nodes, or the PEs may lie within the same network such such that the LSPs each only span part of the network. ----- ----- ----- ----- --- |T-PE1| LSP1 |S-PE1| LSP2 |S-PE3| LSP3 |T-PE2| +---+ | | AC | |=======| |=======| |=======| | AC | | |CE1|----|........PW1........|..PW2........|..PW3........|----|CE2| | | | |=======| |=======| |=======| | | | --- | | | | | | | | +---+ ----- ----- ----- ----- Figure 24 : Multi-Segment Pseudowire While the topology shown in Figure 24 is easy to navigate, the reality of a deployed network can be considerably more complex. The topology in Figure 25 shows a small mesh of PEs. The links between the PEs are not physical links but represent the potential of MPLS LSPs between the PEs. When establishing the end-to-end service between CE1 and CE2, some choice must be made about which PEs to use. In other words, a path computation must be made to determine the pseudowire segment 'hops', and then the necessary LSP tunnels must be established to carry the pseudowire segments that will be stitched together. Of course, each LSP may itself require a path computation decision to route it through the MPLS network between PEs. The choice of path for the multi-segment pseudowire will depend on such issues as: - MPLS connectivity - MPLS bandwidth availability - pseudowire stitching capability and capacity at PEs - policy and confidentiality considerations for use of PEs. ----- |S-PE5| /-----\ --- ----- -----/ \----- ----- --- |CE1|----|T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|----|CE2| --- -----\ -----\ ----- /----- --- \ | ------- | / \ ----- \----- / -----|S-PE2|-------|S-PE4|----- ----- ----- Figure 25 : Multi-Segment Pseudowire Network Topology King & Farrel [Page 45] draft-farrkingel-pce-abno-architecture-05.txt July 2013 3.6.2 Path-Diverse Pseudowires The connectivity service provided by a pseudowire may need to be resilient to failure. In many cases, this function is provided by provisioning a pair of pseudowires carried by path-diverse LSPs across the network as shown in Figure 26 (the terminology is inherited directly from [RFC3985]). Clearly, in this case, the challenge is to keep the two LSPs (LSP1 and LSP2) disjoint within the MPLS network. This problem is not different from the normal MPLS path-diversity problem. ------- ------- | PE1 | LSP1 | PE2 | AC | |=======================| | AC ----...................PW1...................---- --- - / | |=======================| | \ ----- | |/ | | | | \| | | CE1 + | | MPLS Network | | + CE2 | | |\ | | | | /| | --- - \ | |=======================| | / ----- ----...................PW2...................---- AC | |=======================| | AC | | LSP2 | | ------- ------- Figure 26 : Path-Diverse Pseudowires The path-diverse pseudowire is developed in Figure 27 by the "dual- homing" of each CE through more than one PE. The requirement for LSP path diversity is exactly the same, but it is complicated by the LSPs having distinct end points. In this case, the head-end router (e.g., PE1) cannot be relied upon to maintain the path diversity through the signaling protocol because it is aware of the path of the only one of the LSPs. Thus some form of coordinated path computation approach is needed. King & Farrel [Page 46] draft-farrkingel-pce-abno-architecture-05.txt July 2013 ------- ------- | PE1 | LSP1 | PE2 | AC | |=======================| | AC ---...................PW1...................--- / | |=======================| | \ ----- / | | | | \ ----- | |/ ------- ------- \| | | CE1 + MPLS Network + CE2 | | |\ ------- ------- /| | ----- \ | PE3 | | PE4 | / ----- \ | |=======================| | / ---...................PW2...................--- AC | |=======================| | AC | | LSP2 | | ------- ------- Figure 27 : Path-Diverse Pseudowires With Disjoint PEs 3.6.3 Path-Diverse Multi-Segment Pseudowires Figure 28 shows how the services in the previous two sections may be combined to offer end-to-end diverse paths in a multi-segment environment. To offer end-to-end resilience to failure, two entirely diverse, end-to-end multi-segment pseudowires may be needed. ----- ----- |S-PE5|--------------|T-PE4| /-----\ ----- \ ----- -----/ \----- ----- \ --- |T-PE1|-------|S-PE1|-------|S-PE3|-------|T-PE2|--|CE2| --- / -----\ -----\ ----- /----- --- |CE1|< ------- | ------- | / --- \ ----- \----- \----- / |T-PE3|-------|S-PE2|-------|S-PE4|----- ----- ----- ----- Figure 28 : Path-Diverse Multi-Segment Pseudowire Network Topology Just as in any diverse-path computation, the selection of the first path needs to be made with awareness of the fact that a second, fully-diverse path is also needed. If a sequential computation was applied to the topology in Figure 28, the first path CE1,T-PE1,S-PE1, S-PE3,T-PE2,CE2 would make it impossible to find a second path that was fully diverse from the first. But the problem is complicated by the multi-layer nature of the network. It is not enough that the PEs are chosen to diverse because the LSP tunnels between them might share links within the MPLS King & Farrel [Page 47] draft-farrkingel-pce-abno-architecture-05.txt July 2013 network. Thus, a multi-layer planning solution is needed to achieve the desired level of service. 3.6.4 Pseudowire Segment Protection An alternative to the end-to-end pseudowire protection service described in Section 3.6.3 can be achieved by protecting individual pseudowire segments or PEs. For example, in Figure 28, the pseudowire between S-PE1 and S-PE5 may be protected by a pair of stitched segments running between S-PE1 and S-PE5, and between S-PE5 and S-PE3. This is shown in detail in Figure 29. ------- ------- ------- | S-PE1 | LSP1 | S-PE5 | LSP3 | S-PE3 | | |============| |============| | | .........PW1..................PW3.......... | Outgoing Incoming | : |============| |============| : | segment segment | : | ------- | :.......... ...........: | | : | | : | | : | | : |=================================| : | | .........PW2............................... | | |=================================| | | | LSP2 | | ------- ------- Figure 29 : Fragment of a Segment-Protected Multi-Segment Pseudowire The determination of pseudowire protection segments requires coordination and planning, and just as in Section 3.6.5, this planning must be cognizant of the paths taken by LSPs through the underlying MPLS networks. 3.6.5 Applicability of ABNO to Pseudowires The ABNO architecture lends itself well to the planning and control pseudowires in the use cases described above. The user or application needs a single point at which it requests services: the ABNO Controller. The ANBO Controller can ask a PCE to draw on the topology of pseudowire stiching-capable PEs as well as additional information regarding PE capabilities, such as load on PEs and administrative policies, and the PCE can use a series of TEDs or other PCEs for the underlying MPLS networks to determine the paths of the LSP tunnels. Then a number of different provisioning systems can be used to instantiate the LSPs and provision the pseudowires under the control of the Provisioning Manager. The ABNO Controller will use the I2RS Client to instruct the network devices about what King & Farrel [Page 48] draft-farrkingel-pce-abno-architecture-05.txt July 2013 traffic should be placed on which pseudowires, and in conjunction with the OAM Handler can ensure that failure events are handled correctly, that service quality levels are appropriate, and that service protection levels are maintained. 3.7 Other Potential Use Cases This section serves as a place-holder for other potential use cases that might get documented in a future revision of this document. 3.7.1 Grooming and Regrooming This use case could cover the following scenarios: - Nested LSPs - Packet Classification (IP flows into LSPs at edge routers) - Bucket Stuffing - IP Flows into ECMP Hash Bucket 3.7.2 Bandwidth Scheduling Bandwidth Scheduling consist of configuring LSPs based on a given time schedule. This can be used to support maintenance or operational schedules or to adjust network capacity based on traffic pattern detection. The ABNO framework provides the components to enable bandwidth scheduling solutions. 3.7.3 ALTO Server A use case describing the ALTO server is needed.] 4. Survivability and Redundancy within the ABNO Architecture [Editor's note: this section to be written with consideration of how the ABNO system survives the failure of individual components.] 5. Security Consideration [Editor's note: this section to be written.] 6. Manageability Considerations [Editor's note: this section to be written.] King & Farrel [Page 49] draft-farrkingel-pce-abno-architecture-05.txt July 2013 7. IANA Considerations This document makes no requests for IANA action. 8. 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, Diego Caviglia Cyril Margaria, and Jonathan Hardwick. This work was supported in part by the FP-7 IDEALIST project under grant agreement number 317999. 9. References 9.1. Informative References [I-D.atlas-i2rs-architecture] Ward, D., Halpern, J., and S. Hares, An Architecture for the Interface to the Routing System", draft-atlas-i2rs-architecture, work in progress. [I-D.atlas-i2rs-problem-statement] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", draft-atlas-i2rs-problem-statement, work in progress. [I-D.boucadair-connectivity-provisioning-profile] Boucadair, M., Jacquenet, c., and N. Wang, "IP/MPLS Connectivity Provisioning Profile", draft-boucadair-connectivity-provisioning-profile, work in progress. [I-D.crabbe-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and Varga, R., "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-crabbe-pce-pce-initiated-lsp, work in progress. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Yang, Y., "ALTO Protocol", draft-ietf-alto-protocol, work in progress. King & Farrel [Page 50] draft-farrkingel-pce-abno-architecture-05.txt July 2013 [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and Ray, S., "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution, work in progress. [I-D.ietf-netmod-routing-cfg] Lhotka, L., "A YANG Data Model for Routing Management", draft-ietf-netmod-routing-cfg, work in progress. [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, work in progress. [ONF] Open Networking Foundation, "OpenFlow Switch Specification Version 1.1.0 Implemented (Wire Protocol 0x02)", February 2011. [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", RFC2753, January 2000. [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and Worster, T., "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002. [RFC3412] Case, J., Harrington, D., Preshun, R., and Wijnen, B., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 3412, December 2002. [RFC3473] L. Berger et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3630] Katz, D., Kmpella, K., and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. King & Farrel [Page 51] draft-farrkingel-pce-abno-architecture-05.txt July 2013 [RFC3746] Yang, L., Dantu, R., Anderson, T., and Gopal, R., "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 Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5101] B. Claise, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP. and Farrel, A., "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 Brungard, D., "Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008. [RFC5254] Bitar, N., Bocci, M. and L. Martini, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 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 Ash, J., "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5424] R. Gerhards, "The Syslog Protocol", RFC 5424, March 2009. [RFC5440] Vasseur, JP. and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5520] Bradford, R., Vasseur, JP., and Farrel, A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RC 5520, April 2009. King & Farrel [Page 52] draft-farrkingel-pce-abno-architecture-05.txt July 2013 [RFC5557] Lee, Y., Le Roux, JL., King, D., and Oki, E., "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 Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009. [RFC5693] Seedorf, J., and Burger, E., "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC5810] A. Doria, et al., "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. [RFC6007] I. Nishioka. and D. King., "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, September 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011. [RFC6120] P. Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, A., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and Bitar, N., "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. [RFC6805] King, D. and Farrel, A., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012. [TL1] Telcorida, "Operations Application Messages - Language For Operations Application", GR-831, November 1996. King & Farrel [Page 53] draft-farrkingel-pce-abno-architecture-05.txt July 2013 [G.694.2] ITU-T Recommendation G.694.2, "Spectral grids for WDM applications: CWDM wavelength grid", December 2003. [G.709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation, October 2009. 10. Contributors' Addresses Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Victor Lopez Alvarez 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 Ina Minei Juniper Networks ina@juniper.net 11. Authors' Addresses Daniel King Old Dog Consulting Email: daniel@olddog.co.uk Adrian Farrel Juniper Networks Email: adrian@olddog.co.uk King & Farrel [Page 54] draft-farrkingel-pce-abno-architecture-05.txt July 2013 Appendix A. Undefined Interfaces This Appendix provides a brief list of interfaces that are not yet defined at the time of writing. Interfaces where there is a choice of existing protocols are not listed. - An interface for adding additional information to the Treaffic 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 [I-D.atlas-i2rs-architecture] - Netconf [RFC6241] - The protocol or protocols to be used by the Interface to the Routing System described in Section 2.3.2.8 have yet to be determined. The I2RS working group will make this decision after use cases and protocol requirements have been agreed. Various candidate protocols have been identified although none appears to be suitable without some extensions to the currently-specified protocol elements. The list of protocols supplied here is illustrative and not intended to constrain the work of the I2RS working group. The order of the list is not significant. - OpenFlow [ONF] - Netconf [RFC6241] - ForCES [RFC3746] - 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. - 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. - A potential approach for this tyoe of interface is described in [I-D.boucadair-connectivity-provisioning-profile] for a simple use case. King & Farrel [Page 55]