RFC 8454

Information Model for Abstraction and Control of TE Networks (ACTN)

📅 published September 2018, from ietf

RFC 8454: Information Model for Abstraction and Control of TE Networks (ACTN) 🦋

  • RFC number: 8454
  • Stream: Internet Engineering Task Force (IETF)
  • Authors: Y. Lee (Huawei), S. Belotti (Nokia), D. Dhody (Huawei), D. Ceccarelli (Ericsson), B. Yoon (ETRI)
  • Category: Informational, so it's published for info, not as a standards-track spec 🌸
  • Date: September 2018
  • ISSN: 2070-1721
  • Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates ✨

Abstract

okay so bestie, this doc gives us an information model for Abstraction and Control of TE Networks (ACTN) 💖

Status of This Memo

this one is not an Internet Standards Track spec. it's published for informational purposes 🎀

this is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🧚

want the current status, errata, or a way to send feedback? check https://www.rfc-editor.org/info/rfc8454 🔥

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, because they spell out what you can and can't do with this doc 🙈

if you pull Code Components out of this doc, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. they come with no warranty, as the Simplified BSD License describes 💅

Table of Contents 📚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  ACTN Common Interfaces Information Model  . . . . . . . . . .   5
   3.  Virtual Network Primitives  . . . . . . . . . . . . . . . . .   6
     3.1.  VN Instantiate  . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  VN Modify . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  VN Delete . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  VN Update . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  VN Compute  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  VN Query  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  TE Primitives . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  TE Instantiate  . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  TE Modify . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  TE Delete . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  TE Topology Update (for TE Resources) . . . . . . . . . .   9
     4.5.  Path Compute  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  VN Objects  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  VN Identifier . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  VN Service Characteristics  . . . . . . . . . . . . . . .  11
     5.3.  VN Endpoint . . . . . . . . . . . . . . . . . . . . . . .  13
     5.4.  VN Objective Function . . . . . . . . . . . . . . . . . .  14
     5.5.  VN Action Status  . . . . . . . . . . . . . . . . . . . .  14
     5.6.  VN Topology . . . . . . . . . . . . . . . . . . . . . . .  15
     5.7.  VN Member . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.7.1.  VN Computed Path  . . . . . . . . . . . . . . . . . .  15
       5.7.2.  VN Service Preference . . . . . . . . . . . . . . . .  16
   6.  TE Objects  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  TE Tunnel Characteristics . . . . . . . . . . . . . . . .  17
   7.  Mapping of VN Primitives with VN Objects  . . . . . . . . . .  19
   8.  Mapping of TE Primitives with TE Objects  . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     11.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction ✨

okay so this doc gives us an information model for Abstraction and Control of TE Networks (ACTN). the model covers the interface requirements that were identified in the ACTN Framework document [RFC8453] 💅

the ACTN reference architecture [RFC8453] has a three-tier control hierarchy, which is shown in Figure 1: 🌸

  • Customer Network Controllers (CNCs)
  • Multi-Domain Service Coordinator (MDSC)
  • Provisioning Network Controllers (PNCs)
   +-------+                 +-------+                   +-------+
   | CNC-A |                 | CNC-B |                   | CNC-C |
   +-------+                 +-------+                   +-------+
        \                        |                          /
         ------------            | CMI         -------------
                     \           |            /
                      +----------------------+
                      |         MDSC         |
                      +----------------------+
                     /           |            \
         ------------            | MPI         -------------
        /                        |                          \
   +-------+                 +-------+                   +-------+
   |  PNC  |                 |  PNC  |                   |  PNC  |
   +-------+                 +-------+                   +-------+

               Figure 1: A Three-Tier ACTN Control Hierarchy

the two interfaces around the MDSC are the one north of it and the one south of it. they're called "CMI" (CNC-MDSC Interface) and "MPI" (MDSC-PNC Interface), respectively. this doc models both of these, plus their derivatives (like MDSC-to-MDSC in a hierarchy of MDSCs), as one 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, like "abstraction", can be found in [RFC7926] 🧚

2. ACTN Common Interfaces Information Model 👑

this section gives us an ACTN common interface information model. it describes primitives, objects, their properties (shown as attributes), how they relate to each other, and the resources that service applications need in the ACTN context 🎀

the standard interface sits between a client controller and a server controller. the client-server relationship is recursive, between a CNC and an MDSC and between an MDSC and a PNC. on the CMI, the client is a CNC and the server is an MDSC. on the MPI, the client is an MDSC and the server is a PNC. there may also be MDSC-MDSC interfaces that need support, which can happen in a hierarchy of MDSCs where workloads get split across multiple MDSCs 🫶

basic primitives (messages) are required between the CNC-MDSC and MDSC-PNC controllers. these primitives can then support different ACTN network control functions, like network topology requests and queries, VN service requests, path computation and connection control, VN service policy negotiation, enforcement, routing options, and so on 🔥

there are two types of primitives, depending on the type of interface: 🍓

  • Virtual Network primitives at CMI
  • Traffic Engineering primitives at MPI

as [RFC8453] describes really well, at the CMI level there's no need for detailed TE information. the basic job there is to translate customer service information into VNS operation 💖

at the MPI level, the MDSC is mainly in charge of multi-domain coordination and of building a single end-to-end (E2E) abstracted network view that's tightly tied to TE information 😭

as for topology, this doc uses two types 🌈

  • The first type is called "virtual network topology" and it's tied to a VN. this is a customized topology that the customer views and controls. see Section 3.1 for details 🦋
  • The second type is called "TE topology" and it's tied to provider network operation. policy can be applied to it to get the level of abstraction needed to represent the underlying physical network topology ⭐

3. Virtual Network Primitives 🎀

this section lists the main VN primitives. they relate to VNs and they're needed to satisfy the ACTN requirements specified in [ACTN-REQ] 💅

the following VN Action primitives are supported: 🌸

  • VN Instantiate
  • VN Modify
  • VN Delete
  • VN Update
  • VN Path Compute
  • VN Query

VN Action is an object that describes the main VN primitives 🧚

VN Action can take on one of the primitive values mentioned above 🦋

   <VN Action> ::= <VN Instantiate> |

                   <VN Modify> |

                   <VN Delete> |

                   <VN Update> |

                   <VN Path Compute> |

                   <VN Query>

all of these actions happen only at the CMI level, between a CNC and an MDSC 💜

3.1. VN Instantiate 🌷

VN Instantiate is an action where customers or applications ask for VNs to be created. it's for CNC-to-MDSC communication. depending on what the client and provider agreed to, VN instantiate can mean 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.

for the full details on the types of VN, see [RFC8453] 🫶

3.2. VN Modify 🍓

VN Modify is an action that customers or applications issue to change an existing VN (meaning one that's already instantiated). it's for CNC-to-MDSC communication 🔥

what VN Modify does depends on the type of VN that was instantiated. it 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 is an action that customers or applications issue to delete an existing VN. it's for CNC-to-MDSC communication 💖

3.4. VN Update 📬✨

Okay bestie, VN Update is any update to the VN that the customers need to know about 💌. It's MDSC-to-CNC communication, and it follows a push model at the CMI level, so customers get told about specific changes to the topology of an already instantiated VN 🫶.

What the update contains depends on the type of VN that was instantiated 🦋:

  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.

Connection-related info, like Label Switched Paths (LSPs), gets associated with VNs during the "translation" function in the MDSC, where the VN request gets mapped into TE semantics 🧩. That info only shows up if the customer optionally wants more-detailed TE information for the instantiated VN 💅.

3.5. VN Compute 🔍

VN Compute has two parts, a Request and a Reply 💖. A VN Compute Request is an action from customers or applications asking for a VN computation, and a VN Compute Reply is the response to that request ✨.

Don't mix this up with VN Instantiate! 🙈 VN Compute is a priori exploration. It checks network resource availability and gives you a possible VN view with path details that match the customer or application constraints. But this a priori exploration may not guarantee that those computed resources will still be available when you actually instantiate 💀.

3.6. VN Query 🪞

A VN Query is an inquiry about a VN that has already been instantiated 🌸. It's a pull model that lets you get a topology view 👀.

The VN Query Reply is the reply to a VN Query 💜. The topology view it returns will match the topology type that was instantiated for that specific VN, so no surprises 🎀.

4. TE Primitives ✨

This section lists the main TE primitives needed to meet the ACTN requirements in [ACTN-REQ], covering typical TE operations supported at the MPI level 🌈.

The TE action primitives in this section should be supported at the MPI, consistent with the type of topology defined at the CMI 🧠.

The following TE action primitives are supported 💅:

  • TE Instantiate/Modify/Delete
  • TE Topology Update (see Section 4.4. for the description)
  • Path Compute

A TE Action is an object describing the main TE primitives 🎀. A TE Action can take on one of the primitive values mentioned above 💖:

<TE Action> ::= <TE Instantiate> |

                <TE Modify> |

                <TE Delete> |

                <TE Topology Update> |
                <Path Compute> |

All of these actions happen only at the MPI level, between the MDSC and the PNC 🤝.

4.1. TE Instantiate 🌱

"TE Instantiate" is an action issued from the MDSC to the PNC to set up new TE tunnels 🚀.

4.2. TE Modify 🛠️

"TE Modify" is an action issued from the MDSC to the PNC to change existing TE tunnels ✨.

4.3. TE Delete 🗑️

"TE Delete" is an action issued from the MDSC to the PNC to delete existing TE tunnels 👋.

4.4. TE Topology Update (for TE Resources) 🗺️

TE Topology Update is a primitive specifically for the MPI. It's used to send a TE resource update between any domain controller and the MDSC, covering either the entire content of an actual TE topology of a domain controller, or an abstracted, filtered view of that TE topology, depending on the negotiated policy 🫶.

See [TE-TOPO] for the detailed YANG implementation of TE topology update 📚.

<TE Topology Update> ::= <TE-topology-list>

<TE-topology-list> ::= <TE-topology> [<TE-topology-list>]

<TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node-
list> <Link-list>
<Node-list> ::= <Node>[<Node-list>]

<Node> ::= <Node> <TE Termination Point-list>

<TE Termination Point-list> ::= <TE Termination Point> [<TE-
Termination Point-list>]

<Link-list> ::= <Link>[<Link-list>]

Where:

Abstraction gives info on the level of abstraction, which is determined a priori 🔎.

TE-topology-identifier is an identifier that picks out a specific te-topology, e.g., te-types:te-topology-id [TE-TOPO] 🏷️.

Node-list is detailed info about a specific node in a te-topology, e.g., te-node-attributes [TE-TOPO] 🧁.

Link-list is info about the specific link in a te-topology, e.g., te-link-attributes [TE-TOPO] 🔗.

TE Termination Point-list is detailed info about the termination points of a te-link on a specific node, e.g., interface-switching-capability [TE-TOPO] 🧷.

4.5. Path Compute 🧭

Path Compute has a Request and a Reply 💫. The Path Compute Request is an action from the MDSC to the PNC asking for a path computation 🙋‍♀️. The Path Compute Reply is the reply to that Path Compute Request 📨.

The context for Path Compute is described in [Path-Compute] 📖.

5. VN Objects 💎

This section lists the objects tied to the VN action primitives 🎀.

5.1. VN Identifier 🪪

A VN Identifier is a unique identifier for the VN 🔑.

5.2. VN Service Characteristics 💅

VN Service Characteristics describes the customer or application requirements for the VNs being instantiated 📋.

<VN Service Characteristics> ::= <VN Connectivity Type>

                                 <VN Directionality>

                                 (<VN Traffic Matrix>...)

                                 <VN Survivability>

Where:

<VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi-
destination>

The Connectivity Type identifies the kind of VN Service that's needed 🌐. Besides the classic service types (like P2P/P2MP, etc.), ACTN defines a "multi-destination" service 🦋. It's a new P2P service where the endpoints aren't fixed. They can be picked from a list of preconfigured endpoints, or the CNC can provide them dynamically ✨.

VN Directionality shows whether a VN is unidirectional or bidirectional ➡️⬅️. That means each VN member that belongs to the VN has the same directionality as the VN itself 💜.

<VN Traffic Matrix> ::= <Bandwidth>

                        [<VN Constraints>]

The VN Traffic Matrix holds the traffic matrix parameters for the required service connectivity 📊. Bandwidth is a mandatory parameter 🔥, and you can specify a bunch of optional constraints in the VN Constraints, like diversity and cost 🧁. Those can include objective functions and TE metric bounds, as specified in [RFC5541] 🌸.

Further details on the VN constraints are below 👇:

<VN Constraints> ::= [<Layer Protocol>]
                     [<Diversity>]

                     ( <Metric> | <VN Objective Function> )

Where:

Layer Protocol identifies the layer topology where the VN service is requested. For example, it could be MPLS, Optical Data Unit (ODU), or Optical Channel (OCh) 🧩.

Diversity lets you ask for diversity constraints for a VN Instantiate/Modify or a VN Path Compute 🌈. For example, a new VN or a path can be requested in total diversity from an existing one (e.g., diversity exclusion) 🙅‍♀️.

<Diversity> ::= (<VN-exclusion> (<VN-id>...)) |

                  (<VN-Member-exclusion> (<VN-Member-id>...))

Metric can include all the Metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471] 📏.

As for the VN Objective Function, see Section 5.4 🎯.

VN Survivability describes all the attributes related to the VN recovery level and its survivability policy, as enforced by the customers or applications 🛡️.

<VN Survivability> ::= <VN Recovery Level>

                       [<VN Tunnel Recovery Level>]

                       [<VN Survivability Policy>]

Where:

VN Recovery Level is a value representing the level of resiliency requested for the VN. The following values are defined 🔐:

  • Unprotected VN
  • VN with per tunnel recovery: The recovery level is defined against the tunnels that make up the VN, and it's specified in the VN Tunnel Recovery Level.
<VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>|
                     <On the fly restoration>

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] ✨.

<VN Survivability Policy> ::= [<Local Reroute Allowed>]

                              [<Domain Preference>]

                              [<Push Allowed>]

                              [<Incremental Update>]

Where:

Local Reroute Allowed is a delegation policy to the Server, deciding whether or not to allow a local reroute fix when the primary LSP fails 🛠️.

Domain Preference is only applied on the MPI, where the MDSC (client) gives each PNC (server) a domain preference. For example, when an inter-domain link fails, the PNC can use that info to choose an alternative peering 🤝.

Push Allowed is a policy that lets a server trigger an updated VN topology upon failure, without an explicit request from the client 📣. Push action can be set as the default unless otherwise specified 🌟.

Incremental Update is a policy that triggers an incremental update from the server since the last update period 📈. Incremental update can be set as the default unless otherwise specified 💜.

5.3. VN Endpoint 📍

The VN End-Point Object describes the VN's customer endpoint characteristics 🎀.

<VN End-Point> ::= (<Access Point Identifier>

                   [<Access Link Capability>]
                   [<Source Indicator>])...

Where:

Access Point Identifier is a unique identifier for the client endpoint 🪪. The customer uses these to ask for the setup of a virtual network instantiation. A VN End-Point is defined against each AP in the network and is shared between the customer and the provider. Both of them map it against their own physical resources 🤝.

Access Link Capability identifies the capabilities of the access link for a given access point (e.g., max-bandwidth, bandwidth availability, etc.) 🛣️.

Source Indicator shows whether or not an endpoint is the source 🎯.

5.4. VN Objective Function 🏆

The VN Objective Function applies to each VN member (that is, each E2E tunnel) of a VN 💖.

The VN Objective Function can reuse the objective functions defined in Section 4 of [RFC5541] ♻️.

For a single path computation, these objective functions are defined 🧭:

  • MCP is the Minimum Cost Path with respect to a specific metric (e.g., shortest path).
  • MLP is the Minimum Load Path, meaning it finds a path composed of the least loaded te-links 🪶.
  • MBP is the Maximum residual Bandwidth Path 🌊.

For a concurrent path computation, these objective functions are defined 🌈:

  • MBC is to Minimize aggregate Bandwidth Consumption 📉.
  • MLL is to Minimize the Load of the most loaded Link 🔥.
  • MCC is to Minimize the Cumulative Cost of a set of paths 💸.

5.5. VN Action Status ✨

okay so VN Action Status is basically the little "did it work?" indicator 🥺💅 It tells you whether a VN actually got instantiated, modified, or deleted in the server network after a particular VN action. Main character energy for a status flag, honestly.

Also, this action status object can be implicitly indicated, which means it might not show up in any of the VN primitives from Section 3. Not every message needs to spell it out 🙈

5.6. VN Topology 🗺️

When the customer sees a VN as a topology, we call it a "VN topology" 🦋 This goes with VN Type 2, which is built out of virtual nodes and virtual links.

<VN Topology> ::= <Virtual node list> <Virtual link list>

<Virtual node list> ::= <Virtual node> [<Virtual node list>]

<Virtual link list> :: = <Virtual link>  [<Virtual link list>]

5.7. VN Member 🫶

VN Member describes the details of a VN Member. You get a whole list of them, and that list is called VN_Member_List 💜

<VN_Member_List> ::= <VN Member> [<VN_Member_List>]

Where <VN Member> ::= <Ingress VN End-Point>

                      [<VN Associated LSP>]

                      <Egress VN End-Point>
  • Ingress VN End-Point is the VN End-Point info for the ingress side of the AP. Full details are in Section 5.3 🌸
  • Egress VN End-Point is the VN End-Point info for the egress side of the AP. Same deal, see Section 5.3 💅
  • VN Associated LSP describes the LSPs that got instantiated in the Provider's network. For VN Type 1 it's the LSPs in the provider's network, and for VN Type 2 it's the LSPs running over the VN topology ✨

5.7.1. VN Computed Path 🧭

The VN Computed Path is the list of paths you get back after a VN path computation request goes up to a higher controller. Important tea: the computed path is NOT the same thing as an LSP 🙅‍♀️ Once that computed path gets signaled in the network, and the resource is reserved for it, then it becomes an LSP. Glow-up arc 🦋

<VN Computed Path> ::= (<Path>...)

5.7.2. VN Service Preference 🎀

This section covers the VN Service preference. (VN Service itself is defined in Section 2, so go check that if you need a refresher 📚)

<VN Service Preference> ::= [<Location Service Preference >]

                        [<Client-specific Preference >]

                        [<End-Point Dynamic Selection Preference >]

Where:

  • Location Service Preference is about what the End-Point Location (like data centers, or DCs) can support when it comes to Virtual Network Functions (VNFs), such as a security function or firewall capability. It's how you find a path that meets the VNF constraint 🔥
  • Client-specific Preference is any preference related to VNS that an application or client can enforce through the CNC toward lower-level controllers. For example, the CNC can enforce client-specific preferences like picking a destination DC from a set of candidates based on some criteria, in the context of Virtual Machine (VM) migration. After that, MSDC/PNC should provide the DC interconnection that supports that Client-specific Preference 🫶
  • End-Point Dynamic Selection Preference says whether the endpoint (like a DC) can handle load-balancing, disaster recovery, or VM migration. If it can, it can be part of the selection by MDSC, but only after the CNC has enforced the service Preference 👑

6. TE Objects 🌈

6.1. TE Tunnel Characteristics 🚇

Tunnel Characteristics is the set of parameters you need to configure a TE tunnel. It's giving config checklist 📝

<TE Tunnel Characteristics> ::= [<Tunnel Type>]

                               <Tunnel Id>

                               [<Tunnel Layer>]

                               [<Tunnel end-point>]

                               [<Tunnel protection-restoration>]

                               <Tunnel Constraints>

                              [<Tunnel Optimization>]

Where:

<Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>
  • Tunnel Type tells you what kind of tunnel you need. In this document, only the P2P model is provided, so that's the only one we're going with for now 💖
  • Tunnel Id is the TE tunnel identifier 🪪
  • Tunnel Layer represents the layer technology of the LSPs that support the tunnel 🧱
<Tunnel End Points> ::= <Source> <Destination>

<Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot
1:1>|<prot 1:N>|prot <M:N>|<restoration>

Tunnel Constraints are the base configuration constraint parameters for the tunnel 🎯

Where <Tunnel Constraints> ::= [<Topology Id>]

                               [<Bandwidth>]

                               [<Disjointness>]

                               [<SRLG>]

                               [<Priority>]

                               [<Affinities>]

                               [<Tunnel Optimization>]

                               [<Objective Function>]
  • Topology Id points at the topology used to compute the tunnel path 🗺️
  • Bandwidth is the bandwidth used as a parameter in path computation 📶
<Disjointness> ::= <node> | <link> | <srlg>
  • Disjointness says what type of resources the tunnel has to be disjoint from 🙅‍♀️
  • Shared Risk Link Group (SRLG) is a group of physical resources that share the same risk. It's the thing an E2E tunnel is required to be disjoint from 🌩️
<Priority> ::= <Holding Priority> <Setup Priority>

Where:

  • Setup Priority indicates how much priority you have when taking resources from another tunnel [RFC3209] 👑
  • Holding Priority indicates how much priority you have for holding on to resources and avoiding preemption by another tunnel [RFC3209] 🔒
  • Affinities is the structure used to check whether a link belongs to the tunnel's path [RFC3209] 🧲
<Tunnel Optimization> ::= <Metric> | <Objective Function>
  • Metric can cover all the metrics (cost, delay, delay variation, latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471] 📊
<Objective Function> ::= <objective function type>

<objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL>
| <MCC>

For a description of the objective function type, see Section 5.4 🎀

7. Mapping of VN Primitives with VN Objects 🧩

This section maps VN primitives to VN Objects, based on Section 5. Think of it as the cheat sheet that tells you which objects go with which primitive 📋

<VN Instantiate> ::= <VN Service Characteristics>

                     <VN Member-List>

                     [<VN Service Preference>]

                     [<VN Topology>]

<VN Modify> ::= <VN identifier>

                <VN Service Characteristics>

                <VN Member-List>

                [<VN Service Preference>]

                [<VN Topology>]

<VN Delete> ::= <VN Identifier>

<VN Update> :: = <VN Identifier>
                 [<VN Member-List>]

                 [<VN Topology>]

<VN Path Compute Request> ::= <VN Service Characteristics>

                              <VN Member-List>

                              [<VN Service Preference>]

<VN Path Compute Reply> ::= <VN Computed Path>

<VN Query> ::= <VN Identifier>
<VN Query Reply> ::= <VN Identifier>

                     <VN Associated LSP>

                     [<TE Topology Reference>]

8. Mapping of TE Primitives with TE Objects 🍓

This section maps TE primitives to TE Objects, based on Section 6. Same vibe as the VN one, just for the TE side 💜

<TE Instantiate> ::= <TE Tunnel Characteristics>

<TE Modify> ::=  <TE Tunnel Characteristics>

<TE Delete> ::= <Tunnel Id>
<TE Topology Update> ::= <TE-topology-list>

<Path Compute Request> ::= <TE Tunnel Characteristics>

<Path Compute Reply> ::= <TE Computed Path>

                         <TE Tunnel Characteristics>

9. Security Considerations 🔐

Okay, this part is serious, bestie 😭 The ACTN information model isn't directly relevant when you're thinking about potential security issues. What it does is define a set of interfaces for TE networks. The protocols, procedures, and implementations that actually exchange the information model will need to secure the request and control of resources with proper authentication and authorization mechanisms. The data exchanged over the ACTN interfaces also needs verification of data integrity. And backups or redundancies should be available to restore affected data to its correct state. Protect your data, babes 🛡️

Implementations of the ACTN framework will have distributed functional components that exchange an instantiation that follows this information model. Implementations should encrypt data flowing between them, especially when they run on remote nodes, and it doesn't matter whether those flows are on external or internal network interfaces 🔒 The information model may hold customer, application, and network data that could be sensitive for business or privacy reasons, so it should only be stored in an encrypted data store. No leaks allowed 🙅‍♀️

The ACTN security discussion gets split into two specific interfaces:

  • Interface between the CNC and MDSC, the CNC-MDSC Interface (CMI)
  • Interface between the MDSC and PNC, the MDSC-PNC Interface (MPI)

For the detailed discussion of the CMI and MPI, check Sections 9.1 and 9.2 (respectively) in [RFC8453] 📖

The takeaway is that all the data models and protocols used to realize the ACTN information model should have rich security features, like we talked about in this section. Additional security risks may still exist, though 💀 So the discussion and applicability of specific security functions and protocols will be better described in documents that are specific to a use case and environment. Stay alert, besties 👑

10. IANA Considerations 🌸

Nothing for IANA here! This document has no IANA actions 🙌

11. References 📚

11.1. Normative References

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

11.2. Informative References 📚✨

okay so these are the background reads, bestie 🫶 they give extra context but aren't required to implement the thing. still worth a peek because they're the receipts 💅

[ACTN-REQ]
           Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K.
           Lee, "Requirements for Abstraction and Control of TE
           Networks", Work in Progress,
           draft-ietf-teas-actn-requirements-09, March 2018.

[Path-Compute]
           Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma,
           A., Shi, Y., Vilata, R., and K. Sethuraman, "Yang model
           for requesting Path Computation", Work in Progress,
           draft-ietf-teas-yang-path-computation-02, June 2018.

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <https://www.rfc-editor.org/info/rfc3209>.

[RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
           (TE) Extensions to OSPF Version 2", RFC 3630,
           DOI 10.17487/RFC3630, September 2003,
           <https://www.rfc-editor.org/info/rfc3630>.

[RFC4427]  Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
           (Protection and Restoration) Terminology for Generalized
           Multi-Protocol Label Switching (GMPLS)", RFC 4427,
           DOI 10.17487/RFC4427, March 2006,
           <https://www.rfc-editor.org/info/rfc4427>.

[RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
           Objective Functions in the Path Computation Element
           Communication Protocol (PCEP)", RFC 5541,
           DOI 10.17487/RFC5541, June 2009,
           <https://www.rfc-editor.org/info/rfc5541>.

[RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
           Previdi, "OSPF Traffic Engineering (TE) Metric
           Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
           <https://www.rfc-editor.org/info/rfc7471>.

[RFC7926]  Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
           Ceccarelli, D., and X. Zhang, "Problem Statement and
           Architecture for Information Exchange between
           Interconnected Traffic-Engineered Networks", BCP 206,
           RFC 7926, DOI 10.17487/RFC7926, July 2016,
           <https://www.rfc-editor.org/info/rfc7926>.

[TE-TOPO]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
           O. Dios, "YANG Data Model for Traffic Engineering (TE)
           Topologies", Work in Progress,
           draft-ietf-teas-yang-te-topo-18, June 2018.

Contributors 🌸

these are the lovely people who helped shape the doc without being listed as authors 🥹

Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com

Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com

Authors' Addresses 🦋

and here are the squad members who actually wrote it, with their contact info so you can slide into their inbox 💌

Young Lee (Editor)
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA

Phone: (469)277-5838
Email: leeyoung@huawei.com


Sergio Belotti (Editor)
Nokia
Via Trento, 30
Vimercate, Italy

Email: sergio.belotti@nokia.com


Dhruv Dhody
Huawei Technologies,
Divyashree Technopark, Whitefield
Bangalore, India

Email: dhruv.ietf@gmail.com


Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden

Email: daniele.ceccarelli@ericsson.com


Bin Yeong Yoon
ETRI

Email: byyun@etri.re.kr
📦 where this page comes from