The BANDWIDTH Policy Criterion specifies a rate (bandwidth) commitment and a rate limit on an Application Flow or Application Flow Group. The value of the BANDWIDTH Policy Criterion is a 2-tuple (commit, max) where:
In both cases, the average information rate is calculated over a time interval determined by the Service Provider and referred to in the following requirements as the “averaging interval”. Specifying commit=none is equivalent to commit=0, i.e., there is no bandwidth committed to the Application Flow. Specifying max=none is equivalent to max=∞, i.e., there is no maximum imposed on the Application Flow (up to the limits imposed by the UNI speed and Underlay Connectivity Service capacity). There is an expectation that the Subscriber and the Service Provider have agreed on sufficient Underlay Connectivity Service capacity so that the bandwidth committed to all Application Flows can be met. How the average information rates are determined and the behavior of the rate limiting function are described below. The BANDWIDTH Policy Criterion when applied to an Application Flow Group operates differently than other Policy Criteria. For all other Policy Criteria applied to an Application Flow Group, the Policy Criteria are simply applied to the members of the group (that don’t have their own explicit Policy assignment). For the BANDWIDTH Policy Criterion, the specified bandwidth limits apply to all members of the group (that don’t have their own explicit Policy assignment) in the aggregate. In other words, all of those group members share the bandwidth limits specified in the Policy and are treated as a single flow for the purpose of determining the bandwidth. The remainder of this section uses the term Application Flow to refer to both a single Application Flow and an aggregated Application Flow Group “flow”. The effect of metering a stream of IP Packets – that is, comparing the actual sequence of IP Packets to the description in terms of the BANDWIDTH Policy Criterion parameters – is to declare each packet either conformant or non-conformant. This information can be used to take further action, for example policing or shaping. The combined effect is such that each packet has one of three outcomes:
This document does not constrain the implementation of the bandwidth limiting by the Service Provider, nor does it constrain where the bandwidth limiting is implemented, i.e., the metering point. The following requirements define the behavior imposed by the BANDWIDTH Policy Criterion using the parameters commit, and max. [R35] The average information rate for IP Packets in an Application Flow that are declared conformant MUST be at least the lower of the average information rate for IP Packets that pass the metering point in Application Flow over a time interval equal to the averaging interval and commit. [O2] IP Packets in an Application Flow MAY be declared non-conformant in order to ensure that the average information rate for such packets over any time interval equal to the averaging interval that are declared conformant is, at most, max. [O3] IP Packets in an Application Flow MAY be declared non-conformant in order to ensure that the average information rate for IP Packets across all Application Flows at a UNI does not exceed the available capacity of the Underlay Connectivity Services at that UNI. [O4] If, given the traffic received for various Application Flows with various Policies applied, the traffic that needs to be forwarded over a given Underlay Connectivity Service in order to meet all of the Policies exceeds the capacity of that Underlay Connectivity Service, IP Packets in the affected Application Flows MAY be declared non-conformant. When the total amount of traffic received at an SD-WAN UNI exceeds the available capacity of the associated Underlay Connectivity Services, some packets may need to be discarded, even though each individual Application Flow is operating below the maximum specified in the BANDWIDTH Policy Criterion. It is at the Service Providers discretion which packets to discard, so long as each Application Flow still gets its committed rate. For example, they might discard an equal number of packets from each Application Flow, or they might drop as many packets as possible from a single Application Flow. Similarly, even when the total amount of traffic is less than the total available capacity on the Underlay Connectivity Services, the combination of traffic across different Application Flows with different policies might mean that the traffic that needs to be forwarded over a given Underlay Connectivity Service exceeds its capacity. Again, in that case, it is at the Service Providers discretion which packets to discard. [R36] An IP Packet in an Application Flow MUST be declared conformant unless it is declared non-conformant by a condition specified in [O2], [O3], or [O4]. |