Any traffic can be diverted for application-aware processing. AA is enabled through the assignment of an application profile as part of either an enhanced subscriber management or static configuration. This process enables the AA functionality for all traffic of interest to and from a subscriber, SAP or spoke SDP. Which traffic is deemed of interest, is configured through an AA ISA group-specific configuration of forwarding classes (FCs) to be diverted to AA and enabled on a per subscriber, SAP, spoke SDP using application profiles.
Figure: Application Assurance ingress datapath shows the general mechanism for filtering traffic of interest and diverting this traffic to the appropriate AA ISA module residing on an IOM (referred as the host IOM). This traffic management divert method applies to both bridged and routed configurations.
For a SAP, subscribers with application profiles enabling AA, the traffic is diverted to the active AA ISA using ingress QoS policy filters, identifying forwarding and sub-forwarding classes that could be diverted to the AA. Only single point (SAP, ESM, or DSM subscriber, spoke SDP) configuration is required to achieve divert for both traffic originated by and destined for an AA subscriber. Diversion (divert) to the AA ISA is conditional based on the AA ISA status (enabled, failed, bypassed, and so on).
Unless the AA subscriber’s application profile is configured as ‟divert” using Application Profiles and the FC is selected to be diverted as well, the normal ingress forwarding occurs. Traffic that is filtered for divert to AA ISAs is placed in the appropriate location for that system’s AA ISA destination.
Users can leverage the extensive QoS capabilities of the router when deciding what IP traffic is diverted to the AA system for inspection. Through AA ISA group-wide configuration, at least one or more QoS forwarding classes with the ‟divert” option can be identified. The forwarding classes can be used for any AA subscriber traffic the service provider wants to inspect with AA.