The SWVC List of Application Flows Service Attribute specifies the Application Flows that can be recognized by the SD-WAN service and information about how to identify IP Packets in each Application Flow. The value of the Service Attribute is a non-empty ordered list of 3-tuples (appName, appCL, appGroup) where:
appName is an Identifier String that is used to refer to the Application Flow.
appCL is a non-empty list of Application Flow Criteria 2-tuples of the form where:
ACName is an Identifier String containing an Application Flow Criterion Name from Table 4 or other Service Provider Application Flow Criterion Name.
ACValue contains the parameter values specific to the Application Flow Criterion specified in ACName. If there are no parameter values, ACValue is none.
appGroup is an Application Flow Group name contained in the value of the SWVC List of Application Flow Groups Service Attribute or none if the Application Flow is not a member of an Application Flow Group.
[R41] Each Application Flow name, appName, in the value of the SWVC List of Application Flows Service Attribute MUST appear, at most, once.
[R42] Each Application Flow name, appName, in the value of the SWVC List of Application Flows Service Attribute MUST NOT be the same as an Application Flow Group Name in the value of the SWVC List of Application Flow Groups Service Attribute.
[R43] If the appCL element in an entry of the SWVC List of Application Flows Service Attribute contains more than one Application Flow Criterion, an Ingress IP Packet MUST match all Application Flow Criteria in order to be associated with the Application Flow.
[R44] Each Ingress IP Packet MUST be assigned to the first Application Flow in the value of the SWVC List of Application Flows Service Attribute whose Application Flow Criteria it matches, if any.
[R45] Any Ingress IP Packet that cannot be associated with an Application Flow from the value of the List of Application Flows Service Attribute MUST be discarded.
As shown in the example later in this section, the criteria for one Application Flow can be a subset of the criteria for another Application Flow, so the order that the Application Flows are matched, and hence the order of the Application Flow definitions in the value of this Service Attribute is important, and is one aspect of the agreed value of this Service Attribute.
[R43] indicates that the Application Flow is defined by the conjunction of a set of Application Flow Criteria. This doesn’t allow for alternatives within an Application Flow. This is partially mitigated by the fact that many of the Criteria are ranges or lists of values. Also, the Application Flow Group can provide alternatives. For example, one Application Flow can have criteria X and Y, and a second Application Flow can have criteria X and W. If the two Application Flows are put into an Application Group, a common Policy can be applied to the Group and the two Applications can share bandwidth resources, so it appears (almost) like a single Application Flow defined as (X and Y) or (X and W).
[R46] Application Flow Criteria that can be used to describe Application Flows MUST include the Criteria listed in Table 4, except for APPID.
Table 4 – Required Application Flow Criteria
Table 4 includes all of the basic layer 2 through layer 4 fields that all implementations are expected to be able to match against Ingress IP Packets. The exception is the APPID Criterion. The APPID Policy Criterion provides the ability for the Service Provider to define and name both simple and complex matches. These can include standard matches available to all of the Service Provider’s Subscribers from a catalog and/or custom matches developed by the Service Provider by agreement with a particular Subscriber.
APPID matches could be simple protocol matches (that could be accomplished with the other Criteria such as DPORT) such as “SSH” or “SNMP” or “RTP”, but they can also support deeper inspection of packets such as “SNMP GET NEXT” or “HTTP POST” or “TWAMP  STOP-SESSION”.
[R47] If the Service Provider defines an APPID (either a standard or a custom match), the description provided to the Subscriber MUST include the following information:
The Application Identifier
Addition Arguments Required (beyond the Identifier)
Description of the operational logic of the match including the fields that are inspected, the values that they are matched against, and any additional logic associated with the match (e.g., dependencies).
Complex matches, for example, using deep packet inspection, often require inspection of several initial packets and may include heuristics to define the characteristics of the Application Flow. These details are included in the description of the matching logic required by [R47].
An APPID with name SIP: There are no additional arguments required, and the match is performed by inspecting the TCP or UDP source and destination port for value 5060 or 5061.
An APPID named SIPUSER: This includes an additional argument “user-id”. The operation of this match is the same as SIP with the addition that if the port match is successful, the SIP To and From fields are matched against the “user-id”.
The Application Flow Criterion ANY matches all IP Packets. This criterion allows an Application Flow to be defined that includes all “unmatched” IP Packets and assign a Policy to that Application Flow. In general, if this Application Flow Criterion is used, it should be in the last Application Flow definition in the list, since no IP Packets are matched against subsequent Application Flow definitions.
[R48] If an entry in the value of the SWVC List of Application Flows Service Attribute includes the Application Flow Criterion ANY, that entry MUST NOT contain any other Application Flow Criteria.
Following is an example value for this Service Attribute with four Application Flows:
In this example, Application Flow Peach includes packets from any 192.168.7.x address destined to port 80 or 443 or 8080 (and this flow is in the group round). Application Flow VOIP includes packets that are matched by the built in “RTP” flow match. Application Flow Banana is any packet to port 80 that is not matched by Peach, and this flow is in group long. At the end of the list is the Application Flow Else, which includes all IP Packets not matched by the other three.
In this example, it is important that Banana is after Peach because it matches a subset of Peach. If Banana were first, then port 80 packets would never be assigned to Application Flow Peach.