CPAM MIB support for GNEs
Overview
The CPAM supports the limited management of GNEs. The CPAM support of GNEs requires the proper MIB support on GNEs.
The NFM-P mediation engine supports standard MPLS MIBs. The GNEs managed by the NFM-P using standard MIBs must use attributes, IDs and traps in a specific manner to ensure proper operation. Otherwise, LSP objects may be represented incorrectly in the NFM-P. Consider the following regarding GNE standard MIB implementation of MPLS paths.
The NFM-P defines an LSP as an end-to-end path between source and destination label-switched routers. An MPLS path is created when a new mplsTunnel in the mplsTunnelTable is created (a new mpls.Tunnel object announced by a mplsTunnelUp trap). An LSP is also created with an LSP ID corresponding to the mplsTunnelIndex, unless one already exists due to the existence of multiple paths under one LSP.
A route associated with an LSP can be an actual path or a configured path. There can be only one actual path. A configured path contains a primary path, and may also contain multiple secondary and standby paths. The NFM-P groups all of the paths related to an LSP to manage them as a related entity. The GNE must use the same mplsTunnelIndex attribute for a set of primary and standby paths.
The standard MIB does not differentiate between secondary and standby paths, but it does differentiate between primary and secondary paths. The mplsTunnelPrimaryInstance attribute distinguishes the primary from the standby and secondary paths within the LSP. For example, an LSP has three paths (instance 1,2, and 3 respectively) using the same mplsTunnelIndex. Instance 1 is the primary path. The mplsTunnelPrimaryInstance attribute of instance 1 must be set to 0. The mplsTunnelPrimaryInstance attribute is set to 1 for tunnel instances 2 and 3.
The NFM-P relies on the RSVP sessions to determine the hops of the primary and standby paths. Hops are read from the mplsTunnelHopTable and the mplsTunnelARHopTable.
The bit-field attribute “mplsTunnelSessionAttributes” determines whether fast reroute is available. Fast reroute is bit 0. The attribute should be set to 1 or an odd number to identify that the LSP is using fast reroute. Detour or bypass hop records are not supported, because the standard MIB does not provide enough information to associate an RSVP session with a detour of bypass.
The NFM-P triggers a resync of the path when it receives the following traps from the NE:
-
The “mplsTunnelRerouted” trap when a path hop changes.
No “mplsTunnelDown” trap or object deletion should occur.
-
The “mplsTunnelReoptimized” when the path is re-optimized.
No “mplsTunnelDown” trap or object deletion should occur.
-
The “mplsTunnelDown” when a path is down.
A path is configured but the source cannot find a path or cannot successfully signal the path. After a the NFM-P performs the resync, the tunnel should still exist in the tunnel table of the GNE. The path status in the NFM-P is set to Down.
-
The “mplsTunnelUp” trap when the path status is Up.
The path can be successfully signaled. After the NFM-P performs the resync, the tunnel should still exist in the tunnel table of the GNE. The path status in the NFM-P is set to Up.
-
The “mplsTunnelDown” trap when the user deletes a path.
After the NFM-P performs the resync, the tunnel should no longer exist in the tunnel table of the GNE. The path is deleted in the NFM-P and the LSP is deleted if no other path is related to this LSP (no more paths with the same mplsTunnelIndex).
Note: Standard MIBs support read-only mode for the path objects. LSPs or paths can not be configured from the NFM-P.
See “To prepare a GNE for NFM-P management” in the NSP NFM-P Classic Management User Guide for information about how to add a routing MIB to a GNE profile.
© 2023 Nokia. Nokia Confidential Information
Use subject to agreed restrictions on disclosure and use.