In some deployments, operators may select to redirect ESM subscribers to Value Added Services (VAS). Various deployment models can be used but often subscribers are assigned to a specific residential tier-of-service, which also defines the VAS available to subscribers of the specific tier. The subscribers are redirected to VAS based on tier-of-service rules but such an approach can be hard to manage when many VAS services/tiers of service are needed. Often the only way to identify a subscriber’s traffic with a specific tier-of-service is to preallocate IP/IPv6 address pools to a specific service tier and use those addresses in VAS PBR match criteria. This creates an application-services to network infrastructure dependency that can be hard to overcome, especially if fast and flexible application service delivery is needed.
Filter policy-based ESM service chaining removes ESM VAS steering to network infrastructure inter-dependency. An operator can configure per tier of service or per individual VAS service upstream and downstream service chaining rules without a need to define subscriber or tier-of-service match conditions. Figure: ACL filter modeling for ESM service chaining shows a possible ACL model (embedded filters are used for VAS service chaining rules).
On the left in Figure: ACL filter modeling for ESM service chaining, the per-tier-of-service ACL model is depicted. Each tier of service (Gold or Silver) has a dedicated embedded VAS filter (‟Gold VAS”, ‟Silver VAS”) that contains all steering rules for all service chains applicable to the specific tier. Each VAS filter is then embedded by the ACL filter used by a specific tier. A subscriber is subject to VAS service chain rules based on the per-tier ACL assigned to that subscriber (for example, via RADIUS). If a new VAS rule needs to be added, an operator must program that rule in all applicable tiers. Upstream and downstream rules can be configured in a single filter (as shown) or can use dedicated ingress and egress filters.
On the right in Figure: ACL filter modeling for ESM service chaining, the per-VAS-service ACL model is depicted. Each VAS has a dedicated embedded filter (‟VAS 1”, ‟VAS 2”, ‟VAS 3”) that contains all steering rules for all service chains applicable to that VAS service. A tier of service is then created by embedding multiple VAS-specific filters: Gold: VAS 1, VAS 2, VAS 3; Silver: VAS 1 and VAS 3. A subscriber is subject to VAS service chain rules based on the per-tier ACL assigned to that subscriber. If a new VAS rule needs to be added, an operator needs to program that rule in a single VAS-specific filter only. Again, upstream and downstream rules can be configured in a single filter (as shown) or can use dedicated ingress and egress filters.
Figure: Upstream ESM ACL policy-based service chaining shows upstream VAS service chaining steering using filter policies. Upstream subscriber traffic entering Res-GW is subject to the subscriber's ingress ACL filter assigned to that subscriber by a policy server. If the ACL contains VAS steering rules, the VAS-rule-matching subscriber traffic is steered for VAS processing over a dedicated to-from-access VAS interface in the same or a different routing instance. After the VAS processing, the upstream traffic can be returned to Res-GW by a to-from-network interface (shown in Figure: Upstream ESM ACL policy-based service chaining) or can be injected to WAN to be routed toward the final destination (not shown).
Figure: Downstream ESM ACL-policy based service chaining shows downstream VAS service chaining steering using filter policies. Downstream subscriber traffic entering Res-GW is forwarded to a subscriber-facing line card. On that card, the traffic is subject to the subscriber's egress ACL filter policy processing assigned to that subscriber by a policy server. If the ACL contains VAS steering rules, the VAS rule-matching subscriber's traffic is steered for VAS processing over a dedicated to-from-network VAS interface (in the same or a different routing instance). After the VAS processing, the downstream traffic must be returned to Res-GW via a ‟to-from-network” interface (shown in Figure: Downstream ESM ACL-policy based service chaining) to ensure the traffic is not redirected to VAS again when the subscriber-facing line card processes that traffic.
Ensuring the correct settings for the VAS interface type, for upstream and downstream traffic redirected to a VAS and returned after VAS processing, is critical for achieving loop-free network connectivity for VAS services. The available configuration options (config>service>vprn>if>vas-if-type, config>service>ies>if>vas-if-type and config>router>if>vas-if-type) are described below:
deployments that use two separate interfaces for VAS connectivity (recommended, and required if local subscriber-to-subscriber VAS traffic support is required)
to-from-access
upstream traffic arriving from subscribers over access interfaces must be redirected to a VAS PBR target reachable over this interface for upstream VAS processing
downstream traffic destined for subscribers after VAS processing must arrive on this interface, so that the traffic is subject to regular routing but is not subject to Application Assurance diversion, nor to egress subscriber PBR
the interface must not be used for downstream pre-VAS traffic; otherwise, routing loops occur
to-from-network
downstream traffic destined for subscribers arriving from network interfaces must be redirected to a VAS PBR target reachable over this interface for downstream VAS processing
upstream traffic after VAS processing, if returned to the router, must arrive on this interface so that regular routing can be applied
deployments that use a single interface for VAS connectivity (optional, no local subscriber-to-subscriber VAS traffic support)
to-from-both
-
both upstream traffic arriving from access interfaces and downstream traffic arriving from the network are redirected to a PBR target reachable over this interface for upstream/downstream VAS processing
-
after VAS processing, traffic must arrive on this interface (optional for upstream), so that the traffic is subject to regular routing but is not subject to AA diversion, nor to egress subscriber PBR
-
the interface must be used for downstream pre-VAS traffic, otherwise, routing loops occur
-
The ESM filter policy-based service chaining allows operators to do the following:
Steer upstream and downstream traffic per-subscriber with full ACL-flow-defined granularity without the need to specify match conditions that identify subscriber or tier-of-service
Steer both upstream and downstream traffic on a single Res-GW
Flexibly assign subscribers to tier-of-service by changing the ACL filter policy a specific subscriber uses
Flexibly add new services to a subscriber or tier-of-service by adding the subscriber-independent filter rules required to achieve steering
Achieve isolation of VAS steering from other ACL functions like security through the use of embedded filters
Deploy integrated Application Assurance (AA) as part of a VAS service chain—both upstream and downstream traffic is processed by AA before a VAS redirect
Select whether to use IP-Src/IP-Dst address hash or IP-Src/IP-Dst address plus TCP/UDP port hash when LAG/ECMP connectivity to DC is used. Layer 4 inputs are not used in hash with IPv6 packets with extension headers present.
ESM filter policy-based traffic steering supports the following:
IPv4 and IPv6 steering of unicast traffic using IPv4 and IPv6 ACLs
action forward redirect-policy or action forward next-hop router for IP steering with TCAM-based load-balancing, -to-wire, and sticky destination
action forward esi sf-ip vas-interface router for an integrated service chaining solution
Operational notes:
Downstream traffic steered toward a VAS on the subscriber-facing IOM is reclassified (FC and profile) based on the subscriber egress QoS policy, and is queued toward the VAS based on the network egress QoS configuration. Packets sent toward VAS do not have DSCP remarked (becasue they are not yet forwarded to a subscriber). DSCP remarking based on subscriber's egress QoS profile only applies to traffic ultimately forwarded to the subscriber (after VAS or not subject to VAS).
If mirroring of subscriber traffic is configured using ACL entry/subscriber/SAP/port mirror, the mirroring applies to traffic ultimately forwarded to subscriber (after VAS or not subject to VAS). Traffic that is being redirected to VAS cannot be mirrored using an ACL filter implementing PBR action (the same egress ACL filter entry being a mirror source and specifying egress PBR action is not supported).
Use dedicated ingress and egress filter policies to prevent accidental match of an ingress PBR entry on egress, and the other way around, that results in forwarding or dropping of traffic matching the entry (based on the filter's default action configuration).
Restrictions:
This feature is not supported with HSMDAs on subscriber ingress.
This feature is not supported when the traffic is subject to non-AA ISA on Res-GW.
Traffic that matches an egress filter entry with an egress PBR action cannot be mirrored, cannot be sampled using cflowd, and cannot be logged using filter logging while being redirected to VAS on a sub-facing line card.
This feature is not supported with LAC/LNS ESM (PPPoE subscriber traffic encapsulated into or de-encapsulated from L2TP tunnels).
This feature is not supported for system filter policies.