--- 1/draft-ietf-teas-pce-central-control-02.txt 2017-06-15 04:13:36.801501090 -0700 +++ 2/draft-ietf-teas-pce-central-control-03.txt 2017-06-15 04:13:36.857502417 -0700 @@ -1,23 +1,23 @@ TEAS Working Group A. Farrel, Ed. Internet-Draft Juniper Networks Intended status: Informational Q. Zhao, Ed. -Expires: November 15, 2017 R. Li +Expires: December 17, 2017 R. Li Huawei Technologies C. Zhou Cisco Systems - May 14, 2017 + June 15, 2017 An Architecture for Use of PCE and PCEP in a Network with Central Control - draft-ietf-teas-pce-central-control-02 + draft-ietf-teas-pce-central-control-03 Abstract The Path Computation Element (PCE) has become established as a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network for any definition of "optimal" and can also monitor changes in resource availability and traffic demands to update the paths. Conventionally, the PCE has been used to derive paths for MPLS Label @@ -29,40 +29,43 @@ engineered networks, and the PCE may be used to determine paths in a wide range of use cases including static LSPs, segment routing, service function chaining (SFC), and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for - the protocol. This document does not describe the use cases in - detail and does not define protocol extensions: that work is left for - other documents. + the protocol. A PCE-based central controller can simplify the + processing of distributed control plane by blending it with elements + of SDN and without necessarily completely replacing it. + + This document does not describe use cases in detail and does not + define protocol extensions: that work is left for other documents. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 November 15, 2017. + This Internet-Draft will expire on December 17, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,43 +75,44 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7 2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8 2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9 - 2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 10 - 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.1. Technology-Oriented Applicability . . . . . . . . . . . . 12 - 3.1.1. Applicability to Control Plane Operated Networks . . 12 - 3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 12 - 3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 13 - 3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 13 - 3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 13 - 3.1.6. Service Function Chaining . . . . . . . . . . . . . . 14 - 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 14 - 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 14 - 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 15 - 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 15 - 4. Protocol Implications / Guidance for Solution Developers . . 16 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 6. Manageability Considerations . . . . . . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 10.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12 + 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14 + 3.1.1. Applicability to Control Plane Operated Networks . . 14 + 3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14 + 3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15 + 3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15 + 3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15 + 3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16 + + 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16 + 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16 + 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17 + 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17 + 4. Protocol Implications / Guidance for Solution Developers . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 6. Manageability Considerations . . . . . . . . . . . . . . . . 19 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Path Computation Element (PCE) [RFC4655] was developed to offload path computation function from routers in an MPLS traffic engineered network. Since then, the role and function of the PCE has grown to cover a number of other uses (such as GMPLS [RFC7025]) and to allow delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use of network resources [I-D.ietf-pce-pce-initiated-lsp]. @@ -141,23 +145,26 @@ static LSPs, segment routing [I-D.ietf-spring-segment-routing], service function chaining (SFC) [RFC7665], and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the - protocol. This document does not describe the use cases in detail - and does not define protocol extensions: that work is left for other - documents. + protocol. A PCE-based central controller can simplify the processing + of distributed control plane by blending it with elements of SDN and + without necessarily completely replacing it. + + This document does not describe use cases in detail and does not + define protocol extensions: that work is left for other documents. 2. Architecture The architecture for the use of PCE within centralized control of a network is based on the understanding that a PCE can determine how connections should be placed and how resources should be used within the network, and that the PCE can then cause those connections to be established. Figure 1 shows how this control relationship works in a network with an active control plane. This is a familiar view for those who have read and understood [RFC4655] and @@ -348,40 +355,31 @@ | NE | | NE | | NE | :: | NE | | NE | | NE | ---- ---- ---- :: ---- ---- ---- :: Domain 1 :: Domain 2 :: Figure 4: Multiple Controllers on a Partitioned Network 2.1.2. Multiple Parallel Controllers + Multiple controllers may be deployed where each controller is capable + of controlling all of the network elements. Thus the failure of any + one controller will not leave the network unmanageable and, in normal + circumstances, the load can be distributed across the controllers. + Multiple parallel controllers may be deployed as shown in Figure 5. Each controller is capable of controlling all of the network elements thus the failure of any one controller will not leave the network unmanageable and, in normal circumstances, the load can be - distributed across the controllers. - - To achieve full redundancy and to be able to continue to provide full - function in the event of the failure a controller, the controllers - must synchronize with each other. This is nominally a simple task if - there are just two controllers, but can actually be quite complex if - state changes in the network are not to be lost. Furthermore, if - there are more than two controllers, the synchronization between - controllers can become a hard problem. - - Synchronization issues are often off-loaded as "database - synchronization" problems because distributed database packages have - already had to address these challenges. In networking the problem - may also be addressed by collecting the state from the network - (effectively using the network as a database) using normal routing - protocols such as OSPF, IS-IS, and BGP. + distributed across the controllers. In this model, the orchestrator + (or any requester) must select a controller to consume its request. -------------------------------------------- | Orchestrator / Service Manager / OSS / NMS | -------------------------------------------- ^ ^ | ___________________ | | | Synchronization | | v v v v ------------ ------------ | | ----- | | @@ -394,23 +392,76 @@ | |__:___ \___:_ \_:___ : | ....: | .....: | ..: | : | : | : | : | : v v v v v v v v ---- ---- ---- ---- | NE | | NE | | NE | | NE | ---- ---- ---- ---- Figure 5: Multiple Redundant Controllers + An alternate approach is to present the controllers as a "cluster" + that represents itself externally as a single controller as in + Figure 3 but which is actually comprised of multiple controllers. + The size of the cluster may be varied according to load in the manner + of network functions virtualization (NFV) and the cluster is + responsible for sharing load among the members of the cluster. This + approach is shown in Figure 6. + + -------------------------------------------- + | Orchestrator / Service Manager / OSS / NMS | + -------------------------------------------- + ^ + | + --------------------------+------------------------- + | Controller ______________|_____________ | + | Cluster | | | + | | ___________________ | | + | | | Synchronization | | | + | v v v v | + | ------------ ----- ------------ | + | | PCE-based |<---| TED |--->| PCE-based | | + | | Controller | ----- | Controller | | + | | Instance | | Instance | | + | ------------ ------------ | + | ^ ^ | + | |____________________________| | + | | | + --------------------------+------------------------- + _____________|_____________ + | | | | + v v v v + ---- ---- ---- ---- + | NE | | NE | | NE | | NE | + ---- ---- ---- ---- + + Figure 6: Multiple Controllers Presented as a Cluster + + To achieve full redundancy and to be able to continue to provide full + function in the event of the failure a controller, the controllers + must synchronize with each other. This is nominally a simple task if + there are just two controllers, but can actually be quite complex if + state changes in the network are not to be lost. Furthermore, if + there are more than two controllers, the synchronization between + controllers can become a hard problem. + + Synchronization issues are often off-loaded as "database + synchronization" problems because distributed database packages have + already had to address these challenges, or by using a shared + database. In networking the problem may also be addressed by + collecting the state from the network (effectively using the network + as a database) using normal routing protocols such as OSPF, IS-IS, + and BGP. + 2.1.3. Hierarchical Controllers - Figure 6 shows an approach with hierarchical controllers. This + Figure 7 shows an approach with hierarchical controllers. This approach was developed for PCEs in [RFC6805] and appears in various SDN architectures where a "parent PCE", an "orchestrator", or "super controller" takes responsibility for a high-level view of the network before distributing tasks to lower level PCEs or controllers. On its own, this approach does little to protect against the failure of a controller, but it can make significant improvements in loading and scaling of the individual controllers. It also offers a good way to support end-to-end connectivity across multiple administrative or technology-specific domains. @@ -445,21 +496,21 @@ / | | :: | | \ | | | :: | | | v v v :: v v v ---- ---- ---- :: ---- ---- ---- | NE | | NE | | NE | :: | NE | | NE | | NE | ---- ---- ---- :: ---- ---- ---- :: Domain 1 :: Domain 2 :: - Figure 6: Hierarchical Controllers + Figure 7: Hierarchical Controllers 3. Applicability This section gives a very high-level introduction to the applicability of a PCE-based centralized controller. There is no attempt to explain each use case in detail, and the inclusion of a use case is not intended to suggest that deploying a PCE-based controller is a mandatory or recommended approach. The sections below are provided as a stimulus to discussion of the applicability of a PCE-based controller and it is expected that separate documents @@ -492,33 +543,32 @@ determines what LSPs are needed and where to place them. PCEP is used to instruct the head end of each LSP, and the head end signals in the control plane to set up the LSP. 3.1.2. Static LSPs in MPLS Static LSPs are provisioned without the use of a control plane. This means that they are established using management plane or "manual" configuration. - Static LSPs can be provisioned as 1-hop, micro-LSPs at each node - along the path of an end-to-end path LSP. Each router along the path - must be told what label forwarding instructions to program and what - resources to reserve. The PCE-based controller keeps a view of the - network and determines the paths of the end-to-end LSPs just as it - does for the use case described in Section 3.1.1, but the controller - uses PCEP to communicate with each router along the path of the end- - to-end LSP. In this case the PCE-based controller will take - responsibility for managing some part of the MPLS label space for - each of the routers that it controls, and may taker wider - responsibility for partitioning the label space for each router and - allocating different parts for different uses communicating the - ranges to the router using PCEP. + Static LSPs can be provisioned as explicit label instructions at each + hop on the end-to-end path LSP. Each router along the path must be + told what label forwarding instructions to program and what resources + to reserve. The PCE-based controller keeps a view of the network and + determines the paths of the end-to-end LSPs just as it does for the + use case described in Section 3.1.1, but the controller uses PCEP to + communicate with each router along the path of the end-to-end LSP. + In this case the PCE-based controller will take responsibility for + managing some part of the MPLS label space for each of the routers + that it controls, and may taker wider responsibility for partitioning + the label space for each router and allocating different parts for + different uses communicating the ranges to the router using PCEP. 3.1.3. MPLS Multicast Multicast LSPs may be provisioned with a control plane or as static LSPs. No extra considerations apply above those in Section 3.1.1 and Section 3.1.2 except, of course, to note that the PCE must also include the instructions about where the LSP branches, i.e., where packets must be copied. 3.1.4. Transport SDN @@ -782,46 +832,49 @@ involved for opening the discussion. The individuals concerned are: King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li. This document has benefited from the discussions within a small ad hoc design team the members of which are listed as document contributors. Thanks to Michael Scharf and Andy Malis for a lively discussion of this document. + Thanks to Phil Bedard and Aijun Wang for last call comments on this + document. + 10. References 10.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, . 10.2. Informative References [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-09 (work in progress), March 2017. [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure - Transport for PCEP", draft-ietf-pce-pceps-12 (work in - progress), April 2017. + Transport for PCEP", draft-ietf-pce-pceps-14 (work in + progress), May 2017. [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- - pce-18 (work in progress), December 2016. + pce-19 (work in progress), May 2017. [I-D.ietf-pce-wson-rwa-ext] Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06 (work in progress), December 2016. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-11 (work in progress), February