Extensions to the YANG Data Model for L3VPN Service Delivery

6.2.1. Dynamic networking provisioning

Requirement:¶

• Customers with workloads including, but not limited to, data computation offloaded to cloud DCs, periodic data circulation for audit or other purpose and temporary event organization demand task-based connectivity: VPN tunnels are set up only when data transmission tasks start and torn down upon task completion. This avoids the extra costs incurred by persistent long-term VPN subscriptions from operators.¶

• Customers require connection provisioning latency to be provided as an SLO attribute, which quantifies the time offset between the requested-start and actual-start timestamps.¶

Gap in [RFC8299]: L3SM assumes persistent connectivity; it doesn't provide parameters to specify the requested-start time and requested-stop time of AC connections or activation time constraints.¶

Gap in [RFC9834]: The ietf-bearer-svc data yang model defined in [RFC9834] provides the requested-start and requested-stop nodes to specify the expected activation and deactivation date and time of a bearer; but it lacks nodes to indicate whether the connection remains always-on throughout the requested period. In certain scenarios, the connection does not operate in always-on mode over the requested time window; its activation is limited to specific time slots on designated calendar days. A list-type node for L3VPN activation times shall be provided to allow customers to specify multiple connection periods in a single configuration.¶

Extensions:¶

In L3SM, a site refers to a physical location and associated customer premises equipment. AC represents a logical VPN access channel provided by the operator for customers. After configured by the operator, an AC can be bound to a VPN instance to implement end-to-end VPN networking services. From operational practice,sites are typically static and seldom rebuilt or dismantled, while logic access links may be established and bounded to VPN instanceon demand. As an implementation example, dynamic networking mainly refers to the on-demand establishment, association and teardown of ACs. This document is not limited to any specific implementation approach.¶

This YANG data model defines support for on-demand establishment, association and release of VPN connectivity , with specified provisioning delay constraints. The detailed implementation mechanisms for fast activation and deactivation of L3VPN connections are implementation-specific and out of scope of this document.¶

Figure 3 illustrates the module augmentation subtree structure of dynamic networking.¶

augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
        /l3vpn-svc:site-network-accesses
        /l3vpn-svc:site-network-access:
  +--rw service
  |  +--rw requested-start? yang:date-and-time
  |     when "../dynamic-attribute/always-on = true";
  |  +--rw requested-stop? yang:date-and-time
  |     when "../dynamic-attribute/always-on = true";
  |  +--rw svc-input-bandwidth uint64
  |  +--rw svc-output-bandwidth uint64
  |  +--rw dynamic-attribute /
   {dynamic networking and/or bandwidth adjustment}
  |  |  +--rw always-on? boolean
  |  |  +--rw active-networking-policy {not-always-on}?
  |  |     +--rw connection-provisioning-delay-ref? leafref
  |  |     +--rw (policy-mode)
  |  |        +--:(immediate)
  |  |        |  +--rw duration-hours uint16
  |  |        |  +--ro actual-start-time yang:date-and-time
  |  |        |  +--ro actual-stop-time yang:date-and-time
  |  |        +--:(scheduled)
  |  |           +--rw time-period* [period-id]
  |  |              +--rw period-id string
  |  |              +--rw date-list* [date-id]
  |  |                 +--rw date-id string
  |  |                 +--rw target-date yang:date
  |  |              +--rw time-slot* [slot-id]
  |  |                 +--rw slot-id string
  |  |                 +--rw start-time yang:time-of-day
  |  |                 +--rw stop-time yang:time-of-day
  |  |                 +--ro actual-start-time yang:date-and-time
  |  |                 +--ro actual-stop-time yang:date-and-time

• dynamic-attribute: The dynamic-attribute container groups all parameters associated with dynamic service provisioning. This parameter is configurable only when the dynamic networking and/or bandwidth adjustment feature is enabled. If this feature is not enabled, the service shall adopt the conventional L3SM model which assumes persistent connectivity.¶

• always-on: Boolean flag indicating whether the connection is consistent (default true) . The requested-start and requested-stop parameters are only configurable when always-on is enabled. If always-on is false, the customer need to specify the exact time slots.¶

• connection-provisioning-delay: Latency parameter specifying the time offset between requested activation and actual activation of the connection. Network operators may predefine a set of latency-related templates, from which customers may select the one matching their service requirements. The connection-provisioning-delay attribute can reference a predefined latency template.¶

• active-networking-policy:The active-networking-policy container groups parameters associated with dynamic networking service capabilities, including connection-provisioning-delay and specify exact time slots for networking service ,which is only valid when the always-on attribute is set to false.¶

  • policy-mode: There are two types of requirements for specifying exact time slots: immediate activation and scheduled activation. Upon reaching the scheduled active time, the network controller should deploy relevant configurations to bring up the specified connections, and when reaching the scheduled tear-down time, the network controller should deploy corresponding configurations to tear down this connection. In addition to bring up or tearing down the target access link, the controller should simultaneously add or remove all relevant configurations associated with the VPN service that reference this access link from other access links.¶

    • Immediate activation means that service configurations are deployed right after customer subscription. Under the immediate activation mode, the start time does not need to be specified, and the end time is derived from the reserved duration.¶

    • Scheduled activation means supports for explicit calendar date-specific activation, allowing customers to suscribe a list of exact valid dates(YYYY-MM-DD) and corresponding intra-day time slots on which the dynamic networking service takes effect.¶

  • connection-provisioning-delay monitoring: The read-write start-time and end-time are configured to express customers' expected time to enable/ disable the connection, while the corresponding read-only actual-start-time and actual-end-time reports the actual date and time when the bearer was enable/ disable. The difference between the actual timestamps and the expected timestamps represents the actual service provisioning delay. This value is used by customers to check whether the service meets the connection-provisioning-delay SLO constraints.¶

6.2.2. Dynamic bandwidth adjustment

Requirement:¶

• Customers maintain a low-bandwidth persistent connection for regular use. When special requirements arise (such as large data transmission workloads), higher-bandwidth connections may be provisioned temporarily.¶

• Customers require bandwidth adjustment provisioning latency to be provided as an SLO attribute, which quantifies the adjustment time offset between the requested-start/stop time and actual-start/end timestamps.¶

Gap in [RFC8299]: L3SM specifies static bandwidth parameters (svc-input-bandwidth, svc-output-bandwidth) without support for elastic bandwidth adjustment and adjustment provisioning delay constraints.¶

Extensions:¶

This YANG data model defines support for adjustment of bandwidth allocations. Figure 4 illustrates the module augmentation subtree structure of dynamic bandwidth adjustment.¶

augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
        /l3vpn-svc:site-network-accesses
        /l3vpn-svc:site-network-access:
  +--rw service
  |  +--rw requested-start? yang:date-and-time
  |     when "../dynamic-attribute/always-on = true";
  |  +--rw requested-stop? yang:date-and-time
  |     when "../dynamic-attribute/always-on = true";
  |  +--rw svc-input-bandwidth uint64
  |  +--rw svc-output-bandwidth uint64
  |  +--rw dynamic-attribute   /
   {dynamic networking and/or bandwidth adjustment}
  |  |  +--rw always-on? boolean
  |  |  +--rw active-networking-policy {not-always-on}?
  |  |            ...
  |  |  +--rw dynamic-bandwidth-attribute
  |  |     +--rw dynamic-bandwidth-indicator? boolean
  |  |     +--rw bandwidth-adjustment-provisioning-delay-ref  leafref
  |  |     +--rw max-adjustment-bandwidth-range?   leafref
  |  |        +--rw (policy-mode)
  |  |           +--:(immediate)
  |  |           |  +--rw duration-hours uint16
  |  |           |  +--rw svc-input-bandwidth uint64
  |  |           |  +--rw svc-output-bandwidth uint64
  |  |           |  +--ro actual-start-time yang:date-and-time
  |  |           |  +--ro actual-stop-time yang:date-and-time
  |  |           +--:(scheduled)
  |  |              +--rw time-period* [period-id]
  |  |                 +--rw period-id string
  |  |                 +--rw date-list* [date-id]
  |  |                    +--rw date-id string
  |  |                    +--rw target-date yang:date
  |  |                 +--rw time-slot* [slot-id]
  |  |                    +--rw slot-id string
  |  |                    +--rw start-time yang:time-of-day
  |  |                    +--rw stop-time yang:time-of-day
  |  |                    +--ro actual-start-time yang:date-and-time
  |  |                    +--ro actual-stop-time yang:date-and-time
  |  |                    +--rw svc-input-bandwidth uint64
  |  |                    +--rw svc-output-bandwidth uint64

• dynamic-bandwidth-attribute: The dynamic-bandwidth-attribute container groups parameters associated with dynamic bandwidth adjustment service including bandwidth-provisioning-delay, max-adjustment-bandwidth-range and specify exact time slots for bandwidth adjustment service. When alway-on is true, the svc-input-bandwidth node and the svc-output-bandwidth node under /site-network-access/service indicates the base bandwidth value applicable to the access link.¶

  • dynamic-bandwidth-enabled: Boolean flag indicating whether bandwidth adjustment is enabledd (default false).¶

  • maximum-bandwidth-adjustment-profile: Maximum range allowed for a bandwidth modification. This parameter is a factor that operators take into account when selecting appropriate bearer solution for access links. As an illustration, operators may deploy GE links between CE and PE when the maximum bandwidth is less than 1 Gbps. If the required bandwidth exceeds 10 Gbps, 50G-PON or 100G interfaces can be adopted as the access medium instead. The exact approach to be adopted is implementation-specific and determined by the actual deployment.¶

  • bandwidth-adjustment-provisioning-delay: Maximum allowed delay to complete a bandwidth modification. Network operators may predefine a set of latency-related templates, from which customers may select the one matching their service requirements.¶

  • bandwidth-flex-policy:There are two types of requirements to specify exact time slots: immediate activation and scheduled activation. Immediate activation means that service configurations are deployed right after customer subscription. scheduled activation means supports for explicit calendar date-specific activation, allowing customers to suscribe a list of exact valid dates(YYYY-MM-DD) and corresponding intra-day time slots on which the dynamic bandwidth service takes effect. Upon reaching the scheduled adjustment time, the network controller should deploy relevant configurations to adjust the bandwidth to a new value, and when the scheduled bandwidth restoration time arrives, the controller shall revert the bandwidth of the access link to its baseline value. Operators may adopt different bandwidth adjustment implementation mechanisms according to distinct SLO requirements for adjustment latency.¶

  • bandwidth-adjustment-provisioning-delay monitoring: The read-write start-time and stop-time are configured to express customers' expected time to adjust the bandwidth of the connection, while the corresponding read-only actual-start-time and actual-end-time reports the actual date and time when the bandwidth adjustment was completed. The offset between the actual timestamps and the expected timestamps represents the actual service provisioning delay. This value is used by customers to check whether the service meets the bandwidth-adjustment-provisioning-delay SLO constraints.¶

6.2.3. Enhanced qos

Requirement:¶

• With the widespread deployment of SRv6 network slicing, L3VPN services require slicing-specific SLO/SLE parameters including isolation. L3SM shall support binding L3VPN instances to dedicated slicing SLO/SLE guarantees.¶

• Customers expect QoS flow classification policies to be reusable across other functional modules in the same L3VPN service, such as security and performance monitoring, to reduce the complexity of flow classification definitions.¶

• The provisioning of QoS functionality consists of traffic classification policies and QoS policies. As noted above, reusable flow classification policies are required. For QoS policies, customers require a globally applicable QoS policy to eliminate the high complexity of separate configurations per site and per link. Sites or links with special requirements may be assigned customized settings individually.¶

Gap in [RFC8299]:¶

• L3SM provides basic QoS profiles but lacks integration with network slicing constructs and parameterized SLO/SLE specifications.¶

• Traffic classification policies reside under the QoS container, making them inconvenient to be reused by other functional modules.¶

• [RFC8299] defines QoS policies at the site and site-network-access levels, without support for the vpn-service level. This results in extensive duplicated configurations across individual sites and increases operational complexity.¶

Extensions:¶

This YANG data model defines support for enhanced qos. Figure 5 illustrates the module augmentation subtree structure of enhanced qos.¶

  |  +--rw qos {qos}?
  |     +--rw (qos-profile)
  |        +--:(custom) {qos-custom}?
  |           +--rw classes {qos-custom}?
  |              +--rw class* [class-id]
  |                 +--rw class-id string
  |                 +--rw isolation* identityref

• isolation: Specify the requirement that the L3VPN Service is not impacted by the existence of other customers or services in the same network. The definition of isolation aligns with [I-D.ietf-teas-ietf-network-slice-nbi-yang], enabling consistent policy application across VPN and slice services.¶

As mentioned above, the provisioning of QoS functionality consists of traffic classification policies and QoS policies. QoS profiles serve as containers for QoS policies. QoS profiles can be supplied as standardized templates by the operators, or customized independently by customers. QoS policies are appropriate for global definition under the vpn-service node and applicable accross all sites and access links. Traffic classification policies ought to be tied to specific sites and access links, and therefore should be defined at the site level and access link level to enable reuse across different functional modules.¶

Traffic-classification subtree structure is shown in Figure 6.¶

  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site:

  +--rw classification-policy* [rule-id]
  |  +--rw rule-id yt:uint32
  |  +--rw (match-type)
  |     +--:(match-flow)
  |        +--rw dscp? inet:dscp
  |        +--rw dot1p? uint8
  |        +--rw protocol-field? uint8
  |        +--rw ipv4-src-prefix? inet:ipv4-prefix
  |        +--rw ipv4-dst-prefix? inet:ipv4-prefix
  |        +--rw ipv6-src-prefix? inet:ipv6-prefix
  |        +--rw ipv6-dst-prefix? inet:ipv6-prefix
  |        +--rw l4-src-port? inet:port-number
  |        +--rw target-sites* [svc-id] {target-sites}?
  |        +--rw l4-src-port-range?
  |        |  +--rw lower-port? inet:port-number
  |        |  +--rw upper-port? inet:port-number
  |        +--rw l4-dst-port-range?
  |        |  +--rw lower-port? inet:port-number
  |        |  +--rw upper-port? inet:port-number
  |     +--:(match-application)
  |        +--rw match-application? identityref
  |  +--rw target-class-id? string
  +--rw security
  |     +--rw class* [class-id]
  |              ...
  +--rw service
  |     +--rw (qos-profile)
  |        +--:(custom)
  |           +--rw classes {qos-custom}?
  |              +--rw class* [class-id]
  |              ...

The global qos policy subtree structure is shown in Figure 7.¶

  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-service:

  +--rw qos {qos}?
  |   ....

6.2.4. Performance Monitoring

Requirement: Provide end-to-end service quality visibility.¶

Gap in [RFC8299]:The base L3SM lacks native monitoring configuration options and service-level performance metrics.¶

Extensions:¶

Figure 8 illustrates the module augmentation subtree structure of perf-mon.¶

  +--rw perf-mon {perf-mon}?
  |  +--rw enable? boolean
  |  +--rw perf-mon-profile
  |     +--rw (perf-mon-profile)
  |        +--:(standard)
  |        |  +--rw profile?
  |        +--:(custom) {perf-mon-custom}?
  |           +--rw measurement-interval yt:uint32 units seconds
  |           +--rw pm-attributes
  |              +--ro one-way-min-delay? yang:gauge64
  |              +--ro one-way-max-delay? yang:gauge64
  |              +--ro one-way-delay-variation? yang:gauge64
  |              +--ro one-way-packet-loss? decimal64
  |              +--ro two-way-min-delay? yang:gauge64
  |              +--ro two-way-max-delay? yang:gauge64
  |              +--ro two-way-delay-variation? yang:gauge64
  |              +--ro two-way-packet-loss? decimal64

• monitoring-enabled: Boolean flag to enable performance monitoring for the L3VPN service (default false).¶

• measurement-interval: Specifies the performance measurement interval, in seconds.¶

• pm-attributes (read-only): A set of operational state and service-level performance metrics, including delay, packet loss and jitter, to enrich operational state data and enhance end-to-end quality visibility.¶

6.2.5. Enhanced security

Requirement:¶

• Support quantum-safe encryption for high-security data transmission scenarios, defending data against potential cracking threats brought by future cryptographically relevant quantum computers and providing long-term transmission confidentiality.¶

• Support ce-ce encryption to safeguard security throughout the full data transmission process.¶

• Support fine-grained traffic encryption to encrypt designated flows instead of full-traffic encryption. Driven by service charges and forwarding performance constraints, customers demand flow-granular encryption.¶

Gap in [RFC8299]:¶

• L3SM defines basic encryption enablement, including specifying the encryption algorithm applied to ESP payloads and specifying PSK applied for peer authentication during the IKE negotiation phase. But L3SM lacks parameters for quantum key distribution (QKD) and post-quantum cryptography (PQC) integration.¶

• The current specification only supports encryption across the CE-to-PE segment. For scenarios where CEs are managed by the operator, customers require encryption service across the whole CE-to-CE path.¶

• The encryption mechanism defined in [RFC8299] only applies to full traffic on access links and operates at a relatively coarse granularity.¶

• Editor's Note: The ce-ce/PE-PE quantum-safe encryption service type for quantum-safe security is TBD.¶

Extensions:¶

Figure 9 illustrates the module augmentation subtree structure of enhanced security.¶

+--rw security
  |  +--rw authentication? string
  |  +--rw encryption {encryption}?
  |  |  +--rw enabled? boolean
  |  |  +--rw layer? enumeration
  |  |  +--rw encryption-profile
  |  |     +--rw (profile)?
  |  |        +--:(provider-profile)
  |  |        |  +--rw profile-name?
  |  |        +--:(customer-profile)* [class-id]
  |  |           +--rw class-id string
  |  |           +--rw algorithm? string
  |  |           +--rw (key-type)?
  |  |           |  +--:(psk)
  |  |           |     +--rw pre-shared-key? string
  |  |           +--rw post-quantum-encryption-config /
                        {post-quantum-encryption}
  |  |              +--rw enable? boolean
  |  |              +--rw quantum-failover-mode? identityref
  |  |              +--ro quantum-encryption-status? identityref
  |  |              +--rw pqc-config
  |  |              |  +--rw enable? boolean
  |  |              +--rw qkd-config
  |  |                 +--rw enable? boolean
  |  |                 +--rw qkd-key-pool-id? string
  |  |                 +--rw key-refresh-interval? uint32

• fine-grained traffic matching: Class-id distinguishes different traffic classification rules for customers. slist contains traffic classification entries for customers, which .The customer-profile container is defined as a list with class-id serving as its list key. Each entry defines the mapping between a class-id and its associated encryption policy.¶

• post-quantum-encryption-config: The post-quantum-encryption-config container aggregates all configuration items associated with post-quantum-encryption and it is gated by the post-quantum-encryption feature.¶

  • The post-quantum-encryption-config container unifies configuration for the two primary categories of quantum-resistant security services: Post-Quantum Cryptography (PQC) and Quantum Key Distribution (QKD).¶

  • If a customer requires both QKD and PQC services simultaneously, operators need to integrate the two quantum-resistant mechanisms. A typical implementation leverages PQC during IKE negotiation, and combines key material derived from PQC with QKD keys to produce the final session symmetric key. This document merely provides an illustrative example and imposes no restrictions on operator-specific implementations. The detailed deployment approach is left to operator.¶

• post-quantum-encryption-enable: Boolean flag for post-quantum-encryption activation, including activation of PQC, QKD, or both. The specific activation policy is left to the operators. For instance, some operators may deploy only PQC, while others adopt QKD or a combination of both.¶

• quantum-failover-mode:Failover behavior when quantum ike-key generation fails (fallback to conventional crypto or terminate).¶

• quantum-encryption-status: a read-only parameter, reports the current operational state of post-quantum encryption.¶

• PQC-config: The PQC-config container aggregates all configuration items associated with PQC-based encryption. At present, only a boolean enable leaf is specified to turn PQC encryption on or off. The PQC-config container can easily be augmented with other configuration parameters in future.¶

• qkd-config: The qkd-config container aggregates all configuration items associated with QKD-based encryption, and can easily be augmented with other configuration parameters.¶

  • qkd-enable: Boolean flag for QKD-based encryption activation.¶

  • key-refresh-interval: this leaf specifies the time interval, measured in seconds, at which the quantum key pool shall automatically refresh its stored quantum keys.¶

  • qkd-key-pool-id: this leaf specify the identifier of a QKD key pool managed by the QKD key management entity (KME). A QKD key pool stores pre-generated symmetric quantum keys shared between paired QKD endpoints. Identical qkd-key-pool-id values shall be configured on both endpoints of any QKD link. For QKD-based encryption deployed over either the CE-to-PE or CE-to-CE segment, the paired endpoints (CE and PE, or CE and CE) shall share the same qkd-key-pool-id.¶