RSVP

　
　                                                                   RSVP
1> Downstream on Demand (DOD) mode of label
2> The path message from the HE router contains the Label_Request object.
3> The path message
Src address:-System address of the sending router
Dest address:- Destination address of the tail end router.
IP header has Router Alert label set this in turn forces the intermediate routers to process the Path message and take appropriate action.
4>If the path message was defined with strict hops then it is present in the sequential hops section, or else the IGP table is consulted.
5> The hop object in the path message contains the ip address of the egress interface of the router, considering the topology is something like this
R1(10.1.1.1)-------->(10.1.1.2) R2--------->R4------>R6
So Hop object:- 10.1.1.1
This ip address is used by RESV message while creating the LSP.
6> After the path message was sent from R1 to R2 a path state block (PSB) is created PSB is required since R1 needs to know when it receives a RESV message to which LSP session it belongs, PSB and RSB are combined to form a RSVP session. The full path message is stored in the PSB.
7) The session formed after combining PSB and RSB also needs to be refreshed after certain intervals it stores timers to perform those function.
8) When R2 receives the path message it consults the routing table since no explicitly defined hops are present and forwards the path message to the next hop which corresponds to the destination address.
9) R6 responds with a RESV message with a label, from the dynamic range present in the label object field.
10) Resv message uses hop by hop forwarding ie RESV does not consult the Fib, instead it retrieves the address which is already present in the PSB in the HOP object.
11> RESV message source is the egress interface of the router
Dest ip is obtained from the HOP object of the path message hence ip address of the neighbouring router.
Hop object is again the Src ip of the egress interface.
12> Once a RESV message is sent an RSB is created, which contains all the information for the RESV message.
13>Once a router receives the Path message or RESV message it regenerates the message before it is forwarded to its peer.
14> show router rsvp session
Tunnel-ID :- Different LSP have different Tunnel-ID, same for similar LSP although it might have separate Path.
LSP-ID:- This takes into account the path, same LSP can have different path which is displayed here.
LSP name :: Path name
15> When an LSP is brought down then the resources reserved for that LSP on every intermediate routers should be released this is done with the help of Path tear message which travels from HE router to the TE router, and every intermediate hop after it receives the path tear message clears the related state blocks.
16> Similarly RESV tear messages are sent upstream nodes:-
R1(10.1.1.1)-------->(10.1.1.2) R2--------->R4------>R6
Suppose the link between R4 and R6 breaks.
17> The path message is sent downstream, if for any reason the downstream router is not able to send the path message further to downstream it sends a Path Error message to the originator(HE) router, this contains the error code which determines the source of the problem, R1 (HE ) router after receiving the Path Error message sends a Path Tear message downstream.
18> Similarly RESV error messages are sent to downstream to tail end, and then a RESV tear message follows
19> PSB and RSB are refreshed by the Path and RESV messages, the session times out if it is not periodically refreshed.
20> Path tear and RESV tear messages are sent if the path is not refreshed periodically and the session times out.
21> The path and RESV messages are sent by default every 30 seconds.
22> There is also a keep multiplier which determines how many missed messages a router can tolerate before bringing the session down.
23> Reducing the refresh time can help to speed up the convergence, however it may impact the processing performance as each Path/Resv message is processed by the CPU.
Hello protocol is used to speed up convergence without reducing refresh time.
24> Hence to alleviate the problems RSVP also uses the hello protocol, this is derived from the routing protocols ospf/isis.
25> The hello messages is only sent after the session is up with the neighbor and continues to run indefinitely even if the session goes down.
26> By default the Hello messages are sent every 3 seconds, the keep mulltiplier also governs how many hello messages can be missed before it brings the session down.
27> If the hello times out all the RSVP session on that particular interface is cleared.
28> All the sessions are cleared if hellos are not received for 9 seconds this is the default value and can be modified.
29> Hello Timeout= Hello interval x Keep multiplier
3000 ms x 3=9000 ms =9 sec
30> After sending a referesh message the interval to send the next refresh message is set to a random value which extends from 50-150%
Session Timeout >= ( keep multiplier+0.5) * 1.5*Refreshtime=========(3+0.5)*1.5*30
So after each successful path or RESV message the session should timeout after 157.5 seconds ie if it does not receive Path or Resv message till that duration.
Everytime a path message is received the timers are reset.
31> The above Session timeout is followed to avoid the synchronization of all the RSVP sessions at the same time.
32> To display the PSB for a particular router
Tools dump router rsvp psb detail
The PSB state Primary's Connected states that the session is currently connected ie the session is established.
33> Refresh Reduction feature can be enabled in RSVP, this is another way of reducing the messaging overhead of the RSVP protocol, this should be enabled on all the nodes ie all routers should agree to use refresh reduction before this can be implemented.
34> In the case of Refresh reduction the path and resv messages are replaced by Summary Refresh messages which contains a list of Message ID's of the active sessions.
35> Refresh reduction with reliable delivery ensures that the other end has received the message as the sender receives an acknowledgement.
36> When refresh reduction is enabled a Message-ID object is created for each RSVP session.
37> Each message ID object consists of 8 bytes message identifier(4 bytes), RSVP sessions are provided with message identifier values starting from 1. This changes if there is a change in operational or reservational state of a session.
8 bits are allocated to the Flags field if it is set to 0x01 it means an acknowledgement is requested.
Epoch field:- This indicates if the message identifier sequence have been reset this is a rendom value and only changes when the router reboots or the rsvp process changes.
38> Reliable delivery option the sending router waits for an ack message from its peer if it does not receive an ACK it again sends the refresh reduction message this is governed by rapid retransmit interval this can even timeout rapid-retry-limit is reached after which the reliable delivery messages are not sent, however in no way it pulls the session down.
39> Message Pacing is another feature which controls the rate of RSVP messages hitting the router refresh reduction cannot be enabled along with this feature by default 1000 RSVP messages can hit the CPU.
40> config > router > rsvp# interface x
Refresh-reduction
Reliable-delivery
41> config> router > rsvp# rapide-retransmit-time
Config>router>rsvp# rapid-retry-limit <limit>
Show router rsvp neighbor
Flags indicate the refresh reduction feature
LR:- Local flag has set the refresh reduction feature
LD:- Reliable delivery has been set by the local router.
RM:- Remote node supports refresh reduction feature.
RR:- Neighbor sets the refresh reduction capable bit.distribution label is distributed when the HE router requests the label with the help of the path message.