28.06.2014 Views

Discussion

Discussion

Discussion

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

LDP discovers neighbors by sending Hello messages, multicasting them to 224.0.0.2<br />

on UDP port 646. After discovering a neighbor, LDP establishes a TCP connection to<br />

the neighbor and exchanges information regarding labels and routes (called forwarding<br />

equivalence classes [FRCs]) associated with the labels. All packets associated with<br />

the same FEC are treated in the same way by the router. In general, this means that<br />

the packets are sent to the same next hop. The use of TCP ensures reliable delivery of<br />

label information. LDP sends periodic keepalive messages to maintain the TCP connection.<br />

Each LDP router updates its forwarding-path information independently as<br />

it tracks the state of the IGP.<br />

RSVP was developed before MPLS and was designed to create bandwidth reservations<br />

for individual traffic flows. RFC 3209 extends RSVP to allow it to create and<br />

maintain MPLS LSPs and to reserve the bandwidth needed for LSPs. The extensions<br />

are called RSVP-TE. In the rest of this chapter, when we say RSVP, we mean RSVP<br />

with TE extensions. Unlike LDP, which uses the IGP’s shortest path as the transit<br />

path for the LSP, RSVP works with the Constrained Shortest Path First (CSPF) algorithm<br />

to determine the LSP’s path. On the ingress router, CSPF computes the path of<br />

the LSP (the Explicit Route Object [ERO]) and passes the path to RSVP. RSVP then<br />

signals to set up the path. This path-determination mechanism allows RSVP-signaled<br />

LSPs to be used in MPLS-based traffic engineering to explicitly control the path taken<br />

by traffic between specific points in the network. Unlike LDP, which is limited to a<br />

single IGP domain, RSVP-signaled LSPs can cross AS boundaries.<br />

When the ingress router initiates an RSVP-signaled LSP, it sends an RSVP Path message<br />

with the destination address of the egress router. This message also contains<br />

several objects, including the:<br />

Label Request Object (LRO)<br />

Requests an MPLS label for the path<br />

ERO<br />

Contains the addresses of the routers along the LSP<br />

Record Route Object (RRO)<br />

Records the path of the LSP<br />

Sender TSpec<br />

Requests a bandwidth reservation for the LSP<br />

The egress router responds to a Path message by sending a Resv message that contains<br />

the label to be used for the LSP (in the label object) and a record of the path<br />

taken by the Resv message. In turn, the penultimate router sends a Resv message to<br />

its upstream router containing the label value of its choice inside the label object,<br />

because each hop to the downstream router chooses the label value to be used by the<br />

upstream router to forward packets on that hop. This message-exchange scheme<br />

means that an RSVP-signaled LSP requires configuration only on the ingress router.<br />

RSVP periodically sends Path and Resv messages along the LSP to maintain its state.<br />

484 | Chapter 14: MPLS<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!