IP/MPLS service tunnels

Overview

Distributed service traffic is transported between PE NEs by circuits aggregated in unidirectional service tunnels.

The operational theory of a service tunnel is that the encapsulation of the data between the two managed edge NEs appears as a Layer 2 path to the service data although it is really traversing an IP or IP/MPLS core.

Tunnel policies from older releases can be converted to the newer template-based policies by using a “Convert” button located on the rule configuration form. You cannot configure CoS forwarding, LDP-over-RSVP, or multiple LSP bindings on SDP features.

A service tunnel uses GRE or MPLS encapsulation. For MPLS, a mesh of MPLS paths and LSPs must be present in the network core. You associate service tunnels with LSPs during service tunnel configuration. The NFM-P supports LSP creation using a basic LDP variant such as T-LDP, or using LDP over RSVP for tunnel-in-tunnel functionality based on traffic classification.

An NFM-P operator binds a service site to a service tunnel during service configuration. A service tunnel has a unique ID on an NE and cannot be deleted when it is currently associated with a service.

ACL IP and ACL MAC policy filters for service tunnels contain options for forwarding packets on a specific service tunnel based on matching criteria, as described in Chapter 51, Filter policies .

IP/MPLS service tunnels design considerations

Consider the following before you configure IP/MPLS service tunnels:

See the appropriate device documentation for more detailed information about service tunnels.

Class-based forwarding

Packets of the same CoS and service are forwarded over a specific RSVP LSP (or a static LSP), which is part of an SDP that the service (instance) is bound to. The forwarding decision is based on the forwarding class of the packet, as assigned by the ingress QoS policy defined for the SAP.

When implementing class-based forwarding, consider the following: