YANG Model for Scalable VTN

defines IETF network slices that provide connectivity coupled with network resources commitment between a number of endpoints over a shared network infrastructure. Enhanced VPN (VPN+) aims to provide enhancements to existing VPN services to support network slicing. VPN+ is composed of a VPN overlay and an underlying Virtual Transport Network (VTN) which has a customized network topology and a set of dedicated or shared resources in the underlay network. VPN+ and VTN are defined in . describes the scalability considerations in the control plane and data plane to enable VPN+ services. In control plane, decoupling the topology and resource attributes of VTN allows that multiple VTNs share the same topology. In data plane, a global VTN-ID in the data packet is used to determine the set of resources reserved for the corresponding VTN. This document defines the configuration yang model for scalable VTN solution.

The general process of VTN configuration includes: Creat VTN instance based on the network slice requirement Configure the overlay network to initiate VTN in the network Steer the traffic to the corresponding VTN to provide network slice service The corresponding requirement of VTN configuration data model during the process is defined in this section.

After collecting information about the underlying network topology and available resources. Each VTN can have a customized topology and a set of network resources allocated. Flexible combination is allowed when multiple VTNs may shared the same topology, or multiple VTNs may share the same set of network resources. VTN is created with the following attributes: VTN Topology: Based on the existing work in IETF, topology specification for VTN could be implemented by Multi-Topology Routing (MTR) which defined in , , or Flex-algo which is defined in . Correspondingly, the topology attribute of a VTN could be determined by MT-ID or algorithm ID; Signaling extensions for VTN topology is defined in and respectively. Network Resource: network resource is allocated for VTN based on the requirement. For example, VTN could be bound with a layer 2 sub-interface with a subset of the link bandwidth. VTN Data Plane Identifier: VTN data plane identifier is uesed to identify network resource that has been allocated for the VTN. VTN data plane identifier depends on the encapsulation type of the traffic, for example IPv6 defined in . VTN data plane identifier is not mandatory when there are other methods to distinguish VTN instances.

VTN initiation in the network also includes two aspects: resource allocation and traffic steering through VTN specified topology. Resource allocation is defined in this section and traffic steering is defined in the next section. Several technologies could be used for resource allocation in the network device, for example: TSN defined in IEEE 802.1 introduces the concept of time aware shaping; FlexE provides the ability to multiplex multiple channels over one or more Ethernet links; Existing Diffserv scheduling/shaping allow the construction of virtual sub-interfaces. All these technologies could be used to dedicated resource in a shared physical interface. The configuration of these technologies play the role of VTN initiation when the allocated resource is bound with a specified VTN instance.

Just as color in SR policy defined in , color is defined as an attribute of VTN to steer the traffic. With SR policy, traffic could be steered into a SR policy by : SR policy with color is provisioned to the headend; The route with some particular color matchs the SR policy with the corresponding color, which could satisfy the requirement of the route Traffic with the route is steered into the SR policy; Similarly, traffic could be steered into VTN by: VTN is configured with the attribute of color; The route with some particular color matchs VTN with the correponding color, which could satisfy the requirement of the route Traffic with the route is steered to the VTN SR policy could also be bound with VTN to provide resource reservation in the network. BGP SR Policy extensions for VTN is defined in and similarly, YANG model which is used to bound SR policy to a specified VTN is defined in this document by: SR policy with color is provisioned to the headend; The preferred candidate path is bound to VTN; The route with some particular color matchs the SR policy with the corresponding color, which could satisfy the requirement of the route Traffic with the route is steered into the SR policy; Packet is encapsulated with the VTN data plane identifier.

WG List: Editor: Xuesong Geng Editor: Zhibo Hu "; description "This YANG module defines a data model for VTN(Virtual Transport Network)"; revision "2021-04-14" { description "This is the initial version of VTN yang module"; reference "RFC XXX: YANG Data Model for VTN"; } grouping vtn-instances{ description "VTN instances"; list vtn-instance { key "vtn-id"; description "vtn instance list"; leaf vtn-id { type uint32; description "vtn-id"; } container vtn-topology { description "vtn topology is nt"; choice vtn-topolgy-type{ description "customized topology of VTN"; case flex-algo { container flex-algo { description "flex-algo could be used as topology specification for VTN"; leaf flex-algo-id { type uint32; description "flex-algo-id for VTN"; } } } case multi-topology { description "MT could be used as topology specification for VTN"; leaf multi-topology-id{ type uint32; description "MT-id for VTN"; } } } } leaf vtn-data-plane-identifier { type uint32; description "VTN identifier of data plane for vtn distinguishment"; } } } grouping interface-configuration-for-vtn{ description "interface configuration for vtn"; container interface-configuration-for-vtn { description "interface configuration for vtn"; choice vtn-interface-binding-type{ description "vtn interface binding type"; case layer-2-sub-interface { description "vtn is bound to a layer-2 sub-interface"; container layer-2-sub-interface { description "sub-interface configuration"; leaf sub-interface-id { type uint32; description "sub-interface id"; } leaf vtn-id { type uint32; description "vtn-id"; } leaf bandwidth { type uint32; description "bandwidth allocation for the slice"; } } } case queue { description "vtn is bound to a queue in the interface"; container queue { description "queue configuration"; leaf queue-id { type uint32; description "queue id"; } leaf vtn-id { type uint32; description "queue id"; } leaf bandwidth { type uint32; description "bandwidth allocation for the slice"; } } } } } } grouping sr-policy-traffic-steering{ container vtn{ description "candidata path is bound to VTN"; leaf vtn-id{ type uint32; description "vtn"; } } } grouping vtn-traffic-steering{ container vtn-traffic-steering { leaf color-index { type uint32; description "color index"; } leaf vtn-id { type uint32; description "vtn id"; } } } container vtn-instance { description "vtn instance configuraiton"; uses vtn-instances; } augment "/if:interfaces/if:interface" { description "interface model extension for vtn"; uses interface-configuration-for-vtn; } augment /ni:network-instances/ni:network-instance{ description "network instance model extension for vtn"; uses vtn-traffic-steering; } container sr-policy-extension { description "sr policy extension for vtn"; uses sr-policy-traffic-steering; } } ]]>

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.