H3C Technologies H3C S6800 Series Switches - Manual (Page 153)

140
New objects added to the Resv message include:
• LABEL—Advertises the label allocated by the downstream node to the upstream node.
• RECORD_ROUTE—Records the path that the CRLSP actually traverses and the label allocated by
each node on the path.
CRLSP setup procedure
Figure 36 Setting up a CRLSP
As shown in Figure 36 , a CRLSP is set up using the following steps:
1. The ingress LSR generates a Path message that carries LABEL_REQUEST, 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 LSR generates a Resv message carrying the
reservation information and the LABEL object. It forwards the Resv message to the ingress LSR
along the reverse direction of the path that the Path message traveled.
The Resv message advertises labels, reserves resources, and creates a reserve state on each LSR it
passes, so QoS can be guaranteed for services transmitted on the CRLSP.
3. When the ingress LSR receives the Resv message, the CRLSP is established.
RSVP refresh mechanism
Refresh messages
RSVP maintains resource reservation states on a node by periodically sending messages.
The resource reservation states include path states and reservation states. A path state is saved in a path
state block (PSB), and a reservation state is saved in a reservation state block (RSB). A PSB is created by
a Path message and saves the LABEL_REQUEST object. A RSB is created by a Resv message and saves
the LABEL object.
The path states and reservation states are refreshed periodically by Path and Resv messages. A state is
removed if no refresh messages for the state are received in a certain interval, and the CRLSP established
based on this state is also removed.
The Path and Resv messages for refreshing the resource reservation states are collectively referred to as
refresh messages. Refresh messages can also be used to recover from lost RSVP messages.
When multiple RSVP sessions exist on a network, a short refresh interval can cause network degradation,
but a long refresh interval cannot meet the requirements of delay sensitive applications. To find an
appropriate balance, you can use the summary refresh (Srefresh) and the reliable RSVP message delivery
functions.
Srefresh
Srefresh is implemented by adding a Message_ID object to a Path or Resv message to uniquely identify
the message. To refresh Path and Resv states, RSVP does not need to send standard Path and Resv
messages. Instead, it sends an Srefresh message carrying a set of Message_ID objects that identify the
Ingress Egress
Sender Receiver
Path Path
Resv Resv