US 20050078692 A1
A method and system for analyzing a public switched communications network from a remote place via the public Internet. The system comprises an access device which collects data from one or more links in a public switched communications network. The system further includes a server computer which receives the collected data from the access device via a dedicated network or the Internet. The server computer executes one or more applications to perform protocol analysis based on the received data. A client computer executing a Web browser may be used to communicate with the server computer via the Internet and access the outcome of the protocol analysis.
1. A system for restricting access of an operator to a communications network, the system comprising:
a device configured to allow access to at least one link in the communications network;
a computer configured to communicate with the device, the computer having at least one test application; and
a selector configured to identify the at least one test application and at least one link allowed for access by the operator.
2. The system as defined in
3. The system as defined in
4. The system as defined in
5. The system as defined in
6. The system as defined in
7. The system as defined in
8. The system as defined in
9. The system as defined in
10. The system as defined in
11. The system as defined in
12. The system as defined in
13. The system as defined in
14. The system as defined in
15. The system as defined in
16. The system as defined in
17. A method of restricting access of an operator to a communications network, the method comprising:
sending identification information of the operator to a computer to execute at least one test application;
verifying the identification information of the operator; and
determining at least one link and at least one test application allowed for access by the operator in response to the identification information.
18. The method as defined in
19. The method as defined in
20. The method as defined in
21. The method as defined in
22. The method as defined in
23. The method as defined in
24. The method as defined in
25. The method as defined in
26. The method as defined in
27. The method as defined in
28. A method of restricting access of an operator to a communications link, the method comprising:
receiving via a first communications network information about the identity of the operator;
verifying the information about the identity of the operator; and
determining at least one link in a second communications network and at least one test application allowed for access by the operator in response to verifying the information.
29. The method as defined in
30. The method as defined in
31. The method as defined in
32. The method as defined in
33. The method as defined in
34. A system for restricting access of an operator to a communications network, the system comprising:
means for receiving information about the identity of the operator;
means for verifying the information about the operator; and
means for determining at least one link in the communications network and at least one test application allowed for access by the operator.
35. The system of
36. The system of
This application is a continuation, and hereby incorporates by reference the entire disclosure, of U.S. application Ser. No. 09/188,923, entitled “SYSTEM AND METHOD OF ANALYZING NETWORK PROTOCOLS”, filed Nov. 9, 1998.
1. Field of the Invention
The invention relates generally to accessing and testing communication networks. More particularly, this invention relates to remotely accessing, monitoring, and analyzing network protocols, such as used in public switched networks.
2. Description of the Related Technology
Current communication technology accommodates the transmission of voice, data, and video over multiple communication networks. The transmission standard employed by one communication network is often different than the standard employed by another. These standards include frame relay, asynchronous transfer mode (ATM), integrated services digital network (ISDN), fiber distributed data interface (FDDI), and Internet, for example. These transmission standards specify a variety of signal protocols, thereby requiring conversion of signals from one protocol to another, and vice versa.
Generally, a protocol refers to an agreed-upon format for transmitting data between two devices. The protocol determines, among other things, the type of error checking to be used, method of data compression, if any, and how a device indicates that it has finished sending or receiving a message. Several of the most significant protocols in use today are frame relay, ATM, ISDN, FDDI, and TCP/IP.
Frame relay is a packet-switching protocol for connecting devices on a wide area network (WAN). Frame relay networks support data transfer rates at 1.544 Megabits per second (Mbps) (also known as DS1 or T1 rate) and 44.736 Mbps (also known as DS3 or T3 rate). ATM is a packet-based network supporting data transfers between 25 and 622 Mbps. ATM offers a fixed point-to-point connection known as a “virtual circuit” (VC) between a source and destination. ATM is often transmitted over a physical medium known as a synchronous optical network (SONET) which employs fiber optic links. SONET defines a fiber optic transmission system offering optical channels from OC-1 at 51 Mbps to OC-96 at 4.8 Gigabits per second (Gbps).
ISDN is an international communications standard for sending voice, data, and video over digital telephone lines. ISDN requires special metal wires and supports data transfer rates of 64 kilobits per second (kbps). FDDI is a set of American National Standards Institute (ANSI) protocols for sending digital data over fiber optic cable. FDDI networks support data rates up to 100 Mbps. FDDI networks are typically used as backbones for WANs. Finally, data traffic on the largest public network in the world, the Internet, conforms to Transmission Control Protocol/Internet Protocol (TCP/IP) standard which is a suite of communication protocols for connecting host computers on the Internet.
An open systems interconnection (OSI) model is often implemented to facilitate the interoperability of systems conforming to different standards. The OSI model provides a widely accepted structuring technique called “layering” whereby the communications functions are partitioned into a hierarchical set of layers. Each layer performs a related subset of the functions required to communicate with another system. Ideally, the layers are defined so that changes in one layer do not require changes in other layers. The OSI model defines the following: physical, data link, network, transport, session, presentation, and application layers. The following is a brief description of the function and purpose of each layer.
The physical layer defines the transmission of unstructured bit streams over physical links, involving parameters such as voltage swings and bit durations. The data link provides reliability to the bit stream by defining error detection and control bits. The network layer is responsible for establishing, maintaining, and terminating connections across one or more networks between two communicating systems. The transport layer is responsible for maintaining proper sequence and error-free delivery of data between two communicating systems. The session layer controls the dialogue between two communicating systems by specifying discipline (e.g., half- or full-duplex), grouping of data, and checkpoint mechanism for recovering lost data. The presentation layer defines data formats exchanged between applications by offering a set of transformation services, such as compression or encryption. Finally, the application layer defines the mechanism of accessing the OSI environment to support the exchange of information between two or more applications, such as file transfer and electronic mail.
As the number of communication networks increases, so does the complexity of managing, maintaining, and troubleshooting a malfunction in these networks.
At block 130, if the technician detects a problem in the physical layer, the physical component is repaired. However, if the technician does not detect a problem in the physical layer, specialized technicians with protocol analyzers are dispatched to determine if a defect exists in the logical layer of transmission (block 140). Generally, the logical transmission layer refers to the OSI data link, network, transport, session, presentation, and/or application layers. More particularly, the logical transmission layer refers to the OSI data link, network, and/or transport layers. At times, the specialized technicians may have to communicate several times, back and forth, with the technicians at the physical layer before they can determine and isolate the problem. Possibly many hours later, the network operations center notifies the network user of the nature of the problem and time needed to restore normal network operation (block 150). Once the problem is determined, an appropriate fix to hardware or software is made to correct the problem which caused the failure in transmission.
As shown in the above exemplary scenario, isolating and correcting a malfunction in a multiprotocol network may be a very time consuming process involving multiple levels of expertise. During this process, actual examination of a link at multiple locations may be necessary to isolate the source of the malfunction in the network. Moreover, the network user's operation is shut down or, in some cases, transferred to more costly back-up solutions. In troubleshooting a network, the network provider is often compelled to dispatch technicians with expensive, bulky testing units to determine where a problem may exist in the network, thereby making network maintenance costly and inefficient.
Therefore, there is a need in communications network technology to provide network providers with the ability to maintain and troubleshoot their network in an efficient and cost-effective manner.
In one embodiment, the invention provides a system for restricting access of an operator to a communications network. The system comprises a device configured to allow access to at least one link in the communications network. The system further comprises a computer configured to communicate with the device, the computer having at least one test application. The system further comprises a selector configured to identify the at least one test application and at least one link allowed for access by the operator.
In another embodiment, the invention provides a method of restricting access of an operator to a communications network. The method comprises sending identification information of the operator to a computer to execute at least one test application. The method further comprises verifying the identification information of the operator. The method further comprises determining at least one link and at least one test application allowed for access by the operator in response to the identification information. In another embodiment, the method comprises receiving via a first communications network information about the identity of the operator. The method further comprises verifying the information about the identity of the operator. The method further comprises determining at least one link in a second communications network and at least one test application allowed for access by the operator in response to verifying the information.
In yet another embodiment, the invention provides a system for restricting access of an operator to a communications network. The system comprises means for receiving information about the identity of the operator. The system further comprises means for verifying the information about the operator. The system further comprises means for determining at least one link in the communications network and at least one test application allowed for access by the operator.
Certain aspects, features and advantages of certain embodiments of the invention will be better understood by referring to the following detailed description, which should be read in conjunction with the accompanying drawings, in which:
The following description is not to be taken in a limiting sense, but is made merely for the purpose of describing the general principles of the invention. The scope of the invention should be determined with reference to the claims.
As noted above, the invention includes a system and method for analyzing operation and performance of a communication network.
The access devices may be distributed at one or more sites at critical boundaries of the NUE 290. As noted above, the NUE 290 may be a frame relay, ATM, TCP/IP, or other similar communication networks. An access device provides the NEPA server 210 with access to, selection of circuits, and collection of data from the NUE 290. The access device provides a physical interface to the various North American standard telephone signals supported by the NEPA system 200, such as DS1, DS3, and SONET. However, other standards such as the European E1 and E3 signals are encompassed by the invention. The access device may connect to the NUE 290 either in-line or via a test access point such as a digital cross connect (DCS) 244. The access device may be any commercially available unit which is interoperable with the NEPA server 210. For example, the access device may be a frame sentry module 250 which may be installed in an integrated test access unit (ITAU) such as a T3AS 218 or a centralized test system (CTS) 224, manufactured by Applied Digital Access (ADA). The frame sentry 250 performs intrusive access of one or more network links. Additionally, the access device may be a frame probe 228 which is also manufactured by ADA. The frame probe 228 is a stand-alone unit which performs intrusive and non-intrusive access to one or more network links. The access device may also include any original equipment manufacture (OEM) device, such as a frame relay switch 234, router 238, a frame relay assembler/disassembler (FRAD) 248, which includes a NEPA access device, such as the frame sentry module 250. These OEM devices break a data stream into frames for transmission over a frame relay network, and recreate a data stream from incoming frames from the frame relay network.
The user 302 may also use a network interface software 314 such as a Web browser (e.g., Microsoft Internet Explorer, or Netscape Navigator/Communicator), to communicate over the network 220. Alternatively, the user 302 may use a portable personal computer (PC) 316 or a telephonic device 318 equipped with proper network interface software to interface to the network 220. The user 302 may also use a monitor 321 connected to a cable box 322 equipped with proper network interface software to interface with the network 220. Furthermore, using a satellite (not shown), the user may employ a standard television set 324 connected to a satellite box 326 to communicate with the network medium through a satellite antenna 328. Finally, the user 302 may employ a network interface software 331 in a dedicated server 332 to communicate over the network 220. Accordingly, numerous variations in the type of interface equipment may be accommodated in applying this invention.
Using any of the above interface equipment, the user 302 may communicate with one or more NEPA servers 210. The NEPA servers comprise computing devices having large persistent memories such as multi-Gigabyte hard disk drives. The drives contain file resources which are accessible to the NMC 230 (
As shown in
The PAE 320 filters and collects desired protocol information from one or more circuits in the NUE 290 simultaneously. The PAE 320 may conduct protocol analysis on the collected data in in-line configurations. The PAE 320 stores the collected data into the MIB 340 or a dedicated RAM file for further processing. One PAE 320 may further support a variety of signal protocols including TCP/IP, Ethernet (e.g., IEEE 802.3), systems network architecture (SNA), frame relay, and ATM. The PAE 320 may further support a multiprotocol interconnect over frame relay and bridging protocols, as specified in the request for comments (RFC) 1490,published July 1993, which is incorporated by reference. The bridging protocols include 802.4 frame, FDDI frame, 802.6 frame, and protocol data unit (PDU) frame. Of course, other protocols may be analyzed by the access device 250. The type of protocol information to be decoded depends on the signal protocol of the NUE 290. For example, the PAE 320 may consider the IP address, DLCI number, virtual channel identifier (VCI), virtual path identifier (VPI), or other protocol-specific information.
The PTI 330 performs monitor, traffic emulation, and traffic injection functions for selected links of NUE 290. The PTI 330 injects traffic having a data link connection identifier (DLCI) form into the protocol stream of the link of NUE 290. For instance, the PTI 330 may inject a limited set of errors such as frame check sequence (FCS) or “0” bit stuffing errors. The PTI 330 specifies the start time, frequency and duration of a test pattern injection. Two basic methods are provided for specifying test frames for injection into frame relay. The first method requires the PTI 330 to specify a frame prototype and its accompanying data using TR_PROTO frame specification. As known in the protocol analysis technology, a frame relay frame includes an address field and an information field. The PTI 330 may inject traffic in the address field and information field. This frame specification format is useful if the PTI 330 is attempting to construct a frame test sequence from scratch, i.e., without any prior frame capture reference.
The second method requires the PTI 330 to specify only the raw data to be injected into the frame relay link using a TR_DATA frame specification. This form of test data specification is useful if the PTI 330 has collected a frame capture for use as a direct reference to injecting traffic. Multiple concurrent test data specifications having different start time, duration and frequency may be performed. Finally, it is desirable to have the NEPA server 210 perform these functions and, consequently, accordingly instruct the PTI 330 via the NEPA agent 360.
Although it is shown as a separate functional block, the MID 340 is often integrated with the NEPA agent 360. In practice, the NEPA agent 360 comprises the MIB 340 and a WindNet simple network management protocol (SNMP) agent to communicate with the NEPA server 210 using SNMP via the communications network 220. The MIB 340 employs MIB rules defined by RFC 1155 titled “Structure and Identification of Management Information for TCP/IP-based Internets,” published in May 1990, RFC 1212 titled “Concise MIB Definitions,” published in March 1991, and RFC 1315 titled “Management Information Base for Frame Relay DTEs,” published in April 1992, which are incorporated by reference. The MIB 340 typically stores the protocol information collected by the PAE 320. The MIB 340 makes such information available for transfer to the NEPA server 210 for analysis. Additionally, a RAM file may be used to store formatted protocol information. The NEPA server 210 retrieves formatted protocol information using file transfer protocol (FTP) for real-time display, storage in the NEPA server 210, or use by a particular NEPA application.
The NEPA agent 360 may communicate control commands with the NEPA server 210 using a control link, such as Ethernet, Telnet, or X.25, over a TCP/IP network such as the Internet. The NEPA agent 360 may configure the frame sentry 250 (e.g., assigns an IP address to allow operation over the TCP/IP network), communicates alarm and status information, and communicates frame relay protocol data unit (PDU) statistical information. The NEPA agent 360 may employ a common object request broker architecture (CORBA) link to communicate data with the NEPA server 210. CORBA is an architecture which allows pieces of programs or objects to communicate regardless of the programming language or operating system used by these programs.
The foregoing functional blocks of the NEPA access device represent merely one possible approach for designing the NEPA access device. After reviewing this disclosure, it will be apparent to those skilled in the protocol analysis technology that other design partitions may lead to other implementations of a NEPA access device. For example, two or more functional blocks (e.g., MIB 340 and NEPA Agent 360) may be combined into a single functional unit. All these possible variations fall within the scope of the invention.
The HSIS 400 supports interface to one or more signal lines, e.g., DS1 and DS3. Additionally, with the frame sentry 250, the high-speed interface shelf 400 supports interface to SONET signals, and other similar signals. For more information about the ITAU, reference is made to U.S. Pat. No. 5,691,976 issued to Engdahl et al., which is incorporated by reference.
Once the NEPA server 210 verifies the user profile information, the NEPA server 210 prepares the application tools to be displayed to the operator (block 520). In preparing the application tools, the NEPA server 210 determines, based on the user profile information, which tool and options the operator is authorized to access. The NEPA server 210 displays the accessible tools to the operator at the client computer at NMC 230. At block 530, the operator may command the NEPA server 210 to conduct one or more network analysis tasks. The operator may select an object type, a node location (i.e., TAP), and one or more circuits or links to be monitored, tested, or analyzed. Additionally, the operator may select the application or tool to run, duration of the test, protocol type, and frame filter to be used. Based on these selections, at block 540, the NEPA server 210 commands one or more NEPA access devices, such as the frame probe 228 or frame sentry 250, to access and collect data from the NUE 290. At block -550, the one or more NEPA access devices collect the desired data from the NUE 290, and forward the collected data to the NEPA server 210 for analysis.
As noted above, the communication link between the NEPA server 210 and NEPA access devices may be established using a dedicated link or the communications network 220, i.e., the Internet. At block 560, the NEPA server 210 analyzes the collected data, and forwards the data in analyzed form to the operator at the NMC 230 for display in accordance with the selected application. Once the operator receives the analyzed data, the operator may view the analysis on a visual display or print out a hard copy for monitoring or troubleshooting a malfunction in NUE 290. At block 570, the operator decides whether to conduct more tests on the NUE 290. If the operator desires to conduct more tests on the NUE 290, the process returns to block 530. If the operator desires to terminate the session with the NEPA server 210, the operator may terminate the session by logging off at block 580.
Java is a high-level programming language which may be executed or interpreted on most computers, because it is compatible with most operating systems, including,UNIX, Macintosh OS, and MS Windows. Java application programs may be downloaded from a Web server (e.g., NEPA server 210) to run on a computer (e.g., NMC 230) having a Java-compatible browser, such as Netscape Navigator or Internet Explorer.
On the other hand, CGI is a specification for transferring information between a Web server and a CGI program. A CGI program is a program written in any programming language, such as C, Perl, Visual Basic, or Java, so long as the program accepts and returns data which conforms to the CGI specification. CGI programs are commonly used in Web client computers to allow Web servers to interact dynamically with Web users.
Beginning with block 600, the NEPA server 210 begins operation upon power-up or after a reset. As noted above, the NEPA server 210 may be located at any desired physical location selected by the maintenance operators. For example, if desired, the NEPA server 210 may be co-located with the NMC 230. At decision block 610, the NEPA server 210 determines if a test session requested command is received from a NMC 230. If no test session is requested, the NEPA server 210 continues to wait for a request for a test session. If a request for a test session is received, at block 620, the NEPA server 210 requests and verifies access profile information, such as a username and password.
The NEPA server 210 compares the profile information with a file or database containing pre-registered profile information. More particularly, the authorized usernames and passwords may be stored in a key-value ASCII file that is readable by a UserProfile module. In one embodiment, the file format is defined by a “users.profile” file located in the NEPA Toolkit source tree. Each user has an associated profile that defines the tools, tests, and selections (e.g., choice of a circuit) which the user may execute. More particularly, each user has a list of network devices, link addresses, and application programs which the user may access. The network devices may include the T3AS 218, FRAD 248, CTS 224, and frame probe 228. The link addresses generally include the network (e.g., IP) addresses of the NEPA access device, i.e., at the location of the circuit(s) to be tested in the NUE 290. As described in the following sections, the application programs include first glance, frame data, statistics, and datascope.
Accordingly, at block 630, the NEPA server 210 determines which NEPA applications, access devices, and links, to display and allow the operator to access on the computer at the NMC 230. To do so, the NEPA server 210 stores characteristics information of the NEPA access device, such as type (e.g., frame sentry or frame probe), location on the NUE 290, and available links. The NEPA server 210 stores these access device information in a series of ASCII files which correlate to each user profile. Hence, at block 640, the NEPA server 210 may apply the user profile information to determine if the operator is permitted to access a particular option. If the user is permitted to access the option, at block 650 the NEPA server 210 determines to display that option to the operator. On the other hand, if the operator is not permitted to access the option, then the process proceeds to determine accessibility of a next option. At block 650, the NEPA server 210 determines if more options are remaining for the application tool. If there are more options to consider, the NEPA server 210 returns to block 640. If no more options remain for the application tool, then the process proceeds to
At block 680, the NEPA server 210 determines if a further test is requested by the operator. If more test are desired by the operator, the process returns to block 660. If no more tests are desired by the operator, the operator may log off the NEPA server 210 at block 685. At block 690, the NEPA server 210 determines if a reset or power-off action is requested. If so, the NEPA server 210 terminates the test sessions at block 695. If no power-off or reset is requested, the NEPA server 210 returns to block 610 to wait for the next operator log-on.
When running the first glance application, the NEPA server 210 may acquire the first glance information from the MIB 340 (
Generally, a NEPA Toolkit application, such as first glance, includes a MIB collection bar 750 which controls the collection mechanism of the PAE 320. For example, the operator may start and stop a collection session by clicking on a start 752 or stop 754 button, respectively. Additionally, the operator may select a live or file mode for the analysis by selecting the desired mode field 758. In live mode, the data is collected and displayed in real-time, or substantially near real-time. The operator may stop a live mode and save the collected data to a file stored in the operator's computer for later analysis by clicking on the save icon 751. In file mode, the operator may select a file for analyzing historical data. Moreover, the operator may indicate the link direction by specifying the E/F (incoming/outgoing data stream), or both in the direction field 753. The operator may indicate the polling interval by specifying the interval in seconds in the polling interval field 755. The operator may specify no filtering of data link connection identifiers (DLCIs) by specifying “all”, DLCI filtering is desired by specifying DLCI, or filtering a specific DLCI by specifying “one” in the filters field 757. Finally, the operator may specify a duration of the collection of data by specifying continuous or timed in the duration field 756. By selecting continuous duration, the operator may collect data continuously. By selecting the timed duration, the operator may collect data for a predetermined duration of time specified in hours, minutes, and seconds.
As shown in
An operator may view a bit stream in binary, decimal, hexadecimal, or ASCII formats in the view information field 950. Frame relay headers are displayed in binary format in the frame relay header field 955. The operator may click on a particular frame to view its respective header and payload information. The operator may also scroll up and down to view various frame information. The operator may set filter options by specifying DLCI or protocol type in the filters field 757, or direction in the direction field. Finally, in contrast with the other NEPA applications, the MIB collection bar 750 in the datascope application further includes a protocol field 960 and a frames field 970. The protocol field 960 specifies the signal protocol being examined. In effect, the protocol field 960 allows an operator to filter out frames which do not conform to the selected protocol. The operator may choose “Any Type” to disable the protocol filtering. Alternatively, the operator may specify a protocol such as Ethernet, IP, SNA, ATM, frame relay, frame relay multi-protocol, or bridging protocols. The frames field 970 provides a frame count of the collected frames.
As noted above, based on the user profile, the NEPA server 210 determines which NEPA application, and which application options, to provide to the operator. For example, the NEPA application may provide an operator with access to the datascope application. The datascope application uses user profile information to determine whether to restrict or allow the operator to view a datascope option, such as the header or payload information, view headers without a filter, and which filters are permitted.
The NEPA server 210 also provides a traffic-injection application which allows an operator to insert frame relay data (header and payload) into a network link. The traffic-injection application allows emulation of or replacing a link. Additionally, the traffic-injection application allows frame injection or addition into a network link. The operator specifies a frame to be injected by setting individual bits within the header and length of random payload data. The frame is injected a specified number of times using a predetermined CRC error rate. The NEPA access device simulates errors by providing an incorrect CRC number to egress frames. The traffic-injection application displays the total number of frames and corrupted frames in real-time, or substantially near real-time.
Therefore, the invention permits ubiquitous access to a NUE 290 without the need for investment in skilled technicians and expensive hardware or test equipment. The operator may have simultaneous access to multiple points across the network from a single NMC 290.
In view of the foregoing, it will be appreciated that the invention overcomes the long-standing need for a system and method of analyzing multiprotocol networks from a single site. The invention eliminates the need for dispatching technicians and expensive equipment to network boundaries to determine the source of a network malfunction. The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiment is to be considered in all respects only illustrative and not restrictive. The scope o f the invention is, therefore, indicated by the appended claims rather by the foregoing description. All changes which fall within the meaning and range of equivalency of the claims are to be embraced within their scope.