H3C Technologies H3C SR8800 - Manual (Page 57)

46
Figure 15 presents a scenario where a path Router A → Router B → Router C → Router D is established
with 30 Mbps reserved bandwidth between Router A and Router D. The remaining bandwidth is then 30
Mbps.
If 40 Mbps path bandwidth is requested, the remaining bandwidth of the Router A → Router B → Router
C → Router D path will be inadequate. The problem cannot be addressed by selecting another path,
Router A → Router E → Router C → Router D, because the bandwidth of the Router C → Router D link is
inadequate.
To address the problem, you may use the make-before-break mechanism. It allows the new path to share
the bandwidth of the original path at the Router C → Router D link. Upon creation of the new path, traffic
is switched to the new path and the previous path is torn down. This helps avoid traffic interruption
effectively.
RSVP-TE messages
RSVP-TE uses RSVP messages with extensions. The following are RSVP messages:
• Path messages—Transmitted along the path of data transmission downstream by each RSVP sender
to save path state information on each node along the path.
Resv messages—Sent by each receiver upstream towards senders to request resource reservation
and to create and maintain reservation state on each node along the reverse of data transmission
path.
• PathTear messages—Sent downstream immediately once created to remove the path state and
related reservation state on each node along the path.
• ResvTear messages—Sent upstream immediately once created to remove the reservation state on
each node along the path.
• PathErr messages—Sent upstream to report Path message processing errors to senders. They do not
affect the state of the nodes along the path.
• ResvErr messages—Sent downstream to notify the downstream nodes that error occurs during Resv
message processing or reservation error occurs as the result of preemption.
• ResvConf messages—Sent to receivers to confirm Resv messages.
• Hello messages—Sent between any two directly connected RSVP neighbors to set up and maintain
the neighbor relationship that has local significance on the link.
The TE extension to RSVP adds new objects to the Path message and the Resv message. These objects
carry not only label bindings but also routing constraints, supporting CR-LSP and FRR.
• New objects added to the Path message include LABEL_REQUEST, EXPLICIT_ROUTE,
RECORD_ROUTE, and SESSION_ATTRIBUTE.
• New objects added to the Resv message include LABEL and RECORD_ROUTE
The LABEL_REQUEST object in the Path message requests the label bindings for an LSP. It is also saved
in the path state block. The node receiving LABEL_REQUEST advertises the label binding using the LABEL
object in the Resv message to the upstream node, thus accomplishing label advertisement and
transmission.
Setting up an LSP tunnel
Figure 16 shows how to set up a LSP tunnel with RSVP: