3com S7906E 설치 설명서
1-7
z
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.
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.
z
PathTear messages: sent downstream immediately once created to remove the path state and
related reservation state on each node along the path.
related reservation state on each node along the path.
z
ResvTear messages: sent upstream immediately once created to remove the reservation state on
each node along the path.
each node along the path.
z
PathErr messages: sent upstream to report Path message processing errors to senders. They do
not affect the state of the nodes along the path.
not affect the state of the nodes along the path.
z
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.
Resv message processing or reservation error occurs as the result of preemption.
z
ResvConf messages: sent to receivers to confirm Resv messages.
z
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 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.
objects carry not only label bindings but also routing constraints, supporting CR-LSP and FRR.
z
New objects added to the Path message include LABEL_REQUEST, EXPLICIT_ROUTE,
RECORD_ROUTE, and SESSION_ATTRIBUTE.
RECORD_ROUTE, and SESSION_ATTRIBUTE.
z
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.
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
shows how to set up a LSP tunnel with RSVP:
Figure 1-2
Set up an LSP tunnel
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
1) The ingress LSR sends a Path message that carries the label request information, and then
forwards the message along the path calculated by CSPF hop-by-hop towards the egress LSR.
2) After receiving the Path message, the egress generates a Resv message carrying the reservation
information and label and then forwards the message towards the ingress along the reverse
direction of the path along which the Path message travels. The LSRs that the Resv message
traverses along the path reserve resources as required.
direction of the path along which the Path message travels. The LSRs that the Resv message
traverses along the path reserve resources as required.
3) When the ingress LSR receives the Resv message, LSP is established.
As resources are reserved on the LSRs along the path for the LSP established using RSVP-TE,
services transmitted on the LSP are guaranteed.
services transmitted on the LSP are guaranteed.