Hierarchy of IP Controllers (HIC)Huawei TechnologiesHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comFuturewei TechnologiesBostonMAUSAhuaimo.chen@futurewei.com
Routing
TEAS Working GroupHIC
This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the
Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with other protocols
like BGP, Path Computation Element Communication Protocol (PCEP) to provide end to end dynamic services spanning multiple domains and controllers (e.g. Layer 3 Virtual Private Network (L3VPN), Seamless MPLS etc).
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. The Application-Based Network Operation (ABNO)
describes how various components and technologies fit together.
A domain is any collection of network
elements within a common sphere of address management or path
computation responsibility. Specifically, within this document,
it means a part of an operator's network that is under common
management. Network elements will often be grouped into
domains based on technology types, vendor profiles, and
geographic proximity and under a domain controller.
Multiple such domains in the network are interconnected, and a path
is established through a series of connected domains to form an end-to-end
path over which various services are offered. Each domain is under the
control of the domain controller (or lower-level controller), and a "super controller" (or high-level controller)
takes responsibility for a high-level view of the network before distributing tasks to domain controllers (or lower-level controllers).
It is possible for each of the domain to use a different tunnelling mechanism (eg RSVP-TE, Segment Routing (SR) etc).
describes the framework for
Abstraction and Control of Traffic Engineered Networks (ACTN) as well as a set of management and control functions
used to operate multiple TE networks. This documents would apply the ACTN principles to the Hierarchy of IP controllers (HIC)
and focus on the applicability and interactions with other protocols and technologies (specific to IP packet domains).
Sometimes, service (such as Layer 3 Virtual Private Network (L3VPN), Layer 2 Virtual Private Network (L2VPN), Ethernet VPN (EVPN), Seamless MPLS) require sites attached to different
domains (under the control of different domain controller) to be interconnected as part of the VPN
service. This requires multi-domain coordination between domain controllers to compute and set-up
an E2E path for the VPN service.
This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the
Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with control plane protocols
(like BGP, Path Computation Element Communication Protocol (PCEP)) and management plane aspects (Yang models) to provide end to end dynamic services spanning multiple domains and controllers (e.g. L3VPN, Seamless MPLS, etc.).
show examples of multi-domain IP domains under the hierarchy of IP controllers.
The IP "Super Controller" receives a request from the network/service orchestrator to set-up dynamic services spanning multiple domains. The IP "Super Controller" breaks down and assigns tasks to the domain controllers, responsible for communicating to network devices in the domain. It further coordinates between the controller to provide a unified view of the multi-domain network.
As per , ACTN has following the main functions -
Multi-domain coordinationVirtualization/AbstractionCustomer mapping/translationVirtual service coordinationThese functions are part of Multi-Domain Service Coordinator (MDSC) and/or Provisioning Network Controller (PNC). Further, these functions are part of the controller/orchestrator.The HIC is an instantiation of the ACTN framework for the IP packet network. The IP domain (lower-level) controllers implement the PNC functionalities for configuring, controlling, and monitoring the IP domain. The "super controller" (high-level controller) implements the MDSC functionalities for coordination between multiple domains as well as maintaining an abstracted view of multiple domains. It also takes care of the service-related functionalities of the customer-mapping/translation and virtual service coordination.The ACTN functions are part of the IP controllers and responsible for the TE topology and E2E path computation/set-up. There are other functions along with ACTN that are needed to manage multiple IP domain networks.The interaction between super controller and the domain controllers in HIC is a combination of Control Plane and Management Plane interface as shown in .
BGP and PCEP are example of the control plane interface; whereas NETCONF and RESTCONF
are examples of the management plane interface.
Note that ACTN's MDSC-PNC Interface (MPI) could be implemented via management plane interface using Yang models or via PCEP control plane interface
.The Domain Controller is expected to be aware of the topology of the network devices in its domain. The domain controller could participate in the IGP ( and ) or use
BGP-LS by which link-state and TE information is collected and shared with the domain controller using the BGP routing protocol. An alternate approach would be to rely on the management plane interface which uses the YANG model for network/TE Topology as per and .The domain controller is expected to share the domain topology to the Super Controller, as per ACTN (where PNC abstract the topology towards MDSC). A level of abstraction is usually applied while presenting the topology to a higher-level controller. Topology abstraction is described in as well as . BGP-LS, PCEP-LS or management plane interface based on the abstracted network/TE Topology could be used to carry the abstract topology to the super-controller. At minimum, the border nodes and inter-domain links are exposed to the super-controller. Further defines three types of topology abstraction - (1) Native/White Topology; (2) Black Topology; and (3) Grey Topology. Based on the local policy, the domain controller would share the domain topology to the Super Controller based on the abstraction type. Note that any of the control plane or management plane mechanism could be used to carry abstracted domain topology. The Super Controller's MDSC function is expected to manage a E2E topology by coordinating the abstracted domain topology received from the domain controllers.The Domain Controller is responsible for computing and setup of path when the source and destination are in the same domain, otherwise the Super Controller coordinates the multi-domain path computation and setup with the help of the domain controller. This is aligned to ACTN.PCEP provides mechanisms for Path Computation Elements (PCEs) to
perform path computations in response to Path Computation Clients
(PCCs) requests. Since then, the role and function of the PCE has grown to allow
delegated control and PCE-initiated use of network
resources .Further, and describes a hierarchy of
PCE with Parent PCE coordinating multi-domain path computation function between Child PCE(s). This fits well
with HIC as described in this document.Note that a management plane interface which uses the YANG model for path computation/setup ( and ) could be used in place of PCEP.In case there is a need to stitch per domain tunnels into an E2E tunnel, mechanism are described in . describes the concept of route-reflection where a "route reflector" (RR) reflects the routes to avoid full mesh connection between Internal BGP (IBGP) peers. The IP domain
controller can play the role of RR in its domain. The super controller can further act as RR to towards the domain controller.BGP can provide routing policies for traffic management, like
route preference, AS-path filter policy, IP-prefix filter policy and
route aggregation. The controller can distribute these BGP policies into the
routers in a single IP domain. For the scenario of multiple domains,
the super controller can distribute per BGP Policy into each IP domain
controller. Then the IP domain controller trickles down the BGP Policy
to the network devices. describes the concept of BGP Flowspec that
can be used to distribute traffic flow specifications. A flow
specification is an n-tuple consisting of several matching criteria
that can be applied to IP traffic. The controller can originate the flow specifications and disseminate it to the routers. The flow action includes the redirection to a specific TE tunnel. Also, the IP domain controller could be
responsible for collecting the flow sample in its domain and the super
controller can act as the Flow Analysis Server. describes the BGP Monitoring Protocol
(BMP) to monitor BGP sessions. BMP is used to obtain route views
with a flexible way. In the fashion of hierarchical architecture, the
IP domain controller can be used as the domain Monitoring Station.
Meanwhile, the super controller is responsible for a high-level view
of the global network state.Seamless MPLS
describes an architecture which can be used to extend MPLS networks to
integrate access and core/aggregation networks into a single MPLS
domain.In the
seamless MPLS for mobile backhaul, since there are multiple domains
including the core network and multiple mobile backhaul networks,
for each domain there is a domain controller. In order
to implement the end-to-end network service provision, there should be
coordination among multiple domain controllers.Super Controller is responsible for setting the seamless MPLS service. It should break down the service model to network configuration model and the domain controller further break it to the device configuration model to the PE/ASBR to make the E2E seamless MPLS service. The selection of appropriate ASBRs and handling of intra-domain tunnels is coordinated by the Super Controller in a similar fashion as shown in .By enabling BGP sessions between Domain Controller and Super Controller, BGP labeled routes can also be learned at Super Controller. As Super Controller is aware of the (abstract) topology, it could make intelligent decisions regarding E2E BGP LSP to optimize based on the overall traffic information.
A Layer 3 IP VPN service is a collection of sites that are authorized
to exchange traffic between each other over a shared IP
infrastructure. provides a framework for Layer 3 Provider-Provisioned
Virtual Private Networks (PPVPNs). provides a L3VPN
service delivery YANG model for PE-based VPNs. The Super controller is expected to implement the L3SM model
and translate it to network models towards the domain controller, which in turn translate it to the device model.
See for more details.
Based on the user data in the L3SM model, the network configurations need to be trickle down to the network device to set up the L3VPN. describes the need for a YANG model for use between the entity that
interacts directly with the customer (service orchestrator) and the
entity in charge of network orchestration and control which,
according to , can be referred to as Service Delivery
Model. The resulting model is called the L3VPN Network
Model (L3NM).Based on the QoS or Policy requirement for the L3VPN service, the Super Controller may -
Set the tunnel selection policy at the PE/ASBR routers so that they could select the existing tunnelsSelect an existing tunnel at the controller level and bind it to the VPN serviceInitiate the process of creating a new tunnel based on the QoS requirement and bind it to the VPN serviceInitiate the process of creating a new tunnel based on the policyRefer for more details from ACTN perspective.Apart from the Management plane interface based on respective YANG models, the control plane interface PCEP could be used for path computation and setup. There are two fundamentally different kinds of Layer 2 VPN service
that a service provider could offer to a customer: Virtual Private
Wire Service (VPWS) and Virtual Private LAN Service (VPLS) .
A VPWS is a VPN service that supplies an L2 point-to-point service.
A VPLS is an L2 service that emulates LAN service across a Wide Area
Network (WAN). A BGP MPLS-based Ethernet VPN (EVPN) addresses
some of the limitations when it
comes to multihoming and redundancy, multicast optimization,
provisioning simplicity, flow-based load balancing, and multipathing, etc.
The handling of L2VPN/EVPN service is done in a similar fashion as shown in .This sections list some of the possible features or protocol extensions that could be worked on to deploy HIC in a multi-domain packet network.
Simplify the initial configurations needed to set-up the relationship between the super controller and the domain controllers. Note that
this could be done via exchanges during initial session establishment, discovery via other protocols, service discovery (such as DNS etc.).The (higher-level controller, lower-level controller) relationship or the role of the controller. The learning and handling of various capabilities of the Super Controller and Domain Controller. Handling of multiple instances of the controller at each level for high availability.[Editor's Note - This list is expected to be updated in the next version with more details]The Path Computation Element communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains have been identified as a key motivation for PCE
development.A stateful PCE is capable of considering, for the purposes of
path computation, not only the network state in terms of links and
nodes (referred to as the Traffic Engineering Database or TED) but
also the status of active services (previously computed paths,
and currently reserved resources, stored in the Label Switched
Paths Database (LSPDB). describes general considerations for
a stateful PCE deployment and examines its applicability and
benefits, as well as its challenges and limitations through a number
of use cases. describes a set of extensions to PCEP to
provide stateful control. A stateful PCE has access to not only the
information carried by the network's Interior Gateway Protocol (IGP),
but also the set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute
constrained paths while considering individual LSPs and their
interactions. describes the setup,
maintenance and teardown of PCE-initiated LSPs under the stateful PCE
model. 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.Computing paths across large multi-domain environments
require special computational components and cooperation between
entities in different domains capable of complex path computation.
The PCE provides an architecture and a set of functional components
to address this problem space. A PCE may be used to compute
end-to-end paths across multi-domain
environments using a per-domain path computation technique .
The Backward recursive PCE based path computation (BRPC) mechanism
defines a PCE-based path computation procedure to compute
inter-domain constrained MPLS and
GMPLS TE networks. However,
both per-domain and BRPC techniques assume that the sequence of
domains to be crossed from source to destination is known, either
fixed by the network operator or obtained by other means. describes a Hierarchical PCE (H-PCE)
architecture which can be used for computing end-to-end paths for
inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched
Paths (LSPs) when the domain sequence is not known.
Within the Hierarchical PCE (H-PCE) architecture,
the Parent PCE (P-PCE) is used to compute a multi-domain
path based on the domain connectivity information. A Child PCE
(C-PCE) may be responsible for a single domain or multiple domains,
it is used to compute the intra-domain path based on its domain
topology information. state the considerations for stateful PCE(s) in
hierarchical PCE architecture. In particular, the behaviour changes
and additions to the existing stateful PCE mechanisms (including PCE-
initiated LSP set-up and active PCE usage) in the context of networks
using the H-PCE architecture. examines the applicability of PCE/PCEP to the ACTN
framework in detail. introduces the architecture for PCE as a central controller
as an extension of the architecture described in and
assumes the continued use of PCEP as the protocol used between PCE
and PCC. Some related extension to PCEP and are also applicable in HIC. describes a mechanism by which link-state and TE
information can be collected from networks and shared with external
components using the BGP routing protocol. This is
achieved using a new BGP Network Layer Reachability Information
(NLRI) encoding format and a new BGP path attribute (BGP-LS
attribute) that carries link, node, and prefix
parameters and attributes.BGP-LS is another approach to collect
network topology information. It is an extension to BGP for
distribution of the network's link-state (LS) topology to external
entities, such as the SDN controller. Network's link-state topology
consists of nodes and links and a set of attributes.
The link-state topology is distributed among
the IGP domain. The specific protocol used in an IGP domain could be OSPF
or IS-IS . Note that, the
detailed link-state models of these two protocols are not identical.
Therefore, BGP-LS can provide a more abstract topology model that
can map the IGP models.The domain controller acts as a consumer to collect the domain's link-state and TE information via BGP-LS. The domain controller would usually abstract the domain information towards the super-controller and further send it via BGP-LS. BGP-Flowspec is a solution devised for preventing distributed
Denial-of-service (DDoS) attack. BGP-Flowspec distributes
specification rules into neighbours. defines a new BGP NLRI
encoding format that can be used to distribute traffic flow
specifications. Additionally, it defines two applications of that
encoding format: one that can be used to automate inter-domain
coordination of traffic filtering, such as what is required in order
to mitigate DDoS attacks; and a second application to provide
traffic filtering in the context of BGP/MPLS VPN service.The IP domain controller can act as the traffic sampling node.
The super controller can act as the traffic analysis server. When
the super controller finds the attack happened, the super controller
should distribute the flow rules to associated IP domain
controllers. And each IP domain controller should distribute the
flow rules into the ingress routers. Additionally one of the actions taken could be "redirect" where flow could be redirected to the TE tunnels created by the controller. describes
the traffic steering based on BGP controller. The traditional method
for traffic steering depends on the static configuration which is
time-consuming and inefficient. With the hierarchical IP controller, the
IP domain controller can have the domain network topology view and
routing information while the super controller can have the global
network topology view and routing information. The super controller
can compute the end-to-end paths to satisfy the differentiated
service requirement. The IP domain controller may be used to
distribute the routing policy into the routers. BGP policy varies in
many aspects. Its goal is to meet the customer application and
connectivity requirement, and specific service transport needs. So
the super BGP controller is responsible for the coordination of
multiple domain BGP Policy. And then distribute Policy to the related IP
domain controller. The IP domain controller is responsible for
distributing the policy to its network nodes. describes the
route target (RT) constrain mechanism in the hierarchical route
reflection (RR) scenario. describes the
route-target constrain mechanism to build a route distribution graph
in order to restrict the propagation of Virtual Private Network
(VPN) routes.
proposes a solution to address the RT constrain issue in the
hierarchical RR scenarios. The super controller corresponding to
higher level RR can receive the RT-constrain routes from the lower
level RR, which is acted by the IP domain controller. The higher
level RR will select one of the received routes as the best route.
then it should advertise the best route to all the lower level RR to
build the route distribution graph. This fits well with the HIC as
described in this document.This is a non-exhaustive list of possible yang models developed or in-development that could be used for HIC.
Topology: defines a generic YANG data model for
network topology. defines a YANG data model for representing, retrieving
and manipulating Traffic Engineering (TE) Topologies. Tunnel: defines a YANG data model for the configuration and
management of Traffic Engineering (TE) interfaces, tunnels and Label
Switched Paths (LSPs).L3VPN: The Layer 3 service model (L3SM) is defined in , which is a YANG data model that can be used for
communication between customers and network operators and to deliver
a Layer 3 provider-provisioned VPN service. defines a YANG data model that can be used to configure
and manage BGP Layer 3 VPNs at the device. Note that a network configuration model at the Domain Controller level needs to be developed.L2VPN/EVPN: defines a YANG data model that can be used to configure
a Layer 2 Provider-Provisioned VPN service. This model is intended to be instantiated at the management system to
deliver the overall service. and defines a YANG data model to
configure and manage L2VPN and EVPN service respectively. Note that a network configuration model at the Domain Controller level needs to be developed.OAM: TBDBGP Policy: defines a
YANG data model that can be used to configure BGP Policy based
on data centre, carrier and content provider operational
requirements. The model is intended to be vendor-neutral, in
order to allow operators to manage BGP configuration in
heterogeneous environments with routers supplied by multiple
vendors. Note that a network configuration model at the Domain
Controller level needs to be developed.BGP Flowspec:
defines a YANG data model for Flow Specification
implementations. The configuration data is described as flow
specification rules that can be distributed as BGP NLRI to a
network element. The rules can be used to filter Distributed
Denial of Service attacks (DDoS) besides other use cases. Note
that a network configuration model at the Domain Controller
level needs to be developed. provides a framework that describes and discusses an
architecture for service and network management automation that takes
advantage of YANG modeling technologies. This is quite apt for HIC and includes interactions between multiple YANG models as described in .[Editor's Note - the above list should be extended.]The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the
configuration of network devices. The RESTCONF describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the
datastore concepts defined in NETCONF. Some other mechanism like gRPC/gNMI could also be used between controllers using the same YANG data models.There are no IANA concerns in this document.There are no new security concerns in this document.
Intermediate system to Intermediate system routing information
exchange protocol for use in conjunction with the Protocol for
providing the Connectionless-mode Network Service (ISO
8473)
ISO