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:

• Service tunnels are unidirectional, so they are required in both directions between the source NE and the destination NE.

• The tunnel is not specific to one service or one type of service. After a tunnel exists, multiple SDPs can be aggregated over the tunnel. The SDPs can belong to different services and different customers.

• When a tunnel already exists, the NFM-P does not automatically create a new tunnel, even if the only available tunnel is down. This prevents the creation of multiple inoperable tunnels.

• All services that are mapped to a tunnel use the same transport encapsulation type defined for the tunnel.

• Operations on the tunnel affect all the services that are associated with the tunnel. For example, the operational and administrative states of a tunnel control the state of service circuits that are carried on the tunnel. In the case of LSP-based tunnels, an LSP can be replaced in the tunnel without reconfiguring each service bound to the tunnel.

• A service tunnel is locally unique to an NE. The same tunnel ID can appear on other NEs.

• A service tunnel uses the system IP address to identify the far-end edge NE.

• When a newly created service tunnel terminates on a local loopback network interface of the base routing instance, the topology map shows the tunnel terminating on a managed NE. If the service tunnel destination address is provisioned with an IP address from an IES or VPRN interface, the tunnel is shown as terminating on unmanaged NE.

• A service tunnel can be configured using a tunnel template. A user who is assigned the create tunnel template scope of command role can create a tunnel template. The template manager can also apply the tunnel template to a service tunnel.

• An SDP tunnel template can be applied to an auto tunnel policy.

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:

• Class-based forwarding is typically implemented using the service tunnel configuration forms, as detailed in To create an IP/MPLS service tunnel . Class-based forwarding configurations can also be altered after their initial creation by editing the service tunnel configuration form as detailed in To view and manage service tunnels and tunnel elements .

• An LSP can carry packets of a forwarding class for one service and at the same time, carry packets of a different forwarding class for another service. In other words, the same LSP can be used by more than one SDP, even where the forwarding class assignments are different.

• Within an SDP, only one LSP can support a specific CoS.

• A service instance (or service site) can be bound to SDPs of differing CoS configurations, as well as regular SDPs.

• One LSP in the SDP must be designated as the default LSP. The default LSP is used by the SDP if there is no available LSP that matches the packet's forwarding class. When the default LSP is down, the SDP is also brought down.

• Class-based forwarding can be applied to all services supported by the SRs. For VPLS, you can specify an LSP to forward all multicast/broadcast packets (by default, the default LSP is used). For VLL, shared queuing must be enabled on the ingress SAP to support the class-based forwarding.

• Class-based forwarding is configurable on the 7750 SR, 7450 ESS, and 7950 XRS.