•
Interaction Between a PCE and a PCC Using PCEP on page 698
•
LSP Behavior with External Computing on page 701
•
Configuration Statements Supported for External Computing on page 702
•
PCE-Controlled LSP Protection on page 703
•
PCE-Controlled LSP ERO on page 703
•
PCE Controlled Point-to-Multipoint RSVP-TE LSPs on page 704
•
Auto-Bandwidth and PCE-Controlled LSP on page 705
•
TCP-MD5 Authentication for PCEP Sessions on page 705
•
Impact of Client-Side PCE Implementation on Network Performance on page 706
Understanding MPLS RSVP-TE
Traffic engineering (TE) deals with performance optimization of operational networks,
mainly mapping traffic flows onto an existing physical topology. Traffic engineering
provides the ability to move traffic flow away from the shortest path selected by the
interior gateway protocol (IGP) and onto a potentially less congested physical path
across a network.
For traffic engineering in large, dense networks, MPLS capabilities can be implemented
because they potentially provide most of the functionality available from an overlay
model, in an integrated manner, and at a lower cost than the currently competing
alternatives. The primary reason for implementing MPLS traffic engineering is to control
paths along which traffic flows through a network. The main advantage of implementing
MPLS traffic engineering is that it provides a combination of the traffic engineering
capabilities of ATM, along with the class-of-service (CoS) differentiation of IP.
In an MPLS network, data plane information is forwarded using label switching. A packet
arriving on a provider edge (PE) router from the customer edge (CE) router has labels
applied to it, and it is then forwarded to the egress PE router. The labels are removed at
the egress router and it is then forwarded out to the appropriate destination as an IP
packet. The label-switching routers (LSRs) in the MPLS domain use label distribution
protocols to communicate the meaning of labels used to forward traffic between and
through the LSRs. RSVP-TE is one such label distribution protocol that enables an LSR
peer to learn about the label mappings of other peers.
When both MPLS and RSVP are enabled on a router, MPLS becomes a client of RSVP.
The primary purpose of the Junos OS RSVP software is to support dynamic signaling
within label-switched paths (LSPs). RSVP reserves resources, such as for IP unicast and
multicast flows, and requests quality-of-service (QoS) parameters for applications. The
protocol is extended in MPLS traffic engineering to enable RSVP to set up LSPs that can
be used for traffic engineering in MPLS networks.
When MPLS and RSVP are combined, labels are associated with RSVP flows. Once an
LSP is established, the traffic through the path is defined by the label applied at the
ingress node of the LSP. The mapping of label to traffic is accomplished using different
criteria. The set of packets that are assigned the same label value by a specific node
belong to the same forwarding equivalence class (FEC), and effectively define the RSVP
flow. When traffic is mapped onto an LSP in this way, the LSP is called an LSP tunnel.
693Copyright © 2017, Juniper Networks, Inc.
Chapter 23: Configuring Path Computation Element Protocol (PCEP)
To Next Page
Loading...
Need help?
General
