Traffic engineering (TE) links are configured under the config>router>lmp with a specific command, te-link, to create a specific context to hold TE specific configuration information pertinent to the local and remote identifiers, and physical resources assigned to the te-link. Only one data bearer per TE link is supported.
The te-link association is the creation of an association between a TE-link and data-bearing physical ports. Under the TE-link context, different data bearers can be configured via the data-bearer command. The data bearer is assigned a complete physical port, using port<x/y/z> (slot-number/MDA-number/port-number) as input.
Note that a data bearer cannot be associated with a port in a LAG.
A TE-link has a unique link-id, which identifies it in RSVP-TE signaling.
The remote-id is the unnumbered link identifier at far-end of the TE link as advertised by the LMP peer that is the UNI-N.
The TE-link has associated physical resources which are assigned to the TE-link by configuring the data-bearer under the config>router>te-link context.
The operator must also configure the remote data-bearer link identifier under the data bearer subcontext.
Note that LMP does not correlate the local and remote Layer 2 interface identifiers (such as MAC addresses) for the data bearer. It only correlates the local and remote TE Link and Data Bearer link identifiers. The association between the Layer 2 interface address and the data bearer must be correctly configured at the UNI-C and UNI-N. The show>router>lmp>te-link command displays the local link ID, remote link ID, and associated port ID to assist with this.
The CLI tree for creating TE Links under LMP is as follows. Note that there are also some RSVP-specific TE Link parameters that are configured under a separate gmpls context (see below):
config
router
[no] lmp
[no] te-link te-link-id
link-name te-link-name
remote-id id
[no] data-bearer data-bearer-id
port port-id
remote-id id
[no] shutdown
[no] shutdown
[no] shutdown
The te-link-id can take the form of an unsigned integer or 64 character (max) name: [1 to 2147483690] | te-link-name: 64 char max
Upon creation, only the unsigned integer needs to be specified. After the link is created the user can configure the link name (for example, link-name te-link-name). From here, the user can refer to this te-link by either the unsigned integer or the ASCII name.
Note that LMP normally assumes a data bearer is operationally up, even if no MAC layer or a valid PCS IDLE stream is received. This is because a neighboring UNI-N may not generate a PCS IDLE stream and instead transparently transports the MAC layer from the far end, which is not up unless a gLSP is configured. To prevent LMP from using a port for which there is a local fault on the data bearer, indicated by loss of light, a user must configure report-alarm on the Ethernet port, as follows:
config>port>ethernet>report-alarm signal-fail
Only ports with report-alarm signal-fail configured can be included in LMP, and that report-alarm signal-fail cannot be subsequently removed from a port in LMP.
RSVP requires that all traffic engineering attributes for TE Links are configured under the config>router>gmpls>te-link context.
config
router
[no] gmpls
te-link te-link-id
[no] shutdown
where te-link-id: [1..2147483690] | te-link-name: 32 char max
If a path (also see the description of a GMPLS path configuration, below) without an explicit te-link for the first hop is configured, the system automatically selects a TE Link to use for a gLSP path based on the lowest available TE Link ID with a matching bandwidth (if a bandwidth is configured for the gLSP). During a data-bearer link allocation request, an RSVP -requested gLSP BW could be either a non-zero value as per RFC 3471 signal-type (see below), or it could be zero. These are the following cases.
Case 1: requested BW is non-zero as per RFC 3471 Signal-type configuration
When a TE (or TE/DB) link is configured in the related hop LMP checks whether the related port BW is the same (exact match) as the requested BW, and allocates the port (provided any other checks are successful).
When the related Hop is empty, LMP finds a db-link port to the peer with a matching the requested BW, and allocates it.
Case 2: requested BW is Zero
When TE (or TE/DB) link is configured in the related hop, LMP allocates the port (provided the other checks are OK), and provides the port BW to RSVP to use in signaling.
When the related Hop is empty, LMP finds the first available db-link to the peer (based on lower db-link Id), and allocates it and provides the port BW to RSVP to use in signaling.