Image

As noted in the TeraFlow blog at teraflow-will-leave-legacy-its-ietf-standards-and-technology-leadership, the project is making significant contributions to the standardisation work of the IETF. The 115th meeting of the IETF was held in London at the start of November, and much progress was made on topics of interest to TeraFlow.

Advancing TeraFlow Internet-Drafts at Working Group Meetings

Image
tweetcard

Three TeraFlow drafts were presented at the TEAS working group meetings. The TEAS (Traffic Engineering Signaling and Architecture) working group is where traffic engineering in the IETF is predominantly developed and is specifically responsible for network slicing.

  • "Instantiation of IETF Network Slices in Service Providers Networks" (draft-barguil-teas-network-slices-instantiation) is developing how the different IETF service models can be used to build a broader management model for network slicing. The meeting discussed three possible architectural options and the relationship between the IETF network slice service model, the VPN service models, and the network service YANG models. Also up for debate was the mapping between IETF network slice service model parameters and VPN service model parameters.
  • "IETF Network Slice Controller and its associated data models" (draft-contreras-teas-slice-controller-models) describes the Network Slice Controller (NSC) that manages customer requests for network slices and converts these service requests into instructions for the network. At this meeting, the goal was to identify major NSC components and how associated data models apply. The proposal was to split the NSC into two sub-components: the Mapper processes the customer request, putting it into the context of the overall IETF Network Slices in the network; the Realizer processes the complete view of all the slices in the network, decides the appropriate technologies for realising the IETF Network Slice and triggers its realisation.
  • "IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Controllers" (draft-ietf-teas-ietf-network-slice-use-cases) presents the different ways that network slices might be used by customers and the different parameters needed to deliver the services. In addition, the meeting discussed the motivation and support for work on YANG models for the IETF Network Slice Service interface.

A further TeraFlow Internet-Draft was presented in the Netmod working group. "Extensions to the Access Control Lists (ACLs) YANG Model" (draft-dbb-netmod-acl) describes a set of extensions that fix many of the limitations of the ACL YANG model as initially defined in RFC 8519. There has been some debate about resolving the deficiencies by thoroughly revising the YANG model or augmenting it. The discussion in the meeting sought to catalogue the issues and attempt to decide to use augmentation.

Future Internet Routing and Addressing: paper presentations and discussion

As a follow-up to the successful Future Internet Routing and Addressing (FIRA) workshop at SigComm23, an unofficial side meeting was organised during IETF-115 to present three papers for the benefit of IETF participants who were unable to attend FIRA. The slides for the papers can be found at github.com/dirk-trossen-huawei/IETF115_routing_sidemeeting. In addition, this side meeting helps to promote two TeraFlow drafts:

Inventory Management: an opportunity for collaboration

Another side meeting brought together a group of interested people from across the industry to discuss the management of network inventory and assets. There are several new initiatives within the IETF to develop YANG models that build on existing topology and hardware management work to produce data models to track and report on the network's software and hardware revisions and types.

This is a topic of great interest to TeraFlow as part of the SDN management system, and partners will be participating in the new IETF mailing list set up for the topic. www.ietf.org/mailman/listinfo/Inventory-yang

Time Variant Routing: A new IETF Initiative

Existing routing protocols expect to maintain concurrent, end-to-end connected paths across a network. Rapidly responding to changes in connectivity, such as the loss of an adjacent peer, are exceptional circumstances that must be corrected prior to the resumption of data transmission. Corrections may include re-establishing lost adjacencies and recalculating or rediscovering the currently available topology. In traditional fixed networks, links and nodes may disappear and appear with some degree of predictability. However, traditional routing does not handle the potential connectivity represented by nodes and links that may appear in the future. Nor do they handle planning around planned outages.

The Time Variant Routing (TVR) initiative investigates methods to plan and predict reachability across a network where reachable neighbours will only be present at and for specific known time intervals. As a result, network routing and scheduling of connectivity would be capable of considering availability and predictability metrics, along with traditional routing metrics such as costs and latency. This enables less-interrupted and deterministic service delivery without the need to actively reroute at the packet level.

Current use cases for TVR include rural networking, which might have access to microwave links for specific times during the day due to energy costs or solar power capability. In addition, non-Terrestrial Networks (NTN) using Free-Space Optics (FSO) offer another set of challenges where Unmanned Aeriel Vehicles (UAV), or Low-Earth-Orbit (LEO) satellite constellations, may have predictable but scheduled link availability.

Planning for an IETF 116 Hackathon

Image
IETF 116 Hackathon
The weekend before each IETF meeting is dedicated to a hackathon. Teams of coders get together to work on projects implementing, testing, or researching IETF protocols. Although TeraFlow was not part of the hackathon at IETF-115. However, we are starting to plan for IETF-116 and how best to showcase the project and explain how we integrate the many IETF YANG models to build a top-to-bottom management system.