Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 8454 Huawei
Category: Informational S. Belotti
ISSN: 2070-1721 Nokia
D. Dhody
Huawei
D. Ceccarelli
Ericsson
B. Yoon
ETRI
September 2018
Information Model for Abstraction and Control of TE Networks (ACTN)
Abstract
This document provides an information model for Abstraction and
Control of TE Networks (ACTN).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8454.
Lee, et al. Informational [Page 1]
RFC 8454 ACTN Info Model September 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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.
This document provides an information model for Abstraction and
Control of TE Networks (ACTN). The information model described in
this document covers the interface requirements identified in the
ACTN Framework document [RFC8453].
The ACTN reference architecture [RFC8453] identifies a three-tier
control hierarchy comprising the following as depicted in Figure 1:
o Customer Network Controllers (CNCs)
o Multi-Domain Service Coordinator (MDSC)
o Provisioning Network Controllers (PNCs)
The two interfaces with respect to the MDSC, one north of the MDSC
and the other south of the MDSC, are referred to as "CMI" (CNC-MDSC
Interface) and "MPI" (MDSC-PNC Interface), respectively. This
document models these two interfaces and derivative interfaces
thereof (e.g., MDSC-to-MDSC in a hierarchy of MDSCs) as a single
common interface.
1.1. Terminology
The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)"
are defined in [RFC8453]. Other key terms and concepts, for example,
"abstraction", can be found in [RFC7926].
Lee, et al. Informational [Page 4]
RFC 8454 ACTN Info Model September 2018
2. ACTN Common Interfaces Information Model
This section provides an ACTN common interface information model to
describe primitives, objects, their properties (represented as
attributes), their relationships, and the resources for the service
applications needed in the ACTN context.
The standard interface is described between a client controller and a
server controller. A client-server relationship is recursive between
a CNC and an MDSC and between an MDSC and a PNC. In the CMI, the
client is a CNC while the server is an MDSC. In the MPI, the client
is an MDSC and the server is a PNC. There may also be MDSC-MDSC
interfaces that need to be supported. This may arise in a hierarchy
of MDSCs in which workloads may need to be partitioned to multiple
MDSCs.
Basic primitives (messages) are required between the CNC-MDSC and
MDSC-PNC controllers. These primitives can then be used to support
different ACTN network control functions like network topology
requests/queries, VN service requests, path computation and
connection control, VN service policy negotiation, enforcement,
routing options, etc.
There are two different types of primitives depending on the type of
interface:
o Virtual Network primitives at CMI
o Traffic Engineering primitives at MPI
As well described in [RFC8453], at the CMI level, there is no need
for detailed TE information since the basic functionality is to
translate customer service information into VNS operation.
At the MPI level, MDSC has the main scope for multi-domain
coordination and creation of a single end-to-end (E2E) abstracted
network view that is strictly related to TE information.
As for topology, this document employs two types of topology.
o The first type is referred to as "virtual network topology" and is
associated with a VN. Virtual network topology is a customized
topology for view and control by the customer. See Section 3.1
for details.
o The second type is referred to as "TE topology" and is associated
with provider network operation on which we can apply policy to
obtain the required level of abstraction to represent the
underlying physical network topology.
Lee, et al. Informational [Page 5]
RFC 8454 ACTN Info Model September 2018
3. Virtual Network Primitives
This section provides a list of main VN primitives related to VNs and
that are necessary to satisfy the ACTN requirements specified in
[ACTN-REQ].
The following VN Action primitives are supported:
o VN Instantiate
o VN Modify
o VN Delete
o VN Update
o VN Path Compute
o VN Query
VN Action is an object describing the main VN primitives.
VN Action can assume one of the mentioned above primitives values.
::= |
|
|
|
|
All these actions will solely happen at CMI level between CNC and
MDSC.
Lee, et al. Informational [Page 6]
RFC 8454 ACTN Info Model September 2018
3.1. VN Instantiate
VN Instantiate refers to an action from customers/applications to
request the creation of VNs. VN Instantiate is for CNC-to-MDSC
communication. Depending on the agreement between client and
provider, VN instantiate can imply different VN operations. There
are two types of VN instantiation:
VN Type 1: VN is viewed as a set of edge-to-edge links (VN members).
VN Type 2: VN is viewed as a VN-topology comprising virtual nodes
and virtual links.
Please see [RFC8453] for full details regarding the types of VN.
3.2. VN Modify
VN Modify refers to an action issued from customers/applications to
modify an existing VN (i.e., an instantiated VN). VN Modify is for
CNC-to-MDSC communication.
VN Modify, depending of the type of VN instantiated, can be:
1. a modification of the characteristics of VN members (edge-to-edge
links) in the case of VN Type 1, or
2. a modification of an existing virtual topology (e.g., adding/
deleting virtual nodes/links) in the case of VN Type 2.
3.3. VN Delete
VN Delete refers to an action issued from customers/applications to
delete an existing VN. VN Delete is for CNC-to-MDSC communication.
3.4. VN Update
"VN Update" refers to any update to the VN that needs to be updated
to the customers. VN Update is MDSC-to-CNC communication. VN Update
fulfills a push model at the CMI level, making customers aware of any
specific changes in the topology details related to the instantiated
VN.
VN Update, depending of the type of VN instantiated, can be:
1. an update of VN members (edge-to-edge links) in case of VN Type
1, or
2. an update of virtual topology in case of VN Type 2.
Lee, et al. Informational [Page 7]
RFC 8454 ACTN Info Model September 2018
The connection-related information (e.g., Label Switched Paths
(LSPs)) update association with VNs will be part of the "translation"
function that happens in MDSC to map/translate VN request into TE
semantics. This information will be provided in case the customer
optionally wants to have more-detailed TE information associated with
the instantiated VN.
3.5. VN Compute
VN Compute consists of a Request and Reply. "VN Compute Request"
refers to an action from customers/applications to request a VN
computation.
"VN Compute Reply" refers to the reply in response to VN Compute
Request.
A VN Compute Request/Reply is to be differentiated from a VN
Instantiate. The purpose of VN Compute is a priori exploration to
compute network resources availability and getting a possible VN view
in which path details can be specified matching customer/applications
constraints. This a priori exploration may not guarantee the
availability of the computed network resources at the time of
instantiation.
3.6. VN Query
"VN Query" refers to an inquiry pertaining to a VN that has already
been instantiated. VN Query fulfills a pull model that permits
getting a topology view.
"VN Query Reply" refers to the reply in response to a VN Query. The
topology view returned by a VN Query Reply would be consistent with
the topology type instantiated for any specific VN.
4. TE Primitives
This section provides a list of the main TE primitives necessary to
satisfy ACTN requirements specified in [ACTN-REQ] related to typical
TE operations supported at the MPI level.
The TE action primitives defined in this section should be supported
at the MPI consistently with the type of topology defined at the CMI.
Lee, et al. Informational [Page 8]
RFC 8454 ACTN Info Model September 2018
The following TE action primitives are supported:
o TE Instantiate/Modify/Delete
o TE Topology Update (see Section 4.4. for the description)
o Path Compute
TE Action is an object describing the main TE primitives.
TE Action can assume one of the mentioned above primitives values.
::= |
|
|
|
|
All these actions will solely happen at MPI level between MDSC and
PNC.
4.1. TE Instantiate
"TE Instantiate" refers to an action issued from MDSC to PNC to
instantiate new TE tunnels.
4.2. TE Modify
"TE Modify" refers to an action issued from MDSC to PNC to modify
existing TE tunnels.
4.3. TE Delete
"TE Delete" refers to an action issued from MDSC to PNC to delete
existing TE tunnels.
4.4. TE Topology Update (for TE Resources)
TE Topology Update is a primitive specifically related to MPI used to
provide a TE resource update between any domain controller and MDSC
regarding the entire content of any actual TE topology of a domain
controller or an abstracted filtered view of TE topology depending on
negotiated policy.
See [TE-TOPO] for detailed YANG implementation of TE topology update.
Lee, et al. Informational [Page 9]
RFC 8454 ACTN Info Model September 2018
::=
::= []
::= [] list> ::= []
::=
::= [ Termination Point-list>]
::= []
Where
Abstraction provides information on the level of abstraction (as
determined a priori).
TE-topology-identifier is an identifier that identifies a specific
te-topology, e.g., te-types:te-topology-id [TE-TOPO].
Node-list is detailed information related to a specific node
belonging to a te-topology, e.g., te-node-attributes [TE-TOPO].
Link-list is information related to the specific link related
belonging to a te-topology, e.g., te-link-attributes [TE-TOPO].
TE Termination Point-list is detailed information associated with the
termination points of a te-link related to a specific node, e.g.,
interface-switching-capability [TE-TOPO].
4.5. Path Compute
Path Compute consists of Request and Reply. "Path Compute Request"
refers to an action from MDSC to PNC to request a path computation.
"Path Compute Reply" refers to the reply in response to the Path
Compute Request.
The context of Path Compute is described in [Path-Compute].
5. VN Objects
This section provides a list of objects associated to VN action
primitives.
Lee, et al. Informational [Page 10]
RFC 8454 ACTN Info Model September 2018
5.1. VN Identifier
A VN Identifier is a unique identifier of the VN.
5.2. VN Service Characteristics
VN Service Characteristics describes the customer/application
requirements against the VNs to be instantiated.
::=
(...)
Where
::= |||| destination>
The Connectivity Type identifies the type of required VN Service. In
addition to the classical types of services (e.g., P2P/P2MP, etc.),
ACTN defines the "multi-destination" service that is a new P2P
service where the endpoints are not fixed. They can be chosen among
a list of preconfigured endpoints or dynamically provided by the CNC.
VN Directionality indicates if a VN is unidirectional or
bidirectional. This implies that each VN member that belongs to the
VN has the same directionality as the VN.
::=
[]
The VN Traffic Matrix represents the traffic matrix parameters for
the required service connectivity. Bandwidth is a mandatory
parameter, and a number of optional constraints can be specified in
the VN Constraints (e.g., diversity, cost). They can include
objective functions and TE metric bounds as specified in [RFC5541].
Further details on the VN constraints are specified below:
::= []
[]
( | )
Lee, et al. Informational [Page 11]
RFC 8454 ACTN Info Model September 2018
Where:
Layer Protocol identifies the layer topology at which the VN
service is requested. It could be, for example, MPLS, Optical
Data Unit (ODU), and Optical Channel (OCh).
Diversity allows asking for diversity constraints for a VN
Instantiate/Modify or a VN Path Compute. For example, a new VN or
a path is requested in total diversity from an existing one (e.g.,
diversity exclusion).
::= ( (...)) |
( (...))
Metric can include all the Metrics (cost, delay, delay variation,
latency) and bandwidth utilization parameters defined and
referenced by [RFC3630] and [RFC7471].
As for VN Objective Function, see Section 5.4.
VN Survivability describes all attributes related to the VN recovery
level and its survivability policy enforced by the customers/
applications.
::=
[]
[]
Where:
VN Recovery Level is a value representing the requested level
of resiliency required against the VN. The following values
are defined:
o Unprotected VN
o VN with per tunnel recovery: The recovery level is defined
against the tunnels composing the VN, and it is specified in
the VN Tunnel Recovery Level.
::= <0:1>|<1+1>|<1:1>|<1:N>||
The VN Tunnel Recovery Level indicates the type of protection
or restoration mechanism applied to the VN. It augments the
recovery types defined in [RFC4427].
Lee, et al. Informational [Page 12]
RFC 8454 ACTN Info Model September 2018
::= []
[]
[]
[]
Where:
Local Reroute Allowed is a delegation policy to the Server on
whether or not to allow a local reroute fix upon a failure of
the primary LSP.
Domain Preference is only applied on the MPI where the MDSC
(client) provides a domain preference to each PNC (server),
e.g., when an inter-domain link fails, then PNC can choose the
alternative peering with this info.
Push Allowed is a policy that allows a server to trigger an
updated VN topology upon failure without an explicit request
from the client. Push action can be set as default unless
otherwise specified.
Incremental Update is another policy that triggers an
incremental update from the server since the last period of
update. Incremental update can be set as default unless
otherwise specified.
5.3. VN Endpoint
VN End-Point Object describes the VN's customer endpoint
characteristics.