Auto tunnel policies
Overview
The NFM-P supports the automatic creation of service tunnels for groups of NEs, using mesh, hub-and-spoke, or ring topology rules. These rules, or auto tunnel policies, define the conditions for the service tunnel creation. An auto tunnel policy has the following components:
-
a rules-based group to define which NEs are part of the tunnel group
-
the topology rules, for example mesh or ring, that specify the service-tunnel characteristics, such as the type of tunnel and the underlying transport.
Tunnel templates
To create a tunnel template, you can create a new XML API template for service tunnel use or you can modify a provided LSP or SDP tunnel template. Use an example as a starting point to create service or tunnel templates with or without format and range policies. When a template with format and range policies is associated with an auto tunnel rule, the format and range policies defined in the template override the name defined in the auto tunnel rule.
Depending on the tunnel type selected for an auto tunnel, an SDP or LSP tunnel template can be selected. For an RSVP LSP tunnel type, one LSP template must be selected. For an RSVP SDP tunnel type, 16 LSP templates can be selected. When an LSP parent template with more than one LSP path child templates is specified, more than one LSP path is created.
A template should be configured to be deployed to a majority of the NE types. The user must validate the template and enter appropriate changes to the script before the template can be deployed in an auto tunnel policy. The parameters that can be modified depend on the template type.
Tunnel groups
A tunnel group is defined as collection of network resources, such as NEs, that perform the same role in the network; for example, the way that the designation of a port as an access or network port defines the role of the port in the network.
By grouping resources by role, a common policy-based management framework can be used to ensure the appropriate configuration of resources, for example, create service tunnels for different topologies.
The following conditions apply to tunnel groups.
-
A group is ordered or unordered depending on the requirements. The members in a group must be ordered when you create some topologies; for example, a ring topology. Topologies such as mesh or hub-and-spoke, in which NEs are not linearly arranged, do not need an ordered group.
-
A non-NFM-P-managed NE can belong to the tunnel group to which it was added, however, it is not active as a destination NE during rule execution.
-
When two or more tunnel groups share an NE, the shared NE performs the roles defined for each group. In Figure 56-1, NE shared by two tunnel groups, Group 1 contains routers NE1, NE2, NE3, and NE4, and Group 2 contains routers NE3, NE5, NE6, and NE7. NE3 is the intersection set of Groups 1 and 2, therefore NE3 assumes the roles defined for Groups 1 and 2.
Figure 56-1: NE shared by two tunnel groups
