* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Document
Survey
Document related concepts
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Distributed operating system wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Serial digital interface wikipedia , lookup
Dijkstra's algorithm wikipedia , lookup
Transcript
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.