Current Mpls Rsvp-Te Limitations - Juniper ACX1000 Configuration Manual

Junos os; acx series universal access router
Hide thumbs Also See for ACX1000:
Table of Contents

Advertisement

ACX Series Universal Access Router Configuration Guide
694
LSP tunnels are a way to establish unidirectional label-switched paths. RSVP-TE builds
on the RSVP core protocol by defining new objects and modifying existing objects used
in the PATH and RESV objects for LSP establishment. The new objects—LABEL-REQUEST
object (LRO), RECORD-ROUTE object (RRO), LABEL object, and EXPLICIT-ROUTE object
(ERO)—are optional with respect to the RSVP protocol, except for the LRO and LABEL
objects, which are both mandatory for establishing LSP tunnels.
In general, RSVP-TE establishes a label-switched path that ensures frame delivery from
ingress to egress router. However, with the new traffic engineering capabilities, the
following functions are supported in an MPLS domain:
Possibility to establish a label-switched path using either a full or partial explicit route
(RFC 3209).
Constraint-based LSP establishment over links that fulfill requirements, such as
bandwidth and link properties.
Endpoint control, which is associated with establishing and managing LSP tunnels at
the ingress and egress routers.
Link management, which manages link resources to do resource-aware routing of
traffic engineering LSPs and to program MPLS labels.
MPLS fast reroute (FRR), which manages the LSPs that need protection and assigns
backup tunnel information to these LSPs.

Current MPLS RSVP-TE Limitations

Although the RSVP extensions for traffic engineering enable better network utilization
and meet requirements of classes of traffic, today's MPLS RSVP-TE protocol suite has
several issues inherent to its distributed nature. This causes a number of issues during
contention for bisection capacity, especially within an LSP priority class where a subset
of LSPs share common setup and hold priority values. The limitations of RSVP-TE include:
Lack of visibility of individual per-LSP, per-device bandwidth demands—The ingress
routers in an MPLS RSVP-TE network establish LSPs without having a global view of
the bandwidth demand on the network. Information about network resource utilization
is only available as total reserved capacity by traffic class on a per interface basis.
Individual LSP state is available locally on each label edge router (LER) for its own
LSPs only. As a result, a number of issues related to demand pattern arise, particularly
within a common setup and hold priority.
Asynchronous and independent nature of RSVP signaling—In RSVP-TE, the constraints
for path establishment are controlled by an administrator. As such, bandwidth reserved
for an LSP tunnel is set by the administrator and does not automatically imply any
limit on the traffic sent over the tunnel. Therefore, bandwidth available on a traffic
engineering link is the bandwidth configured for the link, excluding the sum of all
reservations made on the link. Thus, the unsignaled demands on an LSP tunnel lead
to service degradation of the LSP requiring excess bandwidth, as well as the other
LSPs that comply with the bandwidth requirements of the traffic engineering link.
LSPs established based on dynamic or explicit path options in the order of
preference—The ingress routers in an MPLS RSVP-TE network establish LSPs for
Copyright © 2017, Juniper Networks, Inc.

Hide quick links:

Advertisement

Table of Contents
loading

This manual is also suitable for:

Acx5048Acx5096Acx500Acx1100Acx2000Acx2100 ... Show all

Table of Contents