Creating an LSP Using the LSR MIB

We now describe the way in which the LSR MIB tables are combined in order to create an LSP. This description is based on that in the IETF draft "Multiprotocol Label Switching (MPLS) Label Switch Router (LSR) Management Information Base." [IETF-LSR-MPLS]. Our goal with the LSP in Figure 8-2 is to carry the non-real -time SMTP traffic through the MPLS cloud. Since there are no stringent real-time requirements, we can make do with a best-effort QoS for the LSP.

We can fulfill these requirements by creating a best-effort, unidirectional LSP segment that originates in a tunnel on the MPLS Edge Router 1 in Figure 8-2 and exits on interface A via an out-segment. This is not a complete LSP (in the end-to-end sense) but rather an LSP segment. Similar segments must be created in the MIBs of the neighboring devices in order to create the full end-to-end LSP. As can be seen from Figure 8-2, interface A has an ifIndex value of 6. The configuration is carried out in three steps. It is important to note that LSPs can be signalled (this takes away many of the manual steps we now describe).

Step 1: Edge Router 1 Cross-Connect and Out-Segment Tables

As we mentioned earlier, three objects are required on an ingress LER:

• A cross-connect

• An out-segment

• A tunnel

We now create one of each of these entities in turn on Edge Router 1.

Edge Router 1 Cross-Connect Creation

A cross-connect entry is required between the tunnel and out-segment objects, respectively. In mplsXCTable , we insert the following values:

 { mplsXCIndex             = 1,  -- The first entry in this table   mplsXCLspId             = '05050501'H, -- 5.5.5.1 IP address of the node   mplsLabelStackIndex     = 0, -- only a single outgoing label   mplsXCIsPersistent      = false (1),   mplsXCRowStatus         = createAndGo(4),   mplsXCAdminStatus       = up(1) } 

An mplsOutSegmentTable row must now be created to point to the appropriate device interface (interface A in Figure 8-2) and any associated traffic parameter (not relevant for our best-effort LSP).

Edge Router 1 Out-segment Creation

Setting mplsInSegmentTrafficParamPtr to zero-dot-zero indicates a best-effort LSP. The same applies to the mplsOutSegmentTrafficParamPtr object. In mplsOutSegmentTable , we create a row with the following values:

 { mplsOutSegmentIndex           = 1,   mplsOutSegmentIfIndex         = 6, -- outgoing interface A   mplsOutSegmentPushTopLabel    = true(1),   mplsOutSegmentTopLabel        = 22, -- outgoing label (fed to adjacent node)   mplsOutSegmentAddrType        =  IPv4(1)   mplsOutSegmentNextHopIpv4Addr = '05050601'H, -- 5.5.6.1, -- Figure 82   mplsOutSegmentXCIndex = mplsXCTable.1, -- Cross-connect just created above   mplsOutSegmentTrafficParamPtr = 0,  -- Best effort   mplsOutSegmentRowStatus       = createAndGo(4) } 

Our cross-connect and out-segment objects are now logically associated with each other. To link this aggregate object to the IP domain, we now need a tunnel.

Edge Router 1 Tunnel Creation

To associate IP traffic with our LSP,we must now create a tunnel. In mplsTunnelTable , we create a row with the following values:

 {     mplsTunnelIndexIndex         = 1,       mplsTunnelInstance           = 1,       mplsTunnelIngressLSRId       = 5.5.5.1,       mplsTunnelEgressLSRId        = 5.5.5.1,       mplsTunnelName               = "LSP",       mplsTunnelDescr              = "Best-effort for SMTP",       mplsTunnelIsIf               = true (1), 

The following setting assigns the cross-connect 1, ingress interface 0, ingress label 0, and out-segment 1 to the mplsTunnelXCPointer column. The LER then decides which tunnel to use. Label 0 indicates that unlabeled IP traffic is to be received.

 mplsTunnelXCPointer      = mplsXCIndex.1.0.0.1,     mplsTunnelSignallingProto    = none (1),     mplsTunnelSetupPrio          = 0,     mplsTunnelHoldingPrio        = 0,     mplsTunnelSessionAttributes  = 0,     mplsTunnelOwner              = snmp (1),     mplsTunnelLocalProtectInUse  = false (0),     mplsTunnelResourcePointer    = 0,     mplsTunnelInstancePriority   = 1,     mplsTunnelHopTableIndex      = 1,     mplsTunnelPrimaryInstance    = 0,     mplsTunnelIncludeAnyAffinity = 0,     mplsTunnelIncludeAllAffinity = 0,    mplsTunnelExcludeAllAffinity = 0,    mplsTunnelRole               = head (1), -- Mandatory parameters needed to activate the row go here    mplsTunnelRowStatus          = createAndGo (4) } 

This completes the configuration required for the creation of an originating LSP on the MPLS Edge Router 1 in Figure 8-2.

We now move to the next node in line, Core Router 1 (Figure 8-2).

Step 2: Core Router 1 Segment and Cross-Connect Tables

We must now create an in-segment, out-segment, and cross-connect on Core Router 1.

Core Router 1 In-segment Creation

In the MIB on Core Router 1, we set the following values in the mplsInSegmentTable :

 { mplsInSegmentIfIndex   = 7, -- interface index (B) value for the transit LSP   mplsInSegmentLabel     = 22, -- incoming label value from Edge Router 1   mplsInSegmentNPop      = 1, -- default value   mplsInSegmentAddrFamily =  IPv4(1)   mplsInSegmentXCIndex = mplsXCTable.6, -- Please see Cross-connect section   mplsInSegmentTrafficParamPtr  = 0,  -- Best effort    mplsInSegmentRowStatus = createAndGo(4) } 

The first two objects mplsInSegmentIfIndex and mplsInSegmentLabel are set to the values 7 and 22, respectively, to tie in with the originating segment of the LSP on Edge Router 1.

Core Router 1 Out-Segment Creation

In mplsOutSegmentTable ,

 { mplsOutSegmentIndex       = 1,   mplsOutSegmentIfIndex     = 8, -- outgoing interface C   mplsOutSegmentPushTopLabel      = true(1),   mplsOutSegmentTopLabel    = 0, -- outgoing label explicit null, 3 = Implicit null   mplsOutSegmentAddrType    =  IPv4(1)   mplsOutSegmentNextHopIpv4Addr = '05050701'H, -- 5.5.7.1, -- Figure 82   mplsOutSegmentXCIndex = mplsXCTable.6, -- Please see Cross-connect section   mplsOutSegmentTrafficParamPtr   = 0,  -- Best effort   mplsOutSegmentRowStatus         = createAndGo(4) } 

The next step consists of configuring the cross-connect table.

Core Router 1 Cross-Connect Creation

A cross-connect entry is now created, thereby associating the newly created segments together. In mplsXCTable , we insert the following values:

 { mplsXCIndex            = 6,    mplsXCLspId           = '05050601'H, -- 5.5.6.1    mplsLabelStackIndex   = 0, -- only a single outgoing label    mplsXCIsPersistent    = false (1),    mplsXCRowStatus       = createAndGo(4),    mplsXCAdminStatus     = up(1) } 

This completes the configuration required for the creation of a transit LSP segment on the MPLS Core Router 1 in Figure 8-2. We now create the last remaining segment on Edge Router 2.

Step 3: Edge Router 2 Cross-Connect and In-Segment Tables

We must now create a cross-connect and in-segment on Edge Router 2.

Edge Router 2 Cross-Connect

In mplsXCTable , we insert the following values:

 { mplsXCIndex            = 8,    mplsXCLspId           = '05050701'H, -- 5.5.7.1    mplsLabelStackIndex   = 0, -- only a single outgoing label    mplsXCIsPersistent    = false (1),    mplsXCRowStatus      = createAndGo(4),    mplsXCAdminStatus    = up(1) } 

Finally, an in-segment must be created.

Edge Router 2 In-segment Table

In the MIB on the Edge Router 2, we set the following values in the mplsInSegmentTable :

 { mplsInSegmentIfIndex    = 9, -- interface (D) index value for the terminating LSP   mplsInSegmentLabel      = 0, -- incoming label value from Core Router 1   mplsInSegmentNPop       = 1, -- default value   mplsInSegmentAddrFamily =  IPv4(1)   mplsInSegmentXCIndex = mplsXCTable.8, -- Please see Cross-connect section   mplsInSegmentTrafficParamPtr    = 0,  -- Best effort   mplsInSegmentRowStatus  = createAndGo(4) } 

The first two objects mplsInSegmentIfIndex and mplsInSegmentLabel are set to the values 9 and 0, respectively, to tie in with the out-segment configuration on Core Router 1.

This completes the configuration required for the creation of a terminating LSP on the MPLS Edge Router 2 in Figure 8-2. After these steps, the LSP looks something like that illustrated in Figure 8-10.

Figure 8-10. Logical description of the LSP.

We now describe a brief walkthrough of what happens to the IP traffic landing on the IP/MPLS boundary on the left-hand side of Figure 8-10:

1. A packet with destination IP address 155.154.4.2 arrives at Edge Router 1 ingress interface.

2. The ingress interface pushes the packet into Tunnel 1.

3. Tunnel 1 serves this IP address via the LSP illustrated in Figure 8-10.

4. The packet is MPLS-encapsulated with the label value 22.

5. Label value 22 is associated with outgoing interface index 6.

6. The MPLS packet is pushed out interface index 6.

7. At Core Router 1, the incoming packet with a label value of 22 arrives at interface index 7.

8. The label value of 22 is used to direct the packet to Core Router 1 interface index 8. The label value of 22 is then replaced with a new label value of zero (explicit nullsome MPLS devices may use 3 for implicit null).

9. The MPLS packet arrives at Edge Router 2 interface index 9 with a label value of zero. The latter is a signal to Edge Router 2 to strip off the label and perform a normal IP lookup.

10. Edge Router 2 forwards the packet to its original destination, the SMTP Gateway at 155.154.4.2.

We now turn to the TE MIB to take a look at the traffic-engineering MPLS objects.

Traffic-Engineered Tunnels

The TE MIB differs from the LSR MIB in a number of ways. The TE MIB provides a model for a traffic-engineered tunnel through an MPLS cloud; in other words, it provides an end-to-end picture. The LSR MIB deals only in terms of segments and cross-connects, and lacks an end-to-end perspective (though use of a signaling protocol, such as LDP, can compensate for this). The only real difference between a tunnel and an LSP is that the former is explicitly routed. Both can reserve resources and (depending on the implementation) both may support IntServ, DiffServ, and any other QoS models.

Tunnels can be created at the head-end (or originating) node (Edge Router 1 in Figure 8-2), and the MIBs for all nodes in the path are automatically updated via a signaling protocol (such as RSVP). This is a powerful facility because it provides a simple way of managing tunnels, using just a few MIB tables. The end result is a traffic-engineered tunnel that traverses an entire network. Tunnels can also be created with or without the assistance of a signaling protocol (such as LDP or RSVP-TE). The TE MIB supports five tables that are used for creating tunnels:

• Tunnel table ( mplsTunnelTable ), used for recording the tunnel parameters

• Resource table ( mplsTunnelResourceTable ), used for configuring end-to-end tunnel resources, such as required bandwidth

• Tunnel hop tables for the specified, actual, and computed route ( mplsTunnelHopTable , mplsTunnelARHopTable , and mplsTunnelCHopTable ) for strict and loose source routed tunnels

The tunnel hops indicate the exact route that will be taken. We now describe these tables.

The mplsTunnelTable

Figure 8-11 illustrates a row from the mplsTunnelTable definition.

Figure 8-11 The MPLS TE tunnel table.

 MplsTunnelEntry ::= SEQUENCE {  1   mplsTunnelIndex             MplsTunnelIndex, -- Index   2   mplsTunnelInstance           MplsTunnelInstanceIndex,   3   mplsTunnelIngressLSRId       MplsLsrIdentifier, Index   4   mplsTunnelEgressLSRId        MplsLsrIdentifier, Index  5   mplsTunnelName               DisplayString, 6   mplsTunnelDescr              DisplayString, 7   mplsTunnelIsIf               TruthValue, 8   mplsTunnelIfIndex            InterfaceIndexOrZero, 9   mplsTunnelXCPointer          RowPointer, 10  mplsTunnelSignallingProto    INTEGER, 11  mplsTunnelSetupPrio          INTEGER, 12  mplsTunnelHoldingPrio        INTEGER, 13  mplsTunnelSessionAttributes  BITS, 14  mplsTunnelOwner              INTEGER, 15  mplsTunnelLocalProtectInUse  TruthValue, 16  mplsTunnelResourcePointer    RowPointer, 17  mplsTunnelInstancePriority   Unsigned32, 18  mplsTunnelHopTableIndex      MplsPathIndexOrZero, 19  mplsTunnelARHopTableIndex    MplsPathIndexOrZero, 20  mplsTunnelCHopTableIndex     MplsPathIndexOrZero, 21  mplsTunnelPrimaryInstance    MplsTunnelInstanceIndex, 22  mplsTunnelPrimaryTimeUp      TimeTicks, 23  mplsTunnelPathChanges        Counter32, 24  mplsTunnelLastPathChange     TimeTicks, 25  mplsTunnelCreationTime       TimeStamp, 26  mplsTunnelStateTransitions   Counter32, 27  mplsTunnelIncludeAnyAffinity MplsTunnelAffinity, 28  mplsTunnelIncludeAllAffinity MplsTunnelAffinity, 29  mplsTunnelExcludeAllAffinity MplsTunnelAffinity, 30  mplsTunnelPathInUse          MplsPathIndexOrZero, 31  mplsTunnelRole               INTEGER, 32  mplsTunnelTotalUpTime        TimeTicks, 33  mplsTunnelInstanceUpTime     TimeTicks, 34  mplsTunnelAdminStatus        INTEGER,  -- Set by the operator 35  mplsTunnelOperStatus         INTEGER,  -- Set by the NE 36  mplsTunnelRowStatus          RowStatus, 37  mplsTunnelStorageType        StorageType } 

Because this is a large table, we inserted line numbers to make the description a little easier to follow. The objects are described as far as possible in related groups.

Tunnel Table Lines 1 to 6

Each row in the tunnel table has a unique index identified by mplsTunnelIndex . This (in conjunction with the value of mplsTunnelInstance ) is how each tunnel is differentiated by the NMS. For tunnel configurations that require protection (or load sharing), a tunnel instance can represent a backup copy of another tunnel. The object mplsTunnelInstance is used for this purpose. The latter then refers to another completely separate entry in the tunnel table. Multiple tunnel instances can also be used for load sharing. Each such tunnel instance can have its own path and reserved resources. The tunnel is also identified in the network by the mplsTunnelIngressLSRId object. The egress router for this tunnel is identified by mplsTunnelEgressLSRId . The tunnel name is mplsTunnelName and is useful (in conjunction with mplsTunnelIndex ) for differentiating between many tunnels on a given node. Other information about the tunnel can be stored in mplsTunnelDescr .

Tunnel Table Lines 7 and 8

A tunnel that corresponds to an interface is indicated by the value of the boolean mplsTunnelIsIf . If mplsTunnelIsIf is set to true, then mplsTunnelIfIndex contains the value of ifIndex from the associated entry in the ifTable .

Tunnel Table Lines 9 and 10

The variable mplsTunnelXCPointer points to a row in the mplsXCTable (not needed for signaled tunnels). The mplsTunnelXCPointer serves to join a tunnel to the cross connect on the ingress node. We saw this in the LSP configuration example. Signaled tunnels store the value of the signaling protocol in mplsTunnelSignallingProto , for example, none(1) and rsvp(2) .

Tunnel Table Lines 11 to 15

The setup priority of the tunnel is stored in mplsTunnelSetupPrio a high value for this means that a tunnel instance may pre-empt (i.e., tear down) another tunnel instance. A related object is mplsTunnelHoldingPrio , which sets the resistance to being torn down by another tunnel instance. Additional characteristics for the tunnel instance are specified in mplsTunnelSessionAttributes ; for instance, isPersistent(2) indicates that this tunnel instance should be restored automatically following a failure (e.g., power down). The tunnel instance creator is indicated by the value of mplsTunnelOwner ; for instance, admin(1) indicates a manual administrator such as an NMS user . mplsTunnelLocalProtectInUse indicates that the tunnel instance can be repaired in the event of a link failure on this node.

Tunnel Table Line 16

The mplsTunnelResourcePointer indicates the entry in the mplsTunnelResourceTable used by this tunnel. Assigning mplsTunnelResourcePointer the value zeroDotZero indicates best-effort treatment. When we create a traffic-engineered tunnel, we will see how the resources are used.

Tunnel Table Line 17

Zero is the lowest value that can be assigned to mplsTunnelInstancePriority . This object can be used to differentiate between groups of tunnel instances; for example, if all instances have the same priority value, then they can load-share traffic with the same destination address.

Tunnel Table Lines 18 to 20

The mplsTunnelHopTableIndex indicates the entry in the hop table used by this tunnel. This indicates the administratively defined, required route for the tunnel. The mplsTunnelARHopTableIndex indicates the entry in the actual hop table used by this tunnel (this indicates the real route through the network taken by the tunnel). The mplsTunnelCHopTableIndex indicates an index into the computed hop table.

Tunnel Table Lines 21 to 25

The primary instance index of this tunnel is indicated by mplsTunnelPrimaryInstance this can be used to logically tie together all the tunnels instances. The time the primary instance has been active is indicated by mplsTunnelPrimaryTimeUp this might be useful for billing and accounting purposes. Changes in the network (such as link failures) may result in a tunnel rerouting; mplsTunnelPathChanges records the number of such changes. The time since the last such path change is recorded in mplsTunnelLastPathChange . The mplsTunnelCreationTime records the value of SysUpTime (a member of the system table illustrated in the example programs in the previous chapter) when the first instance of this tunnel was created.

Tunnel Table Line 26

The overall number of tunnel state transitions (e.g., administrative and operational status changing from up to down) is recorded in mplsTunnelStateTransitions .

Tunnel Table Lines 27 to 29

To provide finer control over which links a tunnel traverses, the mplsTunnelIncludeAnyAffinity constraint can be employed. Links are administratively assigned constraint values (often called colors). The tunnel uses a given link only if either the constraint is zero (i.e., no constraint) or the link fulfills at least one of the specified constraints. For example, in a tunnel that uses only links that have any of the colors gold and silver, any links that have either gold or silver can be included in the tunnel. The object mplsTunnelIncludeAllAffinity is similar except that it specifies the colors that a link must have for inclusion. For example, in a tunnel that uses only links that have all of the colors gold and silver, any links that have both gold and silver can be included in the tunnel. The object mplsTunnelExcludeAllAffinity has similar semantics to mplsTunnelIncludeAllAffinity except that it indicates the constraints that must not be fulfilled. For example, a tunnel that uses only links that do not have all of the colors gold and silver, depending on the implementation, link coloring may only apply to computed-path tunnels. These are tunnels with paths that are ultimately dictated by the network rather than by the values in an ERO.

Service providers could use colors to differentiate servicefor instance, gold service can mean a higher level of service in terms of bandwidth, latency, jitter, and delay.

Tunnel Table Line 30

The mplsTunnelPathInUse object provides an index into the mplsTunnelHopTable and indicates the path that was chosen for the tunnel.

Tunnel Table Lines 31 to 33

The value of mplsTunnelRole reflects the role played by the host node in the overall tunnelan originating tunnel has mplsTunnelRole set to head(1) , a transit tunnel has the value transit(2) , while a terminating tunnel has the value tail(3) . The aggregate up time for all instances of a tunnel is indicated by the value of mplsTunnelTotalUpTime . Similarly, mplsTunnelInstanceUpTime indicates the up time for this tunnel instance.

Tunnel Table Lines 34 and 35

The administratively assigned operational status of the tunnel is indicated by the value of mplsTunnelAdminStatus . This can have values such as up(1) , down(2) , or testing(3) . The actual operational status of the tunnel is indicated by the value of mplsTunnelOperStatus and can have values such as up(1) , down(2) , testing(3) , and unknown(4) .

Tunnel Table Lines 36 and 37

The mplsTunnelRowStatus is used to manage SNMP row operations against an entry in the mplsTunnelTable and has the same semantics as for the other tables. The object mplsTunnelStorageType also follows the usage from other tables.

The mplsTunnelResourceTable

The mplsTunnelResourceTable is used to indicate the resources (bandwidth, burst size, etc.) required for a given tunnel. When the tunnel is created across the network, the required resources are explicitly reserved for its use. An entry in this table is illustrated in Figure 8-12.

Figure 8-12 The MPLS TE tunnel resource table.

 MplsTunnelResourceEntry ::= SEQUENCE {  mplsTunnelResourceIndex                Unsigned32,  -- Index  mplsTunnelResourceMaxRate              MplsBitRate,       mplsTunnelResourceMeanRate             MplsBitRate,       mplsTunnelResourceMaxBurstSize         MplsBurstSize,       mplsTunnelResourceMeanBurstSize        MplsBurstSize,       mplsTunnelResourceExcessBurstSize      MplsBurstSize,       mplsTunnelResourceFrequency            INTEGER,       mplsTunnelResourceWeight               Unsigned32,       mplsTunnelResourceRowStatus            RowStatus,       mplsTunnelResourceStorageType          StorageType } 

The mplsTunnelResourceIndex object uniquely identifies a tunnel resource block (i.e., a row) in this table. The maximum traffic rate is indicated (in units of bits per second) by the value of mplsTunnelResourceMaxRate . The average traffic rate is indicated by mplsTunnelResourceMeanRate . The mplsTunnelResourceMaxBurstSize in bytes specifies the maximum expected burst size. The mplsTunnelResourceMeanBurstSize specifies the average expected burst size. Another important traffic characteristic is mplsTunnelResourceExcessBurstSize . The availability of the tunnel resources is indicated by mplsTunnelResourceFrequency and can have the values unspecified(1) , frequent(2) , or veryFrequent(3) . If the resources are not available at a given point in time, the result might be dropped or marked packets. The latter depends on the underlying platform network hardware. The mplsTunnelResourceWeight indicates the relative weight for using excess bandwidth above the reserved level. The mplsTunnelResourceRowStatus and mplsTunnelResourceStorageType follow the semantics seen in the other tables.

The mplsTunnelHopTable

LSPs can be given pre-assigned routes or paths. These are referred to as Explicit Route Objects (EROs) and serve to indicate a set of hops that is traversed by a tunnel instance. An entry in this table is illustrated in Figure 8-13.

Figure 8-13 The MPLS TE tunnel hop table.

 MplsTunnelHopEntry ::= SEQUENCE {  mplsTunnelHopListIndex          MplsPathIndex,    -- Index   mplsTunnelHopPathOptionIndex    MplsPathIndex,  -- Index   mplsTunnelHopIndex              MplsPathIndex,  -- Index  mplsTunnelHopAddrType           INTEGER,       mplsTunnelHopIpv4Addr           InetAddressIPv4,       mplsTunnelHopIpv4PrefixLen      Unsigned32,       mplsTunnelHopIpv6Addr           InetAddressIPv6,       mplsTunnelHopIpv6PrefixLen      Unsigned32,       mplsTunnelHopAsNumber           Unsigned32,       mplsTunnelHopLspId              MplsLSPID,       mplsTunnelHopType               INTEGER,       mplsTunnelHopIncludeExclude     INTEGER,       mplsTunnelHopPathOptionName     DisplayString,       mplsTunnelHopEntryPathComp      INTEGER,       mplsTunnelHopRowStatus          RowStatus,       mplsTunnelHopStorageType        StorageType } 

New index values in the mplsTunnelHopTable can be obtained from the mplsTunnelHopListIndexNext object. The mplsTunnelHopListIndex object uniquely identifies an ERO in this table. A particular set of hops (called a path option) is indicated by mplsTunnelHopPathOptionIndex . A specific hop in the table is indicated by the value of mplsTunnelHopIndex . The type of a tunnel hop is indicated by mplsTunnelHopAddrType and can have the value ipV4(1) , ipV6(2) , asNumber(3) , or lspid(4) . The value of mplsTunnelHopAddrType dictates the values in the next six objects.

If mplsTunnelHopAddrType is ipV4(1) , then mplsTunnelHopIpv4Addr and mplsTunnelHopIpv4PrefixLen , respectively, contain the value of an IPv4 address and its prefix length. If mplsTunnelHopAddrType is ipV6(2) , then mplsTunnelHopIpv6Addr and mplsTunnelHopIpv6PrefixLen , respectively, contain the value of an IPv6 address and its prefix length. If mplsTunnelHopAddrType is asNumber(3) , then mplsTunnelHopAsNumber contains the autonomous system number of this hop. Finally, if mplsTunnelHopAddrType is lspid(4) , then mplsTunnelHopLspId contains the LSPID of a tunnel of this hop.

The mplsTunnelHopType indicates if this tunnel hop is routed in either a strict (every hop is configured) or loose (where not all hops are configuredthe path may include other networks) fashion.

The mplsTunnelHopIncludeExclude indicates if the current hop is to be excluded from the tunnel route computation. It can have the value include(1) or exclude(2) .

The mplsTunnelHopPathOptionName describes the sequence of hops in relation to the tunnel path. If the operator requires a dynamically computed tunnel path, then the value of mplsTunnelHopEntryPathComp should be set to dynamic(1) . This setting passes the responsibility for path determination over to the network. A value of explicit(2) indicates that the operator is providing the path via an ERO. Finally, the mplsTunnelHopRowStatus and mplsTunnelHopStorageType follow the semantics for these object types in other tables.