Download Document

Background:
Today RSVP protocol is used extensively for different applications like RSVP-TE, RSVP-CAC,
RSVP-Transport etc. . For RSVP session to be setup, RSVP PATH messages are sent across the
network through various nodes along the path. For these RSVP PATH messages to get
processed, the incoming interface should be RSVP enabled on the nodes. These PATH messages
then get forwarded out of the node through an outgoing interface which is again should be RSVP
enabled towards the destination after processing the message. RSVP messages are forwarded
transparently if the node is not RSVP aware. In an RSVP enabled node, the RSVP PATH
messages get dropped if message is received over RSVP enabled interface and there is no RSVP
enabled outgoing interface on the node for the corresponding destination.
With respect to the service provider domain TE (traffic engineering) is widely used which use
RSVP protocol for bandwidth reservation along the network path. And to set up traffic
engineering tunnel along the network path all the nodes along the path needs to be RSVP enabled
(both ingress & egress interfaces) with sufficient RSVP bandwidth configured on the interfaces.
Adding to this, in case of RSVP-TE case RSVP get enabled while enabling mpls-trafficengineering on the corresponding interface.So to set up TE tunnel across networks Administrator
has to make sure that all the nodes along the path of this tunnel should be RSVP enabled with
sufficient RSVP bandwidth configured on those. While configuring this if administrator miss to
enable RSVP on any of the interface with sufficient RSVP bandwidth then TE tunnel fails to set
up. Debugging such scenarios in a complex network is really tough for the administrator.
Currently to debug such scenario, administrator has to login to each node along the path and find
out where exactly RSVP configuration is missing along the path which leads to TE tunnel set up
failure. Currently there is no way for the administrator to trace the RSVP status on each node
along the path to the corresponding destination from the source. Moreover that in a single node
itself there can be more numbers of interfaces and finding out the corresponding ingress/egress
interfaces for the source-destination pair also tedious job.
Detailed Description:
In RSVP enabled network following can be the various RSVP status on different nodes along the
path,
1. RSVP is not enabled on the node at all (non RSVP hop)
2. RSVP enabled on the required incoming and outgoing interface on the node with
sufficient RSVP bandwidth on the interface
3. RSVP enabled on the required incoming and outgoing interface on the node with
insufficient RSVP bandwidth on the interface
4. RSVP enabled on the incoming interfaces only
5. RSVP enabled on the outgoing interfaces only
In the above 1 and 5 case, the node act as non-RSVP hop and RSVP messages is transparently
forwarded by the nodes. In case 2 the node would accept , process and forward RSVP messages
to the next-hop and RSVP session sets up as expected with requested bandwidth reserved on the
interface.
But for case 4 RSVP session fails to establish since the node is unable to find an RSVP enabled
outgoing interface towards the destination. Currently there is no error handling mechanism for
this kind of failure in RSVP and there wont be any error message returned to the source. Due to
this failure, RSVP reservation is not setup which leads to TE tunnel set up failure.
And in case 3 RSVP message get accepted, processed and forwarded to the next hop but TE
tunnel set up fails because of the insufficient RSVP bandwidth on the interface.
This idea helps to solve all above problems by tracing the RSVP information as following,
 Find out non RSVP hops along the data path in a network
 Find out the nodes which are dropping RSVP messages because of missing RSVP on the
egress interface
 Find out the RSVP bandwidth on each node along the path
With above capability information Administrator can understand the RSVP status on the nodes
along which the TE tunnel has to be set up.
Following is the method to achieve above,
RSVP path trace:
In this administrator can initiate a RSVP path trace message which will be a 2 tuple request
message which contains source (Head) and destination IP (Tail) in case of dynamic path trace
AND there will be list of node addresses along with source and destination addresses in case of
explicit path trace . And this message works as following,
 Administrator initiate the path trace message from the RSVP sender box with all required
tuple information where source and destination IP are must parameters
 This path trace function in an iterative fashion where it starts with RSVP-TTL=1 and IPTTL=1
 Upon receiving this packet in next hop, it decrements the TTL value and pass to the
RSVP process if its incoming interface is RSVP enabled. RSVP process will find out the
corresponding outgoing interface for the destination and checks whether it is RSVP
enabled or not. Decrementing TTL value will make TTL value to zero and node will send
back the path error message back to the initiator where path error message contains
ingress interface and egress interface with RSVP status and bandwidth on those interfaces
 If the node is non RSVP capable then it sends back ICMP error message back with which
non RSVP hop can be recognized along the path from the message received on the
initiator
 Upon receiving the error message on initiator it display the information contained in the
error messages and sends the path trace with TTL=2 in the second iteration
 Same way on the second hop TTL becomes zero and corresponding error message will be
send back to the initiator
 Iteration continues till the destination node sends error messages
With this idea it become very easy to trace the RSVP capabilities on the nodes for a given
source-destination pair information. Same method can be used for both dynamic & explicit-path
cases. Where in case of explicit-path case, along with source and destination information we
need to input the next-hop addresses along the path to the destination.
Advantages:
This idea solves certain network administrative problems involved with RSVP in networks
where RSVP is used. Today due to RSVP not being enabled on an egress interface at certain
nodes or insufficient RSVP bandwidth on the interfaces, the administrators have no way in
identifying the point of failure unless they login and check at each and every node along the path.
* Makes debugging easier in RSVP enabled networks.
* In rapidly growing media networks this will add to RSVP debug ability and effective
turnaround to solve call connection failures.
* This will enrich the OAM capabilities in MPLS-TE
This idea solves certain administrative problems related to RSVP in networks when RSVP is
used for call admission control. Today due to RSVP not being enabled on an egress interface at
certain nodes, the administrators have no way to identify the point of failure unless they login
and check at each and every node along the path.
Existing RSVP capability on IOS or IOs-XR can be enhanced with this idea.This idea can make
the RSVP-TE feature easier to deploy in customer deployments by enhanced debug ability.
Industry Use:
Description of possible uses of the technology by others in the industry:
Increased usage of network resources (like bandwidth) in media networks and service provider
networks makes RSVP a mandatory feature for high performance and traffic engineering. So if
this particular feature is available on RSVP, then it can be made use by the customers who
deploy RSVP in their networks.
As mentioned in summary details, method one can be detected if RSVP debugs are enabled on
the sender node. Where we can see the path error message with the RSVP status on the egress
and ingress interface details.
Second method can be detected by initiating a path trace packet from the sender. And sender
display corresponding error messages received from each node along the path.
The same can also be detected by sniffer captures at the upstream interface of the Initiator' in
both cases.