A VTN Network YANG Module

defines IETF network slice services that provide connectivity coupled with network resources commitment between a number of endpoints over a shared network infrastructure, and also defines the IETF Network Slice controller (NSC) to realize the network slice services by mapping it to a suitable underlying technology. describes that enhanced VPN (VPN+) services can be used to realize IETF network slice services. To improve service scalability, The virtual transport network (VTN), which has a customized network topology and a group of dedicated or shared nodes and links of the physical network, is introduced for multiple VPN+ services with similar connection and SLA requirements. For the control and management of these VTN resources, gives a detailed analysis and description. This document defines VTN network model that the NSC can use to create and manage VTN instances to realize the network slicing services. According to the YANG model classification of , VTN network model is a network configuration model.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14, , when, and only when, they appear in all capitals, as shown here. The following terms are defined in and are used in this specification: configuration data state data The following terms are defined in and are used in this specification: augment data model data node The terminology for describing YANG data models is found in .

The tree diagram used in this document follows the notation defined in .

To realize the IETF Network Slice based on the reference framework defined in , the shows an approach with VPN network model and VTN network YANG module.

The VTN network model can be used in the following ways: Static VTN configuration: A VTN instance can be created before processing IETF Network Slice service request by a network controller. Dynamic VTN configuration: A VTN instance can be initiated along with configuring IETF Network Slice service request by a network controller. In the process of realizing an IETF network slice service, when creating a Layer 3 VPN or Layer 2 VPN instance, The NSC can use a static VTN instance or dynamically create one as the VPN underlay transport. Compared with existing VPN underlying full mesh tunneling mechanisms, the VTN could provide resource isolation, topology constraints, and simplified configuration. Additionally, specific service flows of a VPN can be further optimized using SR policies defined in . And also in multi-domain network slicing cases, instead of mapping the overlay VPN to the intra-domain VTNs at the edge of each domain, an inter-domain VTN could be used directly for inter-domain interconnection, which is described in . The network controller serving the transit domain can only manage the VTNs. A 5G end-to-end network slicing scenario is shown in the following figure.

In addition to providing VTN network configuration, VTN network model also provides monitoring details of the underlying resource created to meet the requirements of IETF network slice service. An example of VTN instances and a physical network is illustrated in .

In the example, each VTN instance has a customized network topology comprised of a set of links and nodes in the physical network. In control plane, each VTN is associated with a multi-topology or a Flex-Algo. And it also has its own forwarding plane resources and identifiers which provide VTN-specific packet processing.

There are multiple modes of VTN operations to be supported as follows. New VTN Binding: In realization, a NSC could request a set of underlay resources that are unaffected by other slice services. A new VTN could be created and bound to a VPN per the network slice service and not used for any other VPNs. VTN Sharing: A NSC could decide to use allocated underlay resources to meet the requirements of an IETF network slice. Therefore, an existing VTN instance can be reused and multiple VPNs in the VTN instance can share same VTN resources. In some cases, the properties of the existing VTN (e.g., link bandwidth) need modification. VTN Deletion: If the NSC determines that no VPN service is using a VTN, the NSC can delete the VTN instance. VTN Monitoring: The NSC could also use the VTN network model to track and monitor VTN resource status and usage.

A VTN network is modeled as network topology defined in with augmentations. A new network type "vtn" is defined in this document. When a network topology data instance contains the vtn network type, it represents an instance of a VTN. Each VTN consists of a set of nodes and a set of links. Each node and link have different attributes that represent the allocated resources or the operational status of the VTN network. VTN supports several resource partition methods, which are defined by 'interface-partition-capability'' under a link, which can further be supported by FlexE and independent queue techniques. The container "vtn" under 'network' of defines global parameters for a VTN, which defines the specific control plane technique of the VTN and a unique "vtn-data-plane identifier" for data plane. And also, a color attribute for steering traffic, such as VPN traffic, into a VTN is also defined.

The description of the VTN data nodes are as follows: "vtn-id": Is an identifier that is used to uniquely identify the VTN instance within the network scope. VTN allocation resources: The nodes and links represent the network resource allocated for a VTN instance. 'bandwidth-reservation' specifies the bandwidth allocated to a VTN network, or is overridden by the configuration of the VTN link. 'interface-partition-capability' specifies the resource partition capability of the physical interfaces associated with a VTN link. VTN control plane: Based on the existing work in IETF, control plane mechanism of VTN could be implemented by Multi-Topology Routing (MTR) which defined in , , and or Flex-algo which is defined in . With these control plane technologies, VTN nodes of each VTN instance will create their own VTN-specific forwarding tables. VTN data plane: Defines the data plane mechanism and the VTN identifier of the network domain managed by the network controller. The data plane mechanism could be baed on MPLS or IPv6 forwarding. "vtn-domain-identifier" is used to identify network resource of data plane that has been allocated for the VTN. In the case of IPv6 based forwarding, VTN data plane identifier is defined in . If a network slice service traverses multiple network domains, a global VTN identifier across the domains may be defined. For example, defines a IPv6 extension header to carry the global VTN identifier. VTN steering policy: "vtn-color-id" is the color attribute of VTN for traffic steering.

<CODE BEGINS> file "ietf-vtn-ntw@2021-06-04.yang"

WG List: Editor: Bo Wu : Dhruv Dhody "; description "This YANG module defines a network data module for VTN(Virtual Transport Network)"; revision 2021-06-04 { description "This is the initial version of VTN network yang module"; reference "RFC XXX: YANG Data module for VTN network"; } identity interface-partition-capability { description "Base identity for interface partition capability."; } identity flexe-partition { base interface-partition-capability; description "Identity for FlexE partition capability."; } identity queue-partition { base interface-partition-capability; description "Identity for queue partition capability."; } identity vtn-data-plane-type { description "Base identity for VTN data plane type."; } identity vtn-data-plane-vtn-ipv6 { base vtn-data-plane-type; description "Identity for VTN based packet forwarding of IPv6."; } identity vtn-data-plane-vtn-mpls { base vtn-data-plane-type; description "Identity for VTN based packet forwarding of MPLS."; } identity vtn-data-plane-sr-mpls { base vtn-data-plane-type; description "Identity for SR MPLS forwarding mechanism."; } identity vtn-data-plane-srv6 { base vtn-data-plane-type; description "Identity for SRv6 forwarding mechanism."; } /* * Groupings */ grouping traffic-steering-policy { description "Configuration of the traffic mapping policy."; container steering-policy { description "Policy set that matches to a VTN."; leaf vtn-color-id { type uint32; description "VTN color ID for VTN traffic steering"; } } } grouping vtn-bandwidth-reservation { description "Grouping for VTN bandwidth reservation."; container bandwidth-reservation { description "Container for VTN bandwidth reservation."; choice bandwidth-type { description "Choice of bandwidth reservation type."; case bandwidth-value { leaf bandwidth-value { type uint64; units "bps"; description "Bandwidth allocation for the VTN as absolute value."; } } case bandwidth-percentage { leaf bandwidth-percent { type rt-types:percentage; description "Bandwidth allocation for the VTN as a percentage of a link."; } } } } } grouping vtn-control-plane-attributes { description "VTN topology control plane attributes."; container control-plane { description "vtn control plane mechanism."; choice vtn-cp-type { description "Choice of vtn control plane."; case flex-algo { container flex-algo { description "A VTN could use flex-algo as a control plane mechanism."; leaf flex-algo-id { type uint32; description "flex-algo-id for VTN"; } } } case multi-topology { description "A VTN could use MT (Multi-Topology) as a control plane mechanism."; leaf multi-topology-id { type uint32; description "MT-id for VTN"; } } } } } grouping vtn-data-plane-attributes { description "Grouping for VTN topology data plane attributes."; container data-plane { description "VTN data plane mechanism."; leaf vtn-global-identifier { type uint32; description "The global VTN identifier for multi-domain is specified."; } container domain-data-plane { description "VTN data plane mechanism per network domain."; leaf data-plane-type { type identityref { base vtn-data-plane-type; } description "Specifies the data plane forwarding mechanism of the VTN. The mechanism consists of VTN based Packet Forwarding or existing Segment Routing with MPLS data plane or IPv6 data plane."; } leaf vtn-domain-identifier { type uint32; description "The domain VTN identifier is specified for VTN based Packet Forwarding of a network domain. The forwarding plane could be with the MPLS Data Plane or IPv6"; reference "draft-li-mpls-enhanced-vpn-vtn-id? Carrying Virtual Transport Network identifier in MPLS Packet draft-dong-6man-enhanced-vpn-vtn-id Carrying Virtual Transport Network Identifier in IPv6 Extension Header"; } } } } grouping vtn-topology-attributes { description "VTN topology scope attributes."; container vtn { description "Containing VTN topology attributes."; leaf vtn-id { type uint32; description "VTN identifier"; } leaf vtn-name { type string; description "VTN Name"; } uses vtn-bandwidth-reservation; uses vtn-control-plane-attributes; uses vtn-data-plane-attributes; uses traffic-steering-policy; } // vtn } // vtn-node-attributes grouping vtn-node-attributes { description "VTN node scope attributes."; container vtn { description "Containing VTN attributes."; } } // vtn-node-attributes grouping vtn-link-attributes { description "VTN link scope attributes"; container vtn { description "Containing VTN attributes."; leaf interface-partition-capability { type identityref { base interface-partition-capability; } description "Describes different resource partition type of a link."; } uses vtn-bandwidth-reservation; } } // vtn-statistics grouping statistics-per-vtn { description "Statistics attributes per VTN."; } // vtn-node-statistics grouping statistics-per-node { description "Statistics attributes per VTN node."; } // one-way-performance-metrics grouping one-way-performance-bandwidth { description "Grouping for one-way performance bandwidth ."; leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Available bandwidth that is defined to be VTN link bandwidth minus bandwidth utilization. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link (i.e. as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } } // vtn-link-statistics grouping vtn-statistics-per-link { description "Statistics attributes per VTN link."; container statistics { config false; description "Statistics for VTN link."; leaf admin-status { type te-types:te-admin-status; description "The administrative state of the link."; } leaf oper-status { type te-types:te-oper-status; description "The current operational state of the link."; } uses one-way-performance-bandwidth; uses te-packet-types:one-way-performance-metrics-packet; } } augment "/nw:networks/nw:network/nw:network-types" { description "Defines the VTN topology type."; container vtn { presence "Indicates VTN topology"; description "Its presence identifies the VTN type."; } } augment "/nw:networks/nw:network" { when 'nw:network-types/vtn-ntw:vtn' { description "Augment only for VTN topology."; } description "Augment VTN configuration and state."; uses vtn-topology-attributes; } augment "/nw:networks/nw:network/nw:node" { when '../nw:network-types/vtn-ntw:vtn' { description "Augment only for VTN topology."; } description "Augment node configuration and state."; uses vtn-node-attributes; } augment "/nw:networks/nw:network/nt:link" { when '../nw:network-types/vtn-ntw:vtn' { description "Augment only for VTN topology."; } description "Augment link configuration and state."; uses vtn-link-attributes; uses vtn-statistics-per-link; } } ]]> <CODE ENDS>

The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF access control model provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. vtn-link: A malicious client could attempt to remove a link from a topology, add a new link. In each case, the structure of the topology would be sabotaged, and this scenario could, for example, result in an VTN topology that is less than optimal. The entries in the nodes above include the whole network configurations corresponding with the VTN, and indirectly create or modify the PE or P device configurations. Unexpected changes to these entries could lead to service disruption and/or network misbehavior.

This document registers a URI in the IETF XML registry . Following the format in , the following registration is requested to be made:

This document requests to register a YANG module in the YANG Module Names registry .