Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Understanding TE++ Label-Switched Paths on the NorthStar Controller

    A TE++ tunnel includes a set of paths that are configured as a specific container statement and individual label-switched path (LSP) statements that are called sub-LSPs. A TE++ tunnel enables load balancing across multiple point-to-point member LSPs between the same ingress and egress routers. When the path bandwidth is sufficient, the member LSPs, each of which has equal bandwidth, will take the same best path. However, if the bandwidth is overloaded on the original path, some member LSPs will take an alternate path.

    Based on the configuration and aggregate traffic, a container LSP provides support for dynamic bandwidth management by enabling the ingress router to dynamically add and remove member LSPs through a process called LSP splitting and LSP merging, respectively. Member LSPs can also be re-optimized with different bandwidth values in a make-before-break way.

    Note: TE++ functionality is supported only on Juniper Network routers.

    A process called normalization occurs when the following two triggers are initiated that will cause an LSP to be resized:

    • A periodic retry timer— When this fires, the container LSP is checked to see if it came up with the last normalization result (the number of members, per member bandwidth) If not, the number of members is incremented and retried. When the retry limit is reached, the work-in-progress member LSP that is set from the last retry is accepted for forwarding, if it improves routing of LSPs compared to the current member-set contributing to the next hop (in incremental normalization mode). If the mode is set to no-incremental and the retry limit is reached, the current set is retained and the intermediate set of signaled members is reverted. Normalization retry duration is greater than the regular LSP retry duration.
    • Bandwidth thresholds are reached.

    When these triggers are initiated, one of the following events occur:

    • The LSP requires no change.
    • LSP splitting—An LSP is added and bandwidth is redistributed across all LSPs.
    • LSP merging—An LSP is deleted and bandwidth is redistributed across all remaining LSPs.

    TE++ is supported on the following types of LSPs:

    • Router controlled TE++ LSP—For these LSPs, the controller’s objective is to learn the sub-LSPs. The association object is used to report the LSP container and the sub-LSPs. Statistical accounting for bandwidth for the sub-LSPs is performed at the PCC and based on the bandwidth threshold triggers, the resizing of LSPs is performed from the PCC, and the NorthStar Controller is updated accordingly.
    • Delegated TE++ LSP—Like auto-bandwidth, the bandwidth accounting for these LSPs is performed at the PCC. When the thresholds are reached, the PCC determines how to resize the sub-LSPs and issues LSPs a PCReq message to the PCS server to compute the Explicit Route Object (ERO). The PCS server responds by sending a new ERO and bandwidth to the PCC, which the PCC will apply to the TE++ LSP. Each sub-LSP is delegated by sending PCRpt messages, which are sent with the Delegation bit set. The association object carried in the PCRpt message binds the sub-LSPs to a TE++ container.

      Note: As is also true for LSPs with auto-bandwidth enabled, to avoid the potential multiple writer issue, the Northstar Controller is not allowed to modify the bandwidth of a TE++ LSP that has auto-bandwidth enabled, but unlike auto-bandwidth LSPs, where a PCC sends an error back when bandwidth is changed on the controller, the controller is aware of the presence of TE++ LSPs, so the Path Computation Server (PCS) does not allow changing the bandwidth for TE++ LSPs on the NorthStar Controller.

    Note: The NorthStar Controller does not support controller-created TE++ LSPs.

    When a TE++ LSP is configured as externally controlled, local path computation is disabled, and an association object is created. Any time a TE++ LSP is configured, the sub-LSPs operational state will be down because the PCC expects the PCE (NorthStar Controller) to send an ERO . To trigger this operation, the PCC sends a PCReq (request) message. In turn, the NorthStar Controller sends a PCRep (response) message with the ERO to the PCC, which is signaled with RSVP-TE. The signaled state of the LSP is then reported using a PCRpt message to the NorthStar Controller. The PCRpt message carries the association object that binds the sub-LSPs to a container. This same mechanism is applied any time existing TE++ LSPs are delegated.

    For TE++ LSPs, path computation for all the sub-LSPs is a dependent, collective operation that cannot be performed individually. For example, if only 25 mbps of available bandwidth is available and the PCC requests six LSPs of 5 Mbps each, the setup of the TE++ LSP should fail. If each path is computed independently, the result is five paths of 5 Mbps each. Because TE++ path computation is for all TE++ LSPs (or no TE++ LSPs), path computation must be performed collectively.

    The synchronization of a set of path computation requests is achieved by using the Synchronization VECtor (SVEC) object, defined in RFC 5440, which allows a PCC to request the synchronization of a set of dependent or independent path computation requests.

    Modified: 2016-04-28