RFC 8637
Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)
1. Introduction ✨
okay so bestie, this is RFC 8637 🎀, and it's an Informational doc (not a Standards Track thing, so it's more of a "here's how this all fits together" vibe 💅). It was written by D. Dhody (Huawei Technologies), Y. Lee (Futurewei Technologies), and D. Ceccarelli (Ericsson), and it came out in July 2019 🦋. Its title is "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", and it's giving a whole architecture-meets-protocol crossover 🌈. It doesn't obsolete or update any other RFCs.
The IETF wrote this one, and it's published with ISSN 2070-1721 🧚.
The abstract is basically the whole premise 💖. ACTN is the set of virtual network (VN) operations you need to orchestrate, control, and manage big multidomain TE networks, so you get network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services 🔥. The PCE is a component, app, or network node that can compute a network path or route from a network graph while applying computational constraints 💜. It serves requests from Path Computation Clients (PCCs), which talk to it over a local API or with the Path Computation Element Communication Protocol (PCEP) 🍓. This doc looks at how PCE applies to the ACTN framework, and that's the whole mission ✨.
1.1. Status of This Memo ⭐
Okay, so this is not an Internet Standards Track spec, it's published for information only 🫶. It's a product of the IETF, meaning it represents the consensus of the IETF community, got public review, and was approved by the Internet Engineering Steering Group (IESG) 🎀. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 💅. You can find the current status, errata, and feedback info at https://www.rfc-editor.org/info/rfc8637 🌸.
1.2. Copyright Notice 🌈
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 🦋. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date, so read them carefully because they spell out your rights and restrictions 💖. If you extract Code Components from this doc, they have to include Simplified BSD License text (per Section 4.e of the Trust Legal Provisions), and they come without warranty as described in that license 🔥.
1.3. Table of Contents 🧚
Here's the full roadmap, so you know what's coming 💅:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background Information . . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3
2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4
2.1.2. PCE in Multidomain and Multilayer Deployments . . . . 4
2.1.3. Relationship to PCE-Based Central Control . . . . . . 5
2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
3. Architectural Considerations . . . . . . . . . . . . . . . . 7
3.1. Multidomain Coordination via Hierarchy . . . . . . . . . 7
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 221.4. Introduction Continued 💖
Okay so this is where the doc actually starts. ACTN is defined in [RFC8453] as that same VN-operations set for orchestrating, controlling, and managing big multidomain TE networks 🌸, and the PCE, defined in [RFC4655], is the same component-app-or-node that computes paths from a graph with constraints 🔥.
This doc looks at the PCE and ACTN architecture, explains how PCE fits ACTN, lists the PCEP extensions you'd need to use PCEP as an ACTN interface 💅, and points out any gaps in PCEP that existed when this was published 🫶.
And one more thing bestie: ACTN, stateful Hierarchical PCE (H-PCE) [PCE-HPCE], and PCE as a central controller (PCECC) [RFC8283] are all built on the same basic hierarchy framework, so they're compatible with each other 👑✨.
2.2. Abstraction and Control of TE Networks (ACTN) ✨
okay so ACTN is the big picture for controlling traffic engineered networks 🌸 [RFC8453] lays out the high-level ACTN requirements and the architecture model, including the entities Customer Network Controller (CNC), Multidomain Service Coordinator (MDSC), and Provisioning Network Controller (PNC), plus their interfaces 💖
bestie, [RFC8453] is still the definitive reference for ACTN architecture 🫶 we're just reproducing its diagram here for convenience, so go check the original if you need the official word 📚
Here's the ACTN reference architecture, shown as Figure 1 🦋 It's a three-tier hierarchy, and honestly it's giving very organised vibes ✨
+---------+ +---------+ +---------+
| CNC | | CNC | | CNC |
+---------+ +---------+ +---------+
\ | /
\ | /
Boundary =============\==============|==============/============
Between \ | /
Customer & ------- | CMI -------
Network Operator \ | /
+---------------+
| MDSC |
+---------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | / \
| / | SBI / \
--------- ----- | / \
( ) ( ) | / \
- Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net )
----- -----
CMI - (CNC-MDSC Interface)
MPI - (MDSC-PNC Interface)
SBI - (Southbound Interface)
Figure 1: ACTN Hierarchyso there are two interfaces around the MDSC 🎀 one sits north of it (the CNC-MDSC Interface, aka CMI) and one sits south (the MDSC-PNC Interface, aka MPI) 💅 and you can have a hierarchy of MDSCs too, as long as the MPI interface is recursive 👑
[RFC8454] gives you an information model for ACTN interfaces 🧚
3. Architectural Considerations 🌈
The ACTN architecture [RFC8453] is built on a hierarchy and recursiveness of controllers 💜 It defines three types of controllers, depending on which functionalities they implement 🔥 The main functionalities are:
- Multidomain coordination
- Abstraction
- Customer mapping/translation
- Virtual service coordination
Section 3 of [RFC8453] describes these functions 📖
now, a little heads-up 🚨 this document lists every possible way PCE could be used for each of the functions above, but NOT all functions are required to be implemented via PCE 🙈 same deal with PCEP: this document shows how it could be the communications medium between functional components. Operators may use PCEP for multidomain coordination via stateful H-PCE, but alternatively they can use Network Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] to get access to the topology and support the abstraction function 🦋
3.1. Multidomain Coordination via Hierarchy ✨
so with a domain defined as everything under the control of a single logical controller, as per [RFC8453], you need BOTH a control entity overseeing the specific aspects of each domain AND a single abstracted end-to-end network topology, so you can coordinate end-to-end path computation and path/service provisioning 🌸
The MDSC handles this by coordinating the per-domain PNCs in a hierarchy of controllers 💖 It also has to detach from the underlying network technology and express customer concerns in terms of business needs 💅
[RFC6805] and [PCE-HPCE] describe a hierarchy of PCEs, where the Parent PCE coordinates multidomain path computation between Child PCEs 🧚 these principles line up really nicely, so the stateful H-PCE architecture can be used to realize ACTN 🫶
The per-domain stitched LSP in the Hierarchical stateful PCE architecture, described in Section 3.3.1 of [PCE-HPCE], is a great fit for the multidomain coordination function 🔥 That includes domain sequence selection, End-to-End (E2E) path computation, and controller-initiated (PCE-initiated) path setup and reporting 👑 It also applies to multilayer coordination in IP+optical networks 🌈
[PCE-STATE-SYNC] describes the procedures for stateful communication between PCEs across various use cases ✨ The procedures and extensions also apply to Child and Parent PCE communication, so they're useful for ACTN too 🎀
3.2. Abstraction 🦋
to realize ACTN, you need an abstracted view of the underlying network resources 💜 That includes a global network-wide abstracted topology built from the underlying resources of each domain 🌸 It also includes an abstract topology created from customer service connectivity requests, represented as a VN slice allocated to each customer 💖
to compute and provide optimal paths, PCEs need an accurate and timely Traffic Engineering Database (TED) 🧚 Traditionally, this TED came from a link-state (LS) routing protocol with traffic engineering extensions 📚 A PCE may build its TED by participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS) 🔥 BGP-LS [RFC7752] is the alternative 🫶
for H-PCE [RFC6805], the Parent PCE needs to build the domain topology map of the child domains and how they interconnect 🌈 [RFC6805] and [PCE-INTER-AREA] suggest BGP-LS could be used as a "northbound" TE advertisement from the Child PCE to the Parent PCE 💅
[PCEP-LS] proposes another way to learn and maintain Link-State and TE information, as an alternative to IGP and BGP flooding, using PCEP itself ✨ A Child PCE can use this mechanism to carry Link-State and TE information up to a Parent PCE over PCEP 💖
in ACTN, you need to control the level of abstraction based on the deployment scenario and the business relationship between controllers 👑 The mechanism used to send information from the PNC (Child PCE) to the MDSC (Parent PCE) should support abstraction 🎀 [RFC8453] describes a few alternative approaches to abstraction 🦋 The resulting abstracted topology can be encoded using the PCEP-LS mechanisms [PCEP-LS] and its optical network extension [PCEP-OPTICAL] 🌸 PCEP-LS is a really attractive option if the operator wants a single control-plane protocol (PCEP) to handle ACTN functions 💜
[RFC8453] discusses two ways for the MDSC to build abstract topology when interacting with PNCs 🧚 The primary method is called automatic generation of abstract topology by configuration 🔥 Here, the generation is based on the PNC abstracting/summarising the whole domain and advertising that on the MPI 💅 The secondary method is called on-demand generation of supplementary topology via Path Compute Request/Reply 🫶 This may be needed to get extra information, like potential connectivity from Child PCEs, to help with end-to-end path provisioning 🌈 PCEP is well suited to support both methods 👑
3.3. Customer Mapping 💅
ACTN needs to map customer virtual network (VN) requirements into a network provisioning request sent to the PNC ✨ Basically, the MDSC maps customer requests/commands into network provisioning requests that can go to the PNC 🎀 Specifically, the MDSC maps and translates a customer's service request into a set of parameters specific to a network type and technology, so the network configuration process can actually happen 💖
[RFC8281] describes setting up, maintaining, and tearing down PCE-initiated LSPs under the stateful PCE model 🧚 It doesn't need local configuration on the PCC, so you get a dynamic network that's centrally controlled and deployed 🌸 To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC 🦋 As described in [PCE-HPCE], for an interdomain LSP in a Hierarchical PCE architecture, the initiation operations can be carried out at the Parent PCE 🔥 In that case, once the Parent PCE finishes the E2E path computation, it can send the PCInitiate message to the Child PCE, and the Child PCE passes the initiate request on to the Label Switching Router (LSR) 💜
the customer request gets received by the MDSC (Parent PCE) 👑 Based on business logic, the global abstracted topology, network conditions, and local policy, the MDSC (Parent PCE) translates it into a per-domain LSP initiation request that a PNC (Child PCE) can understand and act on 🌈 This can be done via the PCInitiate message 🫶
PCEP extensions for associating opaque policy between PCEP peers [ASSOC-POLICY] can be used 🎀
3.4. Virtual Service Coordination 🌸
Virtual service coordination in ACTN brings customer service-related information into the virtual network service operations 💖 That way you can operate virtual networks smoothly while still meeting customers' service requirements 💅
[PCEP-VN] describes why you'd want to associate a set of LSPs with a VN "construct" to make VN operations work in PCE architecture ✨ This association lets the PCEs figure out which LSPs belong to a certain VN 🧚
this VN-based association is super useful for optimisations at the VN level, which can apply to every LSP that's part of the VN slice 🔥 During path computation, the impact of a path for one LSP is compared against the paths of the other LSPs in the VN 🦋 That makes sure you optimise and hit SLA targets for the whole VN, not just a single LSP 💜 Similarly, during reoptimization, advanced path computation algorithms and optimisation techniques can be considered for all the LSPs belonging to a VN/customer, and optimised together 👑
4. Interface Considerations ✨
okay so bestie, as per [RFC8453], the network has to provide open, programmable interfaces 💅 so that virtualization and multidomain coordination can actually happen. customer apps can create, replace, and modify virtual network resources and services in an interactive, flexible, and dynamic way, and it has no impact on other customers 🫶. there are two ACTN interfaces:
- The CNC-MDSC Interface (CMI) is the one between a Customer Network Controller and a Multidomain Service Coordinator 🎀. it requests the creation of network resources, topology, or services for the applications. the MDSC may also report potential network topology availability if the Customer Network Controller asks it about current capability ✨.
- The MDSC-PNC Interface (MPI) is the one between a Multidomain Service Coordinator and a Provisioning Network Controller 🦋. it communicates the creation request, if one is required, of new connectivity or bandwidth changes in the physical network, through the PNC. in multidomain environments the MDSC needs to set up multiple MPIs, one for each PNC, because there are multiple PNCs in charge of its domain control 👑.
in the case of a hierarchy of MDSCs, the MPI is applied recursively 🌈. from an abstraction point of view, the top-level MDSC (the one that talks to the CNC) works at a higher level of abstraction (i.e., a less granular level) than the lower-level MDSCs. it's giving zoomed-out big picture 🔭.
PCEP is especially suitable on the MPI because it meets the requirements and functions set out in the ACTN framework [RFC8453] 💖. its recursive nature fits really well with the multilevel hierarchy of PCE 🧚. PCEP can also be applied to the CMI, since the CNC can be a path computation client while the MDSC can be a path computation server 💜. Section 5 describes how PCE and PCEP could help realize ACTN on the MPI 🍓.
5. Realizing ACTN with PCE (and PCEP) 🎀
okay this is the fun part 😭. as per the example in Figure 2, there are 4 domains, each with their own PNC and an MDSC on top. the PNC and MDSC both need PCE as an important function. the PNC (or Child PCE) already uses PCEP to talk to the network device, and it can use PCEP as the MPI to talk between controllers too 🔥.
******
..........*MDSC*..............................
. ****** .. MPI .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
\ / .
\ ****** / .
\ *PNC3*<............/.....................
\ ****** /
\+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 2: ACTN with PCE- Building Domain Topology at MDSC 🗺️: the PNC (or Child PCE) needs to have the TED to compute the path in its domain. as described in Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS is also a proposed mechanism to carry link state and traffic engineering information within PCEP. a mechanism to carry abstracted topology while hiding technology-specific information between PNC and MDSC is described in [PCEP-LS]. by the end of this step, the MDSC (or Parent PCE) has the abstracted topology from each of its PNCs (or Child PCE). this could be as simple as a domain topology map as described in [RFC6805], or it can have full topology information of all domains. the latter is not scalable 😬, so an abstracted topology of each domain interconnected by interdomain links is the most common case 💅.
- Topology Change 🔄: when the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. this depends on the level of abstraction between the MDSC and the PNC 🤔.
- VN Instantiate 🌸: when an MDSC is asked to instantiate a VN, the minimal information required is a VN identifier and a set of end points. various path computation, setup constraints, and objective functions may also be provided. in PCE terms, a VN Instantiate can be thought of as a set of paths belonging to the same VN. as described in Section 3.4 and [PCEP-VN], the VN association can help identify the set of paths that belong to a VN. the rest of the information, like the endpoints, constraints, and objective function (OF), is already defined in PCEP in terms of a single path 🧠.
- Path Computation 🧮: as per the example in Figure 2, the VN instantiate needs two end-to-end paths: (A in Domain 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). the MDSC (or Parent PCE) triggers the end-to-end path computation for these two paths. the MDSC can compute paths based on the abstracted domain topology it already has, or it can use the H-PCE procedures (Section 3.1) with the PCReq and PCRep messages to get the end-to-end path with the help of the Child PCEs (PNC). either way, the resulting E2E paths may be broken into per-domain paths ✂️.
- A-B: (A-B13,B13-B31,B31-B)
- A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C)
- Per-Domain Path Instantiation 🚀: based on the path computation above, the MDSC can send the path instantiation request to each PNC via a PCInitiate message (see [PCE-HPCE] and [PCEP-VN]). a suitable stitching mechanism is used to stitch these per-domain LSPs together. one such mechanism is described in [PCE-INTERDOMAIN], where PCEP is extended to support stitching in a stateful H-PCE context 🪡.
- Per-Domain Path Report 📋: each PNC should report the status of its per-domain LSP to the MDSC via a PCRpt message, following the hierarchy of stateful PCEs ([PCE-HPCE]). the status of the end-to-end LSP (A-B and A-C) is pieced together once all the per-domain LSPs have been reported up by the PNCs 🧩.
- Delegation 🤝: it is suggested that the per-domain LSPs are delegated to their respective PNCs, so they can control the path and attributes based on the conditions of each domain network 💜.
- State Synchronization 🔁: the state needs to be synchronized between the Parent PCE and the Child PCE. the mechanism described in [PCE-STATE-SYNC] can be used ✨.
- Path Computation 🧮: as per the example in Figure 2, the VN instantiate needs two end-to-end paths: (A in Domain 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). the MDSC (or Parent PCE) triggers the end-to-end path computation for these two paths. the MDSC can compute paths based on the abstracted domain topology it already has, or it can use the H-PCE procedures (Section 3.1) with the PCReq and PCRep messages to get the end-to-end path with the help of the Child PCEs (PNC). either way, the resulting E2E paths may be broken into per-domain paths ✂️.
- VN Modify ✏️: the MDSC is asked to modify a VN, for example when the bandwidth for the VN is increased. this may trigger path computation at the MDSC as described in the previous step, and it can trigger an update to an existing per-intradomain path (via a PCUpd message) or the creation (or deletion) of a per-domain path (via a PCInitiate message). as described in [PCE-HPCE], this should be done in make-before-break fashion 🙌.
- VN Delete 🗑️: the MDSC is asked to delete a VN. in this case, based on the E2E paths, the resulting per-domain paths need to be removed (via a PCInitiate message) 👋.
- VN Update (based on network changes) 🌊: any change in a per-domain LSP is reported to the MDSC (via a PCRpt message) as per [PCE-HPCE]. this may result in changes to the E2E path or VN status. it may also trigger a reoptimization leading to a new per-domain path, an update to an existing path, or the deletion of the path 🔄.
- VN Protection 🛡️: the VN protection/restoration requirements need to be applied to each E2E path as well as each per-domain path. the MDSC needs to play a crucial role in coordinating the right protection/restoration policy across each PNC. the existing protection/restoration mechanism of PCEP can be applied on each path 💪.
- Abstract Topology Paths 🪞: in case a PNC generates an abstract topology towards the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links. a PNC would need to take that as an input for path computation to get a path with physical nodes and links. similarly, a PNC would convert the path received from the device (with physical nodes and links) into an abstract path (based on the abstract topology generated earlier, with abstract nodes and links) and report it to the MDSC 🌈.
6. IANA Considerations 🌸
quick one 🦋: this document has no IANA actions.
7. Security Considerations ✨
okay bestie, security is literally the most important part of this whole doc, so let's get into it 🔐💅
Various security considerations for PCEP are described in [RFC5440] and [RFC8253]. Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply on PCEP when used as an ACTN interface. Further, this document lists various extensions of PCEP that are applicable; each of them specify various security considerations that continue to apply here. 🎀
The ACTN framework described in [RFC8453] defines key components and interfaces for managed traffic-engineered networks. It also lists various security considerations such as request and control of resources, confidentially of the information, and availability of function, which should be taken into consideration. 🦋
As per [RFC8453], securing the request and control of resources, confidentiality of the information, and availability of function should all be critical security considerations when deploying and operating ACTN platforms. From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components (with PCE being one of them). Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts and eavesdropping of communication between different ACTN components. 😭 [RFC8453] further states that all protocols used to realize the ACTN framework should have rich security features, and customer, application, and network data should be stored in encrypted data stores. When PCEP is used as an ACTN interface, the security of PCEP provided by Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is used. 🔥
As per [RFC8453], regarding the MPI, a PKI-based mechanism is suggested, such as building a TLS or HTTPS connection between the MDSC and PNCs, to ensure trust between the physical network layer control components and the MDSC. Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted), should also be authenticated, and specific access restrictions and topology views should be configurable and/or policy based. When PCEP is used in MPI, the security functions, as per [RFC8253], are used to fulfill these requirements. 🌸
As per [RFC8453], regarding the CMI, suitable authentication and authorization of each CNC connecting to the MDSC will be required. If PCEP is used in CMI, the security functions, as per [RFC8253], can be used to support peer authentication, message encryption, and integrity checks. 💜
8. References 📚
8.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[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, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
8.2. Informative References 📚✨
okay so this is the bonus reading list, bestie 🧚 every one of these is a work or RFC that helps you go deeper on PCE, GMPLS, and TE. Drafts marked "Work in Progress" are still moving, so check their current status before you rely on them 💅
[ASSOC-POLICY] Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., and M. Negi, "Path Computation Element communication Protocol extension for associating Policies and LSPs", Work in Progress, draft-ietf-pce-association-policy-05, February 2019.
[EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng, H., and Y. Lee, "Experimental Validation of the ACTN architecture for flexi-grid optical networks using Active Stateful Hierarchical PCEs", 19th International Conference on Transparent Optical Networks (ICTON), DOI 10.5281/zenodo.832904, July 2017, <https://zenodo.org/record/832904>. 🔥
[PCE-HPCE] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE).", Work in Progress, draft-ietf-pce-stateful-hpce-10, June 2019.
[PCE-INTER-AREA] King, D. and H. Zheng, "Applicability of the Path Computation Element to Interarea and Inter-AS MPLS and GMPLS Traffic Engineering", Work in Progress, draft-ietf-pce-inter-area-as-applicability-07, December 2018. 🌸
[PCE-INTERDOMAIN] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Extension for Stateful Interdomain Tunnels", Work in Progress, draft-dugeon-pce-stateful-interdomain-02, March 2019.
[PCE-STATE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, draft-litkowski-pce-state-sync-05, March 2019. 🦋
[PCEP-LS] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", Work in Progress, draft-dhodylee-pce-pcep-ls-13, February 2019.
[PCEP-OPTICAL] Lee, Y., Zheng, H., Ceccarelli, D., Wang, W., Park, P., and B. Yoon, "PCEP Extension for Distribution of Link-State and TE information for Optical Networks", Work in Progress, draft-lee-pce-pcep-ls-optical-07, March 2019.
[PCEP-VN] Lee, Y., Zhang, X., and D. Ceccarelli, "Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks", Work in Progress, draft-leedhody-pce-vn-association-08, June 2019. 💜
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>. 🌈
[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, DOI 10.17487/RFC5212, July 2008, <https://www.rfc-editor.org/info/rfc5212>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>. ⭐
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>. 🍓
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. 🔐
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>. 🧠
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>. 🎀
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, <https://www.rfc-editor.org/info/rfc8454>. 👑
Appendix A. Additional Information 🎀
okay the paper [EXP] is the main event here 🔥 it shows the ACTN architecture being used to control a multidomain flexi-grid optical network, and it does that by proposing, adopting, and extending a few things:
- the Hierarchical active stateful PCE architectures and protocols
- the PCEP protocol to support efficient and incremental link-state topological reporting, known as PCEP-LS
- the per-link partitioning of the optical spectrum based on variable-sized allocated frequency slots enabling network sharing and virtualization
- the use of a model-based interface to dynamically request the instantiation of virtual networks for specific clients/tenants
The design and implementation of the test bed are reported in order to validate the approach. 🧪✨
Acknowledgments 🫶
The authors would like to thank Jonathan Hardwick for the inspiration behind this document. Further thanks to Avantika for her comments with suggested text. 💖
Thanks to Adrian Farrel and Daniel King for their substantial reviews. 🙌
Thanks to Yingzhen Qu for RTGDIR review. 🌸
Thanks to Rifaat Shekh-Yusef for SECDIR review. 🦋
Thanks to Meral Shirazipour for GENART review. 🧚
Thanks to Roman Danyliw and Barry Leiba for IESG review comments. 💅
Thanks to Deborah Brungard for being the responsible AD. 👑
Authors' Addresses 💌
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Email: dhruv.ietf@gmail.com
Young Lee Futurewei Technologies 5340 Legacy Drive, Suite 173 Plano, TX 75024 United States of America
Email: younglee.tx@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden
Email: daniele.ceccarelli@ericsson.com
That's the whole RFC, bestie! 🌈💖 The ACTN crew really did all that. Slay. 💅
📦 where this page comes from
- ietf: rfc8637 2019-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms