--- 1/draft-ietf-teas-pce-central-control-00.txt 2016-12-05 06:13:25.505162843 -0800 +++ 2/draft-ietf-teas-pce-central-control-01.txt 2016-12-05 06:13:25.553164067 -0800 @@ -1,42 +1,42 @@ TEAS Working Group A. Farrel, Ed. Internet-Draft Juniper Networks Intended status: Informational Q. Zhao, Ed. -Expires: March 5, 2017 R. Li +Expires: June 8, 2017 R. Li Huawei Technologies C. Zhou Cisco Systems - September 1, 2016 + December 5, 2016 An Architecture for Use of PCE and PCEP in a Network with Central Control - draft-ietf-teas-pce-central-control-00 + draft-ietf-teas-pce-central-control-01 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 Switched Paths (LSPs). These paths are supplied using the Path Computation Element Communication Protocol (PCEP) to the head end of the LSP for signaling in the MPLS network. SDN has a far broader applicability than just signaled MPLS traffic 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 + 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. @@ -48,21 +48,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 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 March 5, 2017. + This Internet-Draft will expire on June 8, 2017. Copyright Notice Copyright (c) 2016 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 @@ -107,55 +107,56 @@ 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]. According to [RFC7399], 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 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. 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 - presented in [RFC7491]. + 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 traffic 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. This is the function and purpose of a + PCE, and the way that a PCE integrates into a wider network control + system (including an SDN system) is presented in [RFC7491]. In early PCE implementations, where the PCE was used to derive paths for MPLS Label Switched Paths (LSPs), paths were requested by network - elements and the results of the path computations were supplied to - network elements using the Path Computation Element Communication - Protocol (PCEP) [RFC5440]. This protocol was later extended to allow - a PCE to send unsolicited requests to the network for LSP - establishment [I-D.ietf-pce-pce-initiated-lsp]. + elements (known as Path Computation Clients - PCCs) and the results + of the path computations were supplied to network elements using the + Path Computation Element Communication Protocol (PCEP) [RFC5440]. + This protocol was later extended to allow a PCE to send unsolicited + requests to the network for LSP establishment + [I-D.ietf-pce-pce-initiated-lsp]. SDN has a far broader applicability than just signaled MPLS or GMPLS traffic engineered networks. The PCE component in an SDN system may be used to determine paths in a wide range of use cases including 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 + 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 dos not describe the use cases in detail and - does not define protocol extensions: that work is left for other + protocol. This document does not describe the 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 @@ -197,21 +198,21 @@ Figure 1: Architecture for Central Controller with Control Plane Although the architecture shown in Figure 1 represents a form of SDN, one objective of SDN in some environments is to remove the dependency on a control plane. A transition architecture toward this goal is presented in [RFC7491] and is shown in Figure 2. In this case, services are still requested in the same way, and the PCE-based controller still requests use of the network using PCEP. The main difference is that the consumer of the PCEP messages is a Network Controller that provisions the resources and instructs the data plane - using Southbound Interface (SBI) that provides an interface to each + using a Southbound Interface (SBI) that provides an interface to each NE. -------------------------------------------- | Orchestrator / Service Manager / OSS / NMS | -------------------------------------------- ^ | v ------------ | | ----- @@ -284,21 +285,21 @@ ^ ---- ---- ^ :......>| NE |...| NE |<....: Control Plane ---- ---- Figure 3: Architecture for Node-by-Node Central Control 2.1. Resilience and Scaling Systems with central controllers are vulnerable to two problems: failure or overload of the single controller. These concerns are not - unique to the use of a PCE-based controller but need to be addressed + unique to the use of a PCE-based controller, but need to be addressed in this document before the PCE-based controller architecture can be considered for use in all but the smallest networks. There are three architectural mechanisms that can be applied to address these issues. The mechanisms are described separately for clarity, but a deployment use may any combination of the approaches. For simplicity of illustration, these three approaches are shown in the sections that follow without a control plane. However, the general, hybrid approach of Figure 3 is applicable in each case. @@ -325,25 +326,25 @@ -------------------------------------------- | Orchestrator / Service Manager / OSS / NMS | -------------------------------------------- ^ ^ | | v v ------------ Coord- ------------ ----- | | ination | | ----- | TED |--->| PCE-based |<-------->| PCE-based |<---| TED | ----- | Controller | | Controller | ----- - | | | | - /------------ ------------\ - / ^ ^ ^ ^ \ - / | | | | \ - | | | | | | + | | :: | | + /------------ :: ------------\ + / ^ ^ :: ^ ^ \ + / | | :: | | \ + | | | :: | | | v v v :: v v v ---- ---- ---- :: ---- ---- ---- | NE | | NE | | NE | :: | NE | | NE | | NE | ---- ---- ---- :: ---- ---- ---- :: Domain 1 :: Domain 2 :: Figure 4: Multiple Controllers on a Partitioned Network @@ -380,21 +381,21 @@ ------------ ------------ | | ----- | | | PCE-based |<---| TED |--->| PCE-based | | Controller | ----- | Controller | | |__ ...........| | ------------\ \_:__ :------------ ^ ^ \___: \ .....: ^ ^ | | .....:\ \_:___ ..: : | |__:___ \___:_ \_:___ : | ....: | .....: | ..: | : - | : | : | : + | : | : | : | : v v v v v v v v ---- ---- ---- ---- | NE | | NE | | NE | | NE | ---- ---- ---- ---- Figure 5: Multiple Redundant Controllers 2.1.3. Hierarchical Controllers Figure 6 shows an approach with hierarchical controllers. This @@ -402,48 +403,48 @@ 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. - Note that this model can be arbitrarily recursive with one PCE-based - controller acting as the parent of of another set of PCE-based - controllers. + Note that this model can be arbitrarily recursive with a PCE-based + controller being the child of one parent PCE-based controller while + acting as the parent of another set of PCE-based controllers. -------------------------------------------- | Orchestrator / Service Manager / OSS / NMS | -------------------------------------------- ^ | v ------------ | Parent | ----- | PCE-based |<---| TED | | Controller | ----- | | ------------ ^ ^ | | - v v - ------------ ------------ - ----- | | | | ----- - | TED |--->| PCE-based | | PCE-based |<---| TED | - ----- | Controller | | Controller | ----- - /| | | |\ - / ------------ ------------ \ - / ^ ^ ^ ^ \ - / | | | | \ - / | | | | \ + v :: v + ------------ :: ------------ + ----- | | :: | | ----- + | TED |--->| PCE-based | :: | PCE-based |<---| TED | + ----- | Controller | :: | Controller | ----- + /| | :: | |\ + / ------------ :: ------------ \ + / ^ ^ :: ^ ^ \ + / | | :: | | \ + / | | :: | | \ | | | :: | | | v v v :: v v v ---- ---- ---- :: ---- ---- ---- | NE | | NE | | NE | :: | NE | | NE | | NE | ---- ---- ---- :: ---- ---- ---- :: Domain 1 :: Domain 2 :: Figure 6: Hierarchical Controllers @@ -529,49 +530,50 @@ and may have point-to-point or point-to-multipoint connections. Thus, all of the considerations in Section 3.1.1, Section 3.1.2, and Section 3.1.3 apply. It may be the case that additional technology- specific parameters are needed to configure the NEs and these parameters will need to be carried in the PCEP messages. 3.1.5. Segment Routing Segment routing is described in [I-D.ietf-spring-segment-routing]. It relies on a series of forwarding instructions being placed in the - header or a packet: at each hop in the network a router looks at the - first instruction and may continue to forward the packet unchanged, - strip the top instruction and forward the packet, or strip the top + header or a packet. At each hop in the network a router looks at the + first instruction and may: continue to forward the packet unchanged; + strip the top instruction and forward the packet; or strip the top instruction, insert some additional instructions, and forward the packet. The segment routing architecture supports operations that can be used to steer packet flows in a network thus providing a form of traffic engineering. A PCE-based controller can be responsible for computing the paths for packet flows in a segment routing network, for configuring the forwarding actions on the routers, and for telling the edge routers what instructions to attach to packets as they enter the network. These last two operations can be achieved using PCEP and the PCE-based controller will assume responsibility for managing the space of labels or path identifiers used to determine how packets are forwarded. 3.1.6. Service Function Chaining Service Function Chaining (SFC) is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the - traffic. The set of functions to be performed and the locations at - which they are to be performed is known as service function chain. - Each packet is marked as belonging to a specific chain and that - marking lets each successive service function node know which - functions to perform and to which service function node to send the - packet next. + traffic. The set of functions to be performed and the order in which + they are to be performed is known as a Service Function Chain. The + chain is enhanced with the locations at which the service functions + are to be performed to derive a Service Function Path (SFP). Each + packet is marked as belonging to a specific SFP and that marking lets + each successive service function node know which functions to perform + and to which service function node to send the packet next. To operate an SFC network the service function nodes must be configured to understand the packet markings and the edge nodes must be told how to mark packets entering the network. Additionally it may be necessary to establish tunnels between service function nodes to carry the traffic. Planning an SFC network requires load balancing between service function nodes and traffic engineering across the network that connects them. These are operations that can be performed by a PCE- @@ -609,22 +611,23 @@ 3.2.2. Traffic Classification Traffic classification is an important part of traffic engineering. It is the process of looking at a packet to determine how it should be treated as it is forwarded through the network. It applies in many scenarios including MPLS traffic engineering (where it determines what traffic is forwarded onto which LSPs), segment routing (where it is used to select which set of forwarding instructions to add to a packet), and service function chaining - (where it indicates along which service function chain a packet - should be forwarded). + (where it indicates along which service function path a packet should + be forwarded). In conjunction with traffic engineering, traffic + classification is an important enabler for load balancing. Traffic classification is closely linked to the computational elements of planning for the network functions just listed because it determines how traffic load is balanced and distributed through the network. Therefore, selecting what traffic classification should be performed by a router is an important part of the work done by a PCE- based controller. Instructions can be passed from the controller to the routers using PCEP. These instructions tell the routers how to map traffic to @@ -642,26 +645,26 @@ Delivering services over a network in an optimal way requires coordination in the way that network resources are allocated to support the services. A PCE-based central controller can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources. 4. Protocol Implications - PCEP is push-pull protocol that is designed to move requests and - responses between a server (the PCE) and Path Computation Clients - (PCCs - the network elements). In particular, it has a message - (PCInitiate [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the - PCE to install state or cause actions at the PCC, and a response - message (PCRpt) that is used to confirm the request. + PCEP is a push-pull protocol that is designed to move requests and + responses between a server (the PCE) and clients (the PCCs, i.e., the + network elements). In particular, it has a message (PCInitiate + [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to + install state or cause actions at the PCC, and a response message + (PCRpt) that is used to confirm the request. As such, there is an expectation that only relatively minor changes to PCEP are required to support the concept of a PCE-based controller. The only work expected to be needed is small extensions to carry additional or specific information elements for the individual use cases. Where possible, consistent with the general principles of how protocols are extended, any additions to the protocol should be made in a generic way such that they are open to use in a range of applications. @@ -677,25 +680,25 @@ consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [I-D.ietf-pce-pceps]. It should be observed that the trust model of a network that operates with out a control plane is different from one with a control plane. The conventional "chain of trust" used with a control plane is replaced by individual trust relationships between the controller and each individual NE. This model may be considerably easier to manage and so is more likely to be operated with a high level of security. - However debate will rage over overall system security and the + However, debate will rage over overall system security and the opportunity for attacks in an architecture with a central controller since the network can be vulnerable to denial of service attacks on the controller, and the forwarding system may be harmed by attacks on - the messages sent to individual routers. In short, while the + the messages sent to individual NEs. In short, while the interactions with a PCE-based controller are not substantially different from those in any other SDN architecture, the security implications of SDN are still open for discussion. The IRTF's SDN Research Group (SDNRG) continues to discuss this topic. It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCE-based central controller on the network type and services being managed. @@ -775,46 +778,47 @@ progress), July 2016. [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", draft-ietf-pce-pceps-10 (work in progress), July 2016. [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-15 (work in progress), July 2016. + pce-18 (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-09 (work in progress), July 2016. + spring-segment-routing-10 (work in progress), November + 2016. [I-D.pkd-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. [I-D.zhao-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Dhody, D., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", draft-zhao-pce-pcep- extension-for-pce-controller-03 (work in progress), March 2016. [I-D.zhao-teas-pcecc-use-cases] Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, C., Communications, T., Rachitskiy, A., and A. Gulida, "The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use- - cases-01 (work in progress), July 2016. + cases-02 (work in progress), October 2016. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, . [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, . @@ -874,21 +878,21 @@ [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . Authors' Addresses Adrian Farrel (editor) Juniper Networks - Email: adrian@olddog.co.uk + Email: afarrel@juniper.net Quintin Zhao (editor) Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 USA Email: quintin.zhao@huawei.com Robin Li Huawei Technologies