--- 1/draft-ietf-pce-applicability-actn-05.txt 2018-06-17 22:13:08.325212431 -0700 +++ 2/draft-ietf-pce-applicability-actn-06.txt 2018-06-17 22:13:08.365213413 -0700 @@ -1,21 +1,21 @@ PCE Working Group D. Dhody Internet-Draft Y. Lee Intended status: Informational Huawei Technologies -Expires: September 6, 2018 D. Ceccarelli +Expires: December 19, 2018 D. Ceccarelli Ericsson - March 5, 2018 + June 17, 2018 Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN) - draft-ietf-pce-applicability-actn-05 + draft-ietf-pce-applicability-actn-06 Abstract Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 6, 2018. + This Internet-Draft will expire on December 19, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -57,37 +57,37 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 1.1.2. PCE in multi-domain and multi-layer deployments . . . 4 - 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 4 - 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 6 - 2. Architectural Considerations . . . . . . . . . . . . . . . . 6 - 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6 - 2.2. Virtualization/Abstraction function . . . . . . . . . . . 7 - 2.3. Customer mapping function . . . . . . . . . . . . . . . . 8 - 2.4. Virtual Network Operations . . . . . . . . . . . . . . . 9 - 3. Interface Considerations . . . . . . . . . . . . . . . . . . 9 - 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 10 - 5. Relationship to PCE based central control . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 1.1.3. Relationship to PCE based central control . . . . . . 4 + 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 + 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7 + 2. Architectural Considerations . . . . . . . . . . . . . . . . 7 + 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7 + 2.2. Abstraction function . . . . . . . . . . . . . . . . . . 8 + 2.3. Customer mapping function . . . . . . . . . . . . . . . . 9 + 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 + 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 + 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Path Computation Element (PCE) The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to perform path computations in response to Path Computation Clients (PCCs) requests. @@ -116,24 +116,24 @@ interactions. [RFC8281] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model. [RFC8231] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or a PCC to delegate control of specific LSPs to a new PCE. 1.1.1. Role of PCE in SDN - Software-Defined Networking (SDN) refers to a separation between the - control elements and the forwarding components so that software - running in a centralized system called a controller, can act to - program the devices in the network to behave in specific ways. A + Software-Defined Networking (SDN) [RFC7149] refers to a separation + between the control elements and the forwarding components so that + software running in a centralized system called a controller, can act + to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place flows within the network given knowledge of the availability of network resources, how other forwarding devices are programmed, and the way that other flows are routed. It is concluded in [RFC7399], that this is the same function that a PCE might offer in a network operated using a dynamic control plane. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system including SDN is @@ -168,43 +168,52 @@ [I-D.ietf-pce-stateful-hpce] state the considerations for stateful PCE(s) in hierarchical PCE architecture. In particular, the behavior changes and additions to the existing stateful PCE mechanisms (including PCE- initiated LSP setup and active PCE usage) in the context of networks using the H-PCE architecture. [RFC5623] describes a framework for applying the PCE-based architecture to inter-layer to (G)MPLS TE. It provides suggestions for the deployment of PCE in support of multi-layer networks. It also describes the relationship between PCE and a functional - component in charge of the control and management of the VNT, called - the Virtual Network Topology Manager (VNTM). + component in charge of the control and management of the Virtual + Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM). + +1.1.3. Relationship to PCE based central control + + [RFC8283] introduces the architecture for PCE as a central controller + (PCECC), it further examines the motivations and applicability for + PCEP as a southbound interface, and introduces the implications for + the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy + of PCE-based controller as per the Hierarchy of PCE framework defined + in [RFC6805]. 1.2. Abstraction and Control of TE Networks (ACTN) [I-D.ietf-teas-actn-requirements] describes the high-level ACTN requirements. [I-D.ietf-teas-actn-framework] describes the architecture model for ACTN including the entities (Customer Network Controller(CNC), Multi-domain Service Coordinator(MDSC), and Provisioning Network Controller (PNC) and their interfaces. The ACTN reference architecture identified a three-tier control hierarchy as depicted in Figure 1: +---------+ +---------+ +---------+ | CNC | | CNC | | CNC | +---------+ +---------+ +---------+ \ | / - Business \ | / + \ | / Boundary =============\==============|==============/============ Between \ | / Customer & ------- | CMI ------- - Network Provider \ | / + Network Operator \ | / +---------------+ | MDSC | +---------------+ / | \ ------------ | MPI ------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | SBI / | / \ @@ -233,44 +242,47 @@ ACTN interfaces. 1.3. PCE and ACTN This document examines the PCE and ACTN architecture and describes how the PCE architecture is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface. This document also identifies any gaps in PCEP, that exist at the time of publication of this document. + Further, ACTN, Stateful H-PCE, and PCECC are based on the same basic + hierarchy framework and thus compatible with each other. + 2. Architectural Considerations ACTN [I-D.ietf-teas-actn-framework] architecture is based on hierarchy and recursiveness of controllers. It defines three types of controllers (depending on the functionalities they implement). The main functionalities are - o Multi domain coordination function - o Virtualization/Abstraction function + o Abstraction function o Customer mapping/translation function o Virtual service coordination function Section 3 of [I-D.ietf-teas-actn-framework] describes these functions. It should be noted that, this document lists all possible ways in which PCEP could be used for each of the above functions, but all functions are not required to be implemented via PCEP. Operator may choose to use the PCEP for multi domain coordination via stateful H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the - topology and support virtualization/abstraction function. + topology and support abstraction function. 2.1. Multi domain coordination via Hierarchy With the definition of domain being "everything that is under the control of the single logical controller", as per [I-D.ietf-teas-actn-framework], it is needed to have a control entity that oversees the specific aspects of the different domains and to build a single abstracted end-to-end network topology in order to coordinate end-to-end path computation and path/service provisioning. @@ -291,21 +303,21 @@ coordination function. This includes domain sequence selection; E2E path computation; Controller (PCE) initiated path setup and reporting. This is also applicable to multi-layer coordination in case of IP+optical networks. [I-D.litkowski-pce-state-sync]" describes the procedures to allow a stateful communication between PCEs for various use-cases. The procedures and extensions are also applicable to Child and Parent PCE communication and thus useful for ACTN as well. -2.2. Virtualization/Abstraction function +2.2. Abstraction function To realize ACTN, an abstracted view of the underlying network resources needs to be built. This includes global network-wide abstracted topology based on the underlying network resources of each domain. This also include abstract topology created as per the customer service connectivity requests and represented as a network slice allocated to each customer. In order to compute and provide optimal paths, PCEs require an accurate and timely Traffic Engineering Database (TED). @@ -324,33 +336,33 @@ [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning and maintaining the Link-State and TE information as an alternative to IGPs and BGP flooding, using PCEP itself. The child PCE can use this mechanism to transport Link-State and TE information from child PCE to a Parent PCE using PCEP. In ACTN, there is a need to control the level of abstraction based on the deployment scenario and business relationship between the controllers. The mechanism used to disseminate information from PNC (child PCE) to MDSC (parent PCE) should support abstraction. - [I-D.lee-teas-actn-abstraction] describes a few alternative - approaches of abstraction. The resulting abstracted topology can be - encoded using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and - its optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS - is an attractive option when the operator would wish to have a single + [I-D.ietf-teas-actn-framework] describes a few alternative approaches + of abstraction. The resulting abstracted topology can be encoded + using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and its + optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is + an attractive option when the operator would wish to have a single control plane protocol (PCEP) to achieve ACTN functions. [I-D.ietf-teas-actn-framework] discusses two ways to build abstract topology from an MDSC standpoint with interaction with PNCs. The - primary method is called authomatic generation of abstract topology - by configuration. with this method, automatic generation is based on + primary method is called automatic generation of abstract topology by + configuration. With this method, automatic generation is based on the abstraction/summarization of the whole domain by the PNC and its - advertisement on the MPI. The seconday method is called on-demand + advertisement on the MPI. The secondary method is called on-demand generation of supplementary topology via Path Compute Request/Reply. This method may be needed to obtain further complementary information such as potential connectivity from child PCEs in order to facilitate an end-to-end path provisioning. PCEP is well suited to support both methods. 2.3. Customer mapping function In ACTN, there is a need to map customer virtual network (VN) requirements into network provisioning request to the PNC. That is, @@ -373,21 +385,21 @@ child PCE further propagates the initiate request to the LSR. The customer request is received by the MDSC (parent PCE) and based on the business logic, global abstracted topology, network conditions and local policy, the MDSC (parent PCE) translates this into 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 peer [I-D.ietf-pce-association-policy] can be used. -2.4. Virtual Network Operations +2.4. Virtual Service Coordination Virtual service coordination function in ACTN incorporates customer service-related information into the virtual network service operations in order to seamlessly operate virtual networks while meeting customer's service requirements. [I-D.leedhody-pce-vn-association] describes the need for associating a set of LSPs with a VN "construct" to facilitate VN operations in PCE architecture. This association allows the PCEs to identify which LSPs belong to a certain VN. @@ -402,21 +414,21 @@ considered for all the LSPs belonging to a VN/customer and optimize them all together. 3. Interface Considerations As per [I-D.ietf-teas-actn-framework], to allow virtualization and multi domain coordination, the network has to provide open, programmable interfaces, in which customer applications can create, replace and modify virtual network resources and services in an interactive, flexible and dynamic fashion while having no impact on - other customers. The 3 ACTN interfaces are - + other customers. The two ACTN interfaces are - o The CNC-MDSC Interface (CMI) is an interface between a Customer Network Controller and a Multi Domain Service Coordinator. It requests the creation of the network resources, topology or services for the applications. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller. o The MDSC-PNC Interface (MPI) is an interface between a Multi Domain Service Coordinator and a Provisioning Network Controller. @@ -503,21 +516,21 @@ o VN Instantiate: MDSC is requested to instantiate a VN, the minimal information that is required would be 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 considered as a set of paths belonging to the same VN. As described in Section 2.4 and [I-D.leedhody-pce-vn-association] the VN association can help in identifying the set of paths that belong to a VN. The rest of the information like the endpoints, constraints and objective function - is already defined in PCEP in terms of a single path. + (OF) is already defined in PCEP in terms of a single path. * Path Computation: As per the example in the Figure 2, the VN instantiate requires two end to end paths between (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. MDSC can do path computation based on the abstracted domain topology that it already has or it may use the H-PCE procedures (Section 2.1) using the PCReq and PCRep messages to get the end to end path with the help of the child PCEs (PNC). Either way, the resulted E2E paths may be broken @@ -579,65 +592,66 @@ o In case PNC generates an abstract topology to the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links. PNC would need to take that as an input for path computation to get a path with physical nodes and links. Similarly PNC would convert the path received from the device (with physical nodes and links) into abstract path (based on the abstract topology generated before with abstract nodes and links) and reported to the MDSC. -5. Relationship to PCE based central control - - [RFC8283] introduces the architecture for PCE as a central controller - (PCECC), it further examines the motivations and applicability for - PCEP as a southbound interface, and introduces the implications for - the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy - of PCE-based controller as per the Hierarchy of PCE framework defined - in [RFC6805]. Both ACTN and PCECC is based on the same basic - framework and thus compatible with each other. - -6. IANA Considerations +5. IANA Considerations This is an informational document and thus does not have any IANA allocations to be made. -7. Security Considerations +6. Security Considerations The ACTN framework described in [I-D.ietf-teas-actn-framework] defines key components and interfaces for managed traffic engineered networks. It also list various security considerations such as request and control of resources, confidentially of the information, and availability of function which should be taken into consideration. When PCEP is used on the MPI, this interface needs to be secured, use of [RFC8253] is RECOMENDED. Each PCEP extension listed in this document, presents its individual security considerations, which continue to apply. -8. Acknowledgments +7. 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. -9. References +8. References -9.1. Normative References +8.1. Normative References [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . -9.2. Informative References + [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, + . + + [I-D.ietf-teas-actn-framework] + Ceccarelli, D. and Y. Lee, "Framework for Abstraction and + Control of Traffic Engineered Networks", draft-ietf-teas- + actn-framework-15 (work in progress), May 2018. + +8.2. Informative References [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [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, . @@ -646,20 +660,26 @@ Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [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, . + [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, + . + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [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, . [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, @@ -667,25 +687,24 @@ Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, . [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, . - [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, - . + [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, + . [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, . [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, . @@ -734,30 +753,25 @@ and O. Dios, "Hierarchical Stateful Path Computation Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in progress), March 2018. [I-D.ietf-teas-actn-requirements] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, "Requirements for Abstraction and Control of TE Networks", draft-ietf-teas-actn-requirements-09 (work in progress), March 2018. - [I-D.ietf-teas-actn-framework] - Ceccarelli, D. and Y. Lee, "Framework for Abstraction and - Control of Traffic Engineered Networks", draft-ietf-teas- - actn-framework-11 (work in progress), October 2017. - [I-D.ietf-teas-actn-info-model] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE - Networks (ACTN)", draft-ietf-teas-actn-info-model-07 (work - in progress), February 2018. + Networks (ACTN)", draft-ietf-teas-actn-info-model-09 (work + in progress), June 2018. [I-D.ietf-pce-inter-area-as-applicability] King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and O. Dios, "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- applicability-06 (work in progress), July 2016. [I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for @@ -773,36 +787,30 @@ [I-D.leedhody-pce-vn-association] Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP Extensions for Establishing Relationships Between Sets of LSPs and Virtual Networks", draft-leedhody-pce-vn- association-04 (work in progress), February 2018. [I-D.litkowski-pce-state-sync] Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Stateful Path Computation Element communication - procedures", draft-litkowski-pce-state-sync-02 (work in - progress), August 2017. + procedures", draft-litkowski-pce-state-sync-03 (work in + progress), April 2018. [I-D.ietf-pce-association-policy] Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and J. Hardwick, "Path Computation Element communication Protocol extension for associating Policies and LSPs", draft-ietf-pce-association-policy-02 (work in progress), February 2018. - [I-D.lee-teas-actn-abstraction] - Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios, - "Abstraction and Control of TE Networks (ACTN) Abstraction - Methods", draft-lee-teas-actn-abstraction-02 (work in - progress), June 2017. - [I-D.lee-pce-lsp-stitching-hpce] Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions for Stitching LSPs in Hierarchical Stateful PCE Model", draft-lee-pce-lsp-stitching-hpce-01 (work in progress), December 2017. Authors' Addresses Dhruv Dhody Huawei Technologies