Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1999-07-01
2003-12-09
Alam, Hosain T. (Department: 2155)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S224000, C709S238000
Reexamination Certificate
active
06662223
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed to measuring response time between end points in a computer network.
FIG. 1
is a schematic block diagram of a conventional computer network that includes a local enterprise network coupled to a remote enterprise network via an Internet Service Provider (ISP) domain. The local and remote enterprise networks may comprise autonomous systems such as corporate intranets, where in the local enterprise network includes a source end station ESA and the remote enterprise network includes a destination end station ESB. The ISP domain includes a plurality of routers coupled together by a transmission control protocol/Internet protocol (TCP/IP) network cloud. As shown in
FIG. 1
, the ISP domain includes a source router
100
(SRC) and a destination router
102
(DSTN) bordering an IP network cloud
104
and interconnected thereto by associated edge routers
103
and
105
.
During operation, a user of source end station A (ESA)
106
may realize delays when communicating with destination end station B (ESB)
108
over the ISP domain. The delays may occur in the local enterprise network, the remote enterprise network or at the intermediate ISP domain. Typically, the user will levy a complaint to the Internet service provider and it would desirable for the Internet service provider to diagnose its domain and unequivocally determine whether it is the source of the delays.
Typically, an Internet Control Message Protocol (ICMP) is used to measure response time between end points, such as the source router and destination router, in the ISP domain. The ICMP is described generally on pages 185-189 of the textbook
Interconnections
by Radia Perlman, Addison Wesley Longman, Inc., 1992. In addition, the industry standards hand out entitled “standard RFC 792” describes the Internet Control Message Protocol in detail. The basic format of an ICMP message consists of one byte of message type, one byte of code, two checksum bytes, two bytes of type-specific data, followed by the variable Internet header itself and 64 bits of the problem packet. ICMP message types include: 0=echo reply; 3=destination unreachable; 4=source quench; 5=redirect; 8=echo request; 11=time exceeded; 12=parameter problem; 13=timestamp request; 14=timestamp reply; 15=information request; 16=information reply; 17=address mask request; and 18=address mask reply. The ICMP code message includes: (where type is time exceeded) 0=died in transit and 1=died while being reassembled at the destination; or (where type is destination unreachable) 0=network unreachable; 1=host unreachable; 2=protocol unreachable; 3=port unreachable; 4=fragmentation required but not allowed; and 5=source failed; or (where type is parameter problem) code unused.
The timestamp process entails the request and transmission of time data associated with message receipt. For example, an originate timestamp message is put in by the requester to indicate the most recent known time before transmission of the timestamp request. A receive timestamp message is put in by the replier to indicate the time that the request was received. A transmit timestamp message is put in by the replier to indicate the time at which the reply was transmitted.
The particular type of ICMP message used to measure response time is the echo request (message type=8), which can be used to decide whether some destination is reachable. The destination receiving an echo request is supposed to respond with an echo reply (message type=0). The echo request is also known as a “Ping.” To ping a network node means to send an echo request thereto. Ping message exchanges, and the ICMP protocol, are typically used to measure response time because that protocol and those messages are services readily available to all devices in a TCP/IP network. That is, ICMP is an integral part of the Internet Protocol (IP) and implemented by every IP module in any IP device. Ping is an operation based on ICMP, and thus, is available on all machines. Therefore, Ping messages are typically used to measure response time in an ISP domain in response to customer complaints with respect to service.
A disadvantage associated with the use of Ping messages as a means for measuring network response time in the ISP domain is that the ICMP is not representative of the client's application protocol that manifests the latencies/delays. For example, the customer may be running a Domain Name Service (DNS) or a Simple Network Management Protocol (SNMP) application when they latencies manifest. These application protocols typically run over a transport such as the User Datagram Protocol (UDP). Another application may be the Hypertext Transfer Protocol (HTTP) that generally runs over the Transmission Control Protocol (TCP) transport of the Internet Protocol (IP) stack. In general, there are more latencies associated with the UDP and TCP protocol communications because of the processing required in the end points when implementing such features as quality of service (QOS). Therefore, it is desirable to measure the response time between router end points in the ISP domain using a protocol that is similar to the protocol used by a customer, such as UDP or TCP.
When using these transport protocols to communicate with a destination, the source end station generally specifies a particular port in the destination for receiving and responding to a request from the source. In order to effect such transport protocol communication, certain software processes must be running on the destination end station. Typically, the destination end station is a server located in the remote enterprise network and the source end station is a client located in the local enterprise network. The software running on the server that is required to effect transport communication is typically a server process (otherwise known as a responder) that is configured to “listen” on a particular port in order to receive requests from the client. For example, in the case of a DNS application running over EDP, the DNS server process running on a destination end station listens on standard router Port
53
in order to service any DNS requests.
The responder server processes are generally not running on the destination in source routers in the ISP domain. Yet in order for the Internet Service Provider to accurately diagnosis the response time in its domain, it is desired for the ISP to emulate the UDP transaction between the source and destination routers in the ISP domain. That way, the ISP can determine whether there is any latencies between the source and destination router end points that are configured to utilize the same protocol, quality of service and ports as the client and server end stations on the local and remote enterprise networks. Accordingly, the server process software must be installed on the destination router so that the destination router can respond to the service request using the UDP transport protocol. More specifically, if the client is having a problem on, for example, Port
53
, it is desirable to emulate Port
53
on the destination of the ISP domain. The server process (responder software) must be running and listening on Port
53
in the destination router in order to respond to the UDP request from the source router in the ISP domain.
A problem with manually configuring the routers with the appropriate software is that these processes would be constantly running in the routers for an extended period of time; this could lead to disruption of service (denial of service attacks) on the routers by unauthorized interlopers, e.g. “hackers.” The present invention is directed to solving this problem and, in particular, to a technique for dynamically invoking a responder process on a destination router of the ISP domain.
SUMMARY OF THE INVENTION
The present invention is directed to a control mechanism that enables a destination router to
Lautmann John
Raparla Satyanarayana R.
Zhang Kui
Alam Hosain T.
Cesari and McKenna LLP
Cisco Technology Inc.
Tran Philip B.
LandOfFree
Protocol to coordinate network end points to measure network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Protocol to coordinate network end points to measure network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Protocol to coordinate network end points to measure network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3170898