WO1995008805A1

WO1995008805A1 - Distribution of network management communication via frame relay

Info

Publication number: WO1995008805A1
Application number: PCT/US1994/008928
Authority: WO
Inventors: Ronald S. Cheung; Yuval Gilbert; Daniel B. Grossman
Original assignee: Codex, Inc., A Subsidiary Company Of Motorola Inc.
Priority date: 1993-09-20
Filing date: 1994-08-08
Publication date: 1995-03-30
Also published as: CA2148491A1; EP0670065A1; AU7557794A; EP0670065A4

Abstract

A communication network has a network manager (400) that controls aspects of the operation of the network. The frame relay protocol is used to provide fan-out of network management communication from the network manager (400) to the nodes (418).

Description

DISTRIBUTION OF NETWORK MANAGEMENT COMMUNICATION VIA FRAME RELAY

Field of the Invention

The invention relates to communications networks.

Background of the invention

In a geographically dispersed network, there is a need to send network management communication from a centralized manager to the nodes at different sites. Traditionally, network managers have multiple physical connectors, each of which is connected to a different communication node. As the size of the network increases, the cost of providing a connector for each node becomes prohibitive.

With the advent of local and wide area networking technology, recent generations of network managers use a single line interface connecting the network nodes. Employing a communication protocol that supports multiplexing, network management information is distributed to each individual node via logical channels as defined by the communication protocol.

Some systems use X.25 protocol (as defined by the International Telecommunications Union Telecommunications Standardization Sector (ITU-T)), or the Internet Protocol (IP) for sending network management information. However, both systems are inefficient. X.25 incorporates the functions of error recovery, sequencing, flow control and reset in the successive network nodes. This requires significant processing in each node, which is costly and difficult to implement in high-performance networks. IP does not maintain an end-to-end connection. This requires significant networking protocol overhead, which must be processed in each successive network node. Very high performance realizations of IP are difficult and expensive to implement.

Thus, a networking protocol is needed which is more easily realized in high performance networks, and that is more efficient than either X.25 or IP.

Brief Description of the Drawings

FIG. 1 is a generalized representation of a distributed communication network.

FIG. 2 shows the distribution of network management communications using frame relay.

FIG. 3 shows the frame relay frame format.

FIG. 4 represents the format of a 2-byte address field in a frame relay frame.

FIG. 5 shows a layered model of the communication protocol processing.

FIG. 6 shows a method of communicating congestion information from a network node to either the manager or a managed node after connection is established.

FIG. 7 shows a flow chart for further control of network management information in either the network manager or the managed node.

FIG. 8 shows a different method of for further control of network management information in either the network manager or the managed node. FIG. 9 shows a further method for control of network management information in either the network manager or the managed node.

FIG. 10 shows a a further method for control of network management information in either the network manager or the managed node

Description of the Drawings

The frame relay protocol is used to provide fan-out of network management communication from the network manager to the nodes. In this case, communication to each node is transported via virtual connections of the frame relay protocol. An upper layer protocol stack, e.g. TP4/CLNP (Class 4 Transport Protocol {TP4, as specified in ISO 8073} and the OSI Protocol to Provide and Support the Connectionless Network Service {CLNP, as specified in ISO 8473}), provides reliable communication and multiplexing of channels to each node.

As compared to other networking protocols such as X.25, the frame relay approach offers greater efficiency since it requires lower processing overhead. Specifically, the functions of error recovery, sequencing, flow control and reset are done only at the endpoints of a Frame Relay connection, and are not done in the successive network nodes. However, an end-to-end connection is maintained, minimizing processing while handling individual data packets and minimizing networking protocol overhead. These efficiencies allow for more cost-efficient realization than other methods.

FIG. 1 is a generalized representation of a distributed communication network 10. Network 10 allows data transmission between users at different nodes 20. Each node 20 may be connected to a variety of different data processing equipment such as computer terminals 30, mainframe computers 32, and local area networks (LANs) 34. A centralized network manager 40 permits network operators to control the network by monitoring and interpreting key activities of the communication nodes. Also, the manager 40 is responsible for the configuration of parameters and functionalities of each node 20. The communication from the manager 40 to the nodes 20 is accomplished using frame relay. The types of traffic include commands from the manager 40, responses from the nodes 20, events from the nodes 20 and software downloads from the manager 40 to the nodes 20.

A general description of frame relay may be found in

International Telecommunications Union Telecommunications Standardization Sector (ITU-T) Recommendation 1.233.1.

FIG. 2 shows the distribution of network management communications using frame relay. The network manager 100 has a frame relay processor 102 which is used for sending and receiving frames that contain the network management communication. A frame relay connection 110, 112, 114 is established between the network manager 100 and each node 104, 106, 108. At the time the connection is established, a specific Data Link Connection identifier (DLCI) is associated with each frame relay connection at each frame relay interface 116, 118.

Information designated for or received from a particular node 104,106,108 is encoded in frames that have a specific DLCI. The frame relay processor 102 in the network manager 100 uses a frame relay interface to carry multiplexed frame relay connections across a frame relay interface 116 to a frame handler node 104. The frame relay interface may either terminate directly on frame handler node 104, or may connect to the frame handier node through a network 120. If connected to the frame handler node, another frame relay interface 118 is present. The frame handler node 104 also has a frame relay interface to receive management information in frame relay frames. Upon receipt of a call establishment indication from the network manager, the frame handler node 104 establishes connections between the manager 100 and all other nodes 104,106,108 based on the nodes' addresses.

Upon receipt of the frame relay frames, the frame handler node 104 first disassembles the frame relay protocol. Based on the content of the DLCI (data link connection identifier), frame handler node 104 may direct the information for internal processing, or convert the frame into an internodal format for transmission to the destination node 106,108 for further processing.

Every node including frame handier node 104 employs a frame relay processor for disassembling the frame relay frames to obtain the manager 's commands, and constructing the frame relay frames based on information to be sent back from the node. The frame relay processor implements the formats and elements of procedures of the standardized Link Access Procedure for Frame Mode Bearer Services (LAPF), as specified in ITU-T Recommendation Q.922. In particular, the LAPF protocol is comprised of a data link core protocol (DL- CORE) (specified in the Annex A/Q.922) and the data link control (DL-CONTROL) protocol (specified in the main text). Either the acknowledged or the unacknowledged mode of the DL-CONTROL protocol can be used.

FIG. 3 shows the frame relay frame format. Frame 200 is delimited by one or more 1 -octet flag sequences 202 (encoded as hexadecimal '7E'). The frame is made up of a 2-, 3- or 4- octet address field 204, a variable length frame relay information field 206 and a 2-octet frame check sequence field 208. The address field 204 of the frame relay frame 200 is further described below. The upper layer protocols and network management information are encoded in the information field 206.

FIG. 4 represents the format of a 2-byte Address Field. The address field is comprised of a Data Link Connection Identifier (DLCI), which is a 10-bit binary integer, encoded in two DLCI fields 300, 306. A Command/Response (C/R) bit 302 is provided for exclusive use of the DL-CONTROL protocol, and is carried without modification by the frame relay bearer service. The Forward Explicit Congestion Notification (FECN) bit 308 and Backward Explicit Congestion Notification (BECN) bit 310 are used to indicate congestion conditions in the network. The Discard Eligibility (DE) bit 312, when set to binary '1', indicates a frame which should, during conditions of severe congestion in the network, be discarded in preference to frames which have the DE bit set to binary ^*0\ The Extended Address (EA) bits 304, 314 are used to indicate the length of the Address Field. Details of a 3 or 4-byte address field are specified in the ITU-T Recommendation Q.922 Annex A.

FIG. 5 shows a layered model of the communication protocol processing. The network manager 400 multiplexes data from various management applications 402, such as configuration, performance or event management, using a upper layer protocol stack 404, e.g. the Open Systems

Interconnection (OSI) Class 4 Transport Protocol (TP4, as specified in ISO 8073) and the OSI Protocol to Provide and Support the Connectionless Network Service (CLNP, as specified in ISO 8473). In addition, the upper layer stack 404 also provides means to recover from any loss or residual corruption or mis-ordering of data.

The information is formatted into DL-CONTROL frames by the DL-CONTROL layer 406, which may also provide re- transmission and flow control. It is further formatted into frame relay frames by the DL-CORE layer 407 and transmitted through the Physical layer 408. At the frame handler node 410, the frame relay frames are received using the physical layer PH 412. The frame relay frames then are delimited and processed by the DL-CORE layer 414. If the DLCI corresponds to a virtual connection to another node, the frame relay frames as shown in FIG. 3 will be converted into the subnetwork protocol format 416. This format can be chosen for optimized internodal communication and it does not have to be frame relay. For example, Asynchronous Transfer Mode (ATM) technology may be used as the internal transmission format. In this case, the frame relay frame is converted into multiple ATM cells, in the manner specified in ITU-T Recommendations I.555, 1.365.1 , I.363 and I.360.

The cells are then sent through the internodal links. At the receiving node 418, the cells are then re-assembled into frame relay frames. The frame relay frames are then processed using DL-CONTROL 420 and, and the content of the information field is further processed by the upper layer protocol 422. The result is then directed to a plurality of agent applications 424.

Network management traffic is inherently bursty in nature. The frame relay bearer service as defined in ITU-T Recommendation 1.233.1 , and the congestion strategy defined in ITU-T Recommendation I.370 permits reservation of transmission capacity for each frame relay virtual connection.

The frame relay bearer service allows frame relay virtual connections to contend for transmission capacity in excess of that reserved for them. When the load perceived by the frame handler node 410 in FIG. 5 is in excess of the node's 410 optimal operating point, it sets the FECN bit in the address field prior to forwarding the frame to another node 418 or to the network manager 400. When the upper layer protocol entities 404, 422 (respectively) incorporate a protocol such as TP4, each maintains a running average of the number of FECN bits it receives in successive frames. If this running average exceeds 50 percent, the upper layer protocol 422 instructs its peer entity 404, respectively, to slightly reduce its data transmission rate. When the running average of the FECN bits becomes less than 50 percent, the upper layer protocol instructs its peer to slightly increase its data transmission rate.

The congestion strategy also handles backward congestion. When the frame handler node 410 detects that the exhaust of buffering resources for receiving data is imminent, the node sets the BECN bit in any frame relay frames sent toward the source of the congestion-inducing traffic. The BECN bit can be used by the DL-CONTROL protocol entities 406, 420 (respectively) to sharply reduce its data transmission rate when the acknowledged mode of LAPF is used. When the DL-CONTROL entity 406,420 does not receive any BECN bit within a certain interval of time, it increases its data transmission rate. Should neither the FECN nor the BECN mechanism reduce the congestion in the node, frames must be discarded. Detection of loss of frames by the upper layer protocol entity 404, 422 (respectively) causes it to instruct its peer to sharply reduce its rate. Similarly, detection of loss of frames causes the acknowledged mode of LAPF to sharply reduce its rate. In this manner, the DL-CONTROL and/or the upper layers cooperate with the network to match the rate of transmission of network management information to the present capacity of the network to convey said information.

FIG. 6 shows a method of communicating congestion information from a network node to either the manager or a managed node after connection is established. After the connection is established, a frame is received (step 502). If the network is severely congested (step 504), then the frame is checked to see if DE=1 (step 506), indicating that the frame is to be discarded in preference to frames with DE ■= 0, e.g., because the frame was sent in excess of parameters previously configured. If so, the frame is discarded (step 508).

If the network was not severely congested or if DE was not 1 , then the network is tested to see if it is at least moderately congested (step 510) in the direction opposite the direction of transmission of the frame. If so, the BECN bit is set in the frame.

If the network is operating in excess of its optimum operating point, (step 514), the FECN bit of the frame is set (step 516). The process ends when the frame is forwarded to the next node in the network or to the network manager (step 518).

FIG. 7 shows a flow chart for further control of network management information in either the network manager or the managed node. A frame is received (step 552). The value of the FECN bit in the frame is noted (step 554). The running average of values of FECN bits received over a revious period, T, is recomputed (step 556). If the running average of number of FECN bits received over said period is less than 50% set (step 558), and if the rate has not been increased during the previous period T (step 560), then the rate of the transmitter is increased (step 564). If the running average is less than 50% (step 558), and if the rate has been increased during the previous time T (step 560), then the process ends.

If the running average of values of the FECN bit is greater than or equal to 50% FECN bits set to (step 560), and if the rate has not been reduced during the previous period T (step 562), the rate of the transmitter is decreased (step 566). Otherwise, the rate remains the same.

FIG. 8 shows a different method of for further control of network management information in either the network manager or the managed node. After the frame is received (step 602), the value of the BECN bit of the frame is checked (step 604). If the BECN bit is not set to "1" (step 606), and the rate has not been increased during previous period of time T (step 608), then the rate of the transmitter is increased (step 610). If the rate has been increased previously (step 608), the rate is not increased.

If the BECN bit is set to "1" (step 606), and the rate has not been reduced during previous time T (step 612), then the rate is reduced (step 614). Otherwise, the rate is not reduced.

FIG. 9 shows a further method for control of network management information in either the network manager or the managed node, which may be used alone or in combination with the methods shown in FIG. 7 or 8. If a frame loss is detected (step 627) and if the rate has not been reduced during a previous time T (step 629), then the transmit rate is reduced (step 631 ).

FIG. 10 shows a a further method for control of network management information in either the network manager or the managed node, which may be used in combination with the method of FIG. 9. If frame loss has not been detected during previous period of time T (step 652) and if the rate has not been increased during previous time T (step 654), the rate of the transmitter is increased (step 656). Otherwise, the rate remains the same.

We claim:

Claims

1. A network manager communication system for sending communication between a network manager and a network having at least two nodes comprising:

the network manager having a frame relay processor for constructing frame relay frames containing the communication;

the nodes having a frame relay processor for

(a) switching frame relay frames based upon the data link connection identifier of the frame relay frames and

(b) disassembling the frame relay frames, and (c) constructing the frame relay frames; and

(d) detecting congestion conditions in said node.

the network manager communicating with the nodes by frame relay.

2. The network of claim 1 where the frame relay frames includes an end-to-end transport protocol.

3. The network of claim 1 where each node has a frame relay processor.

4. The network of claim 2 where at least one node is a frame handler node has a physical interface where frame relay frames are transported to the node from the network manager.

5. A method of communicating information from a network manager to a plurality of nodes in a network after establishing connection comprising the steps of:

at the network manager: converting the management application information into frame relay frames; sending the frame relay frames to a frame handler node; at the frame handler node: obtaining the destination node data link connection identifier by_, disassembling the frame relay frames; if the data link connection identifier is for another node in the network, converting the frame relay frames into internodal frames; sending the converted frames to the corresponding node; at the node: converting the internodal frames to frame relay frames; disassembling the frame relay frames to obtain the management information.

6. The method of claim 5 wher the step of converting the information into frame relay frames includes the further step of multiplexing the information and where the step of disassembling the frame relay frames to obtain the information includes the further step of demultiplexing the information.

7. The method of claim 5 including the further steps of communicating information from the nodes to the network manager comprising: at the nodes: converting the agent application information into frame relay frames; converting the frame relay frames into internodal frames; senH^;ng the internodal frames to the frame handler node; at the frame handler node: converting the internodal frames into frame relay frames; sending the frame relay frames to the network manager; at the network manager: disassembling the frame relay frames into information; processing the information.

8. The method of claim 5, including the further steps of setting a forward explicit congestion notification bit in the frame relay frame when the frame relay processor detects transmission in excess of its optimal operating point; and setting a backward explicit congestion notification bit in the frame relay frame being conveyed toward traffic sources when the frame relay processor detects a state of moderate congestion, and discarding frames during periods of severe congestion

9. The method of claim 8, including the further steps of: reducing the rate of transmission of frame relay frames containing management information in response to receipt of frames, when said frames have the forward explicit congestion notification bit set to binary '1 ' with a density of 50% or greater as measured over a certain interval of time; and increasing the rate of transmission of frame relay frames containing management information in response to receipt of frames, when said frames have the forward explicit congestion notification bit set to binary '1 ' with a density of less than 50% as measured over a certain interval of time.

10. The method of claim 8, including the further steps of: reducing the rate of transmission of frame relay frames containing management information in response to receipt of at least one frame, when said frame has the backward explicit congestion notification bit set to binary '1 '; and increasing the rate transmission of frame relay frames containing management information when it does not receive at least one frame having the backward explicit congestion notification bit set to binary within a certain interval of time.