Note: Descriptions are shown in the official language in which they were submitted.
2 ~ ~ 8 `~
DISTRIBUTION OF NETWORK MANAGEMENT
COMMUNICATION VIA FRAME RELAY
Field of the Invention
The invention relates to communications networks.
Background of the Invention
In a ~eo~raphically dispersed network, there is a need to
send network management communication from a centralized
mana~er to the nodes at different sites. Traditionally,
network mana~ers 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 ~ ~ 1`connector for each node becomes prohibitive. ` --
With the advent of local and wide ar~a networking
technolo~y, recent ~enerations of network mana~ers use a
20 sin~le line interface connectin~ the network nodes. Employin~
a communication protocol that supports multiplexin~, network
mana~ement information is distribubd 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 sendin~ network management information. However, both
30 sysbms are inefficient. X.25 incorporates the functions of
error recovery, sequencin~, flow control and reset in the
successive network nodes. This requires significant ~ r,:''~''.`,',,:
processin~ in each node, which is costly and difficult to
implement in high-performance networks. IP does not - 1 `
35 maintain an end-to-end connection. This requires si~nificant
. . . ,- .
, ~,.,,:,
.
2 ~ 9 1
networking protocol overhead, whieh must be processed in
each successive network node. Very high performanee
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 Drawin~s
FIG. 1 is a generalized representation of a distributed
communication network.
FIG. 2 shows the distribution of network management
communications usin~ frame relay. -~-
FIG. 3 shows the frame relay frame format.
FIG. 4 represents the format of a 2-byte address field in
20 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
3 5 manager or the managed node.
. ~ , -
:. , . ~ -. . ~ . .
-`` ` 2 ~ k ~ '~ 9 ~
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
mana~ement information in either the network manager or the
managed node
Description of ths Drawin~s
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 multiplexin~ of channels to each ; `
node.
As compared to other networking protocols such as X.26,
the frame relay approach offers greater efficiency since it
requires lower processing overhead. Specifically, the ~ s~;
functions of error recovery, sequencing, flow control and
reset are done only at the endpoints of a Frame Relay ~ ,,,.,.,,r
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 mèthods. ` -` ; i'
FIG. 1 is a generalized representation of a dis1ributed
35 communication network 10. Network 10 allows data
"; ~
2 ~
transmission between users at different nodes 20. Eaeh node
20 may be eonnected to a variety of different data proeessing
equipment sueh as eomputer terminals 30, mainframe
computers 32, and loeal area networks (LANs) 34. A
5 eentralized network manager 40 permits network operators to
control the network by monitoring and interpreting key
activities of the eommunieation nodes. Also, the manager 40
is responsible for the eonfiguration of parameters and
funetionalities of eaeh node 20. The eommunieation from the
10 manager 40 to the nodes 20 is aeeomplished using frame relay.
The types of traffie inelude eommands 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 ~eneral deseription of frame relay may be found in
International Teleeommunieations Union Teleeommunieations ~i
Standardization Seetor (ITU-T) Reeommendation 1.233.1.
FIG. 2 shows the distribution of network management
eommunieations using frame relay. The network manager 100
has a frame relay proeessor 102 whieh is used for sendin~ and
receivin~ frames that eontain the network management
eommunieation. A frame relay eonneetion 110, 112, 114 is ~-
established between the network manager 100 and eaeh node
104, 106, 108. At the time the connection is established, a
speeific Data Link Connection Identifier (DLCI) is associated
with eaeh frame relay connection at each frame relay
interfaee 116, 1 18.
Information designated for or reeeived from a particular
node 104,106,108 is eneoded in frames that have a speeifie
DLCI. The frame relay processor 102 in the network mana~er
100 uses a frame relay interface to carry multiplexed frame -
relay conneetions aeross a frame relay interfaee 116 to a
frame handler node 104. The frame relay interface may
.,.; .,. ~ ,... ... ..
. :. ~ . . . ..
. : ~ .. . , ~ .... -
,
. ~ . ., . ., . ~ .
,; ~. . ..
" ,. ,' '~ ' ! ' ` ' ` ' `
2 1 ~
either terminate directly on frame handler node 104, or may
connect to the frame handler node through a network 120. If ~ -~
connected to the frame handler node, another frame relay -
interface 118 is present. The frame handler nods 104 also has
5 a frame relay interface to receive mana~ement information in
frame relay frames. Upon receipt of a call establishment ~ -
indication from the network manager, the frame handler node
104 Rstablishes connections between the manager 100 and all
other nodes 104,106,108 based on the nodes' addresses. -~
1 0
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
15 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 handler node 104 employs a
20 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~
CC)RE) (specified in the Annex A/a.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 -~ ~ -
delimibd by one or more 1-octet flag sequences 202 (encoded
as hexadecimal '7E'). The frame is made up of a 2-, 3- or 4~
-` .. , ~,''.
. . ,..... .~
oetet address field 204, a variable length frame relay
information field 206 and a 2-oetet frame eheek ssquenee
field 208. The address field 204 of the frame relay frame ~ -
200 is further deseribed below. The upper layer protoeols and
5 n~twork mana~ement information are eneoded in the
information field 206.
FIG. 4 represents the format of a 2-byte Address Field.
The address field is eomprised of a Data Link Connection
10 Identifier (DLCI), whieh is a 10-bit binary integer, eneoded in
two DLCI fields 300, 306. A Command/Response (C/R) bit
302 is provided for exelusive use of the DL-CONTROL protocol,
and is earried without modification by the frame relay bearer
serviee. The Forward Explieit Congestion Notifieation (FECN)
1 5 bit 308 and Baekward Explieit Congestion Notifieation (BECN)
bit 310 are used to indicate eongestion eonditions in-the
network. The Diseard Eligibility (DE) bit 312, when set to
binary '1', indicates a frame whieh should, during conditions
of severe congestion in the network, be discarded in
20 preferenee 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 eommunieation ,
protocol processing. The network manager 400 multiplexes
data from various management applications 402, such as
configuration, performance or event management, using a
30 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 Protoeol to Provide and
Support the Connectionless Network Serviee (CLNP, as
specified in ISO 8473). In addition, the upper layer stack 404
35 also provides means to recover from any loss or residual
~-
. ~.. , . . ~ ,
'2~ 8~1
eorruption or mis-ordering of data.
The information is formatted into DL-CONTROL frames ~-~
by the DL-CONTROL layer 406, which may also provide re~
5 transmission and flow control. It is further formatted into
frame relay frames by the DL-CORE layer 407 and transmitted
through the Physieal layer408. 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 eonverted into the
subnetwork protocol format 416. This format can be ehosen
for optimized internodal communication and it does not have - ;
15 to be frame relay. For example, Asynchronous Transfer Mode
(ATM) teehnology may be used as the internal transmission ~ -
format. In this case, the frame relay frame is converted into
multiple ATM C811S, in the manner specified in ITU-T
Reeommendations 1.555, 1.365.1, 1.363 and 1.360. - ~ -
2 0
The cells are then sent through the internodal links. At
the receiving node 418, the cells are then re-assembled into i
frame relay frames. The frame relay frames are then
proeessed using DL-CONTROL 420 and, and the content of the
25 information field is further processed by the upper layer
protoeol 422. The result is then directed to a plurality of ~ ~ `
agent applications 424.
Network management traffic is inherently bursty in i~
nature. The frame relay bearer service as defined in ITU-T
Reeommendation 1.233.1, and the eongestion strategy defined
in ITU-T Reeommendation 1.370 permits reservation of ~ -
transmission eapacity for each frame relay virtual connection.
The frame relay bearer service allows frame relay ~ '
" ~
; . . ~ , ,. . ~ . . - - ~ .
~1~8~9~ ;
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 FEC:N bit in the
address field prior to forwardin~ the frame to another node
418 or to the network mana~er 400. When the upper layer
protocol entities 404, 422 (respectively) incorporate a
protocol such as TP4, each maintains a runnin~ average of the
number of FECN bits it receives in successive frames. If this
runnin~ avera~e 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 strate~y also handles backward
congestion. When the frame handler node 410 detects that the
exhaust of bufferin~ resources for receivin~ 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
Ioss 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
3 5 the rate of transmission of network management information ~;
, ~ . .; .. - ..
,-
~, ... , . , , .. ~ . - , , ~ . - . . ..
-' 2 ~ 9 i
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 con~ested (sbp 504), then the frame
is checked to see if DE-1 (st~p 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 con~ested 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
mana~ement information in either the network manager or the
managed node. A frame is received (step 552). The value of - ~ ``" 5
the FECN bit in the frame is noted (step 554). The running -~
average of values of FECN bits received over a previous 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 - ~
'' ~ .`' ''' ~ '
' , ,
J i ` .~' . ': . . ~ : . . . '
-``` 21~8~9~
.
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 ths runninQ average of values of the FFCN bit is
greater than or equal to 50h FECN bits set to '1' (sbp 560),
and if the rate has not been reduced during the previous period
T (step 562), the rats of the transmitter is decreased (step
566). Otherwise, the rate remains the same.
1 0
FIG. 8 shows a different method of for further control of
network management information in either the network
mana~er or the managed node. After the frame is received
(sbp 602), the value of the BECN bit of the frame is checked
1 5 (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
(sbp 608), then the rate of the transmitter is increased (step
610). If the rate has been increased previously (step 608), the
rab is not increased.
If the BECN bit is set to ~1~ (sbp 606), and the rate has
not been reduced during previous time T (step 612), then me
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
(sbp 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
. "".'. ' i',,'',
- . .
:, .- ., -~ - . . . ..
`~` 21~8~9~
1 1 .
msthod of FIG. 9. If frame loss has not bsen detected during -
previous period of tims T (stsp 652) and if the rate has not
been increased during previous time T (step 654), the rate of
the transmitter is increased (sbp 656). Otherwise, the rate
5 remains the same.
We claim~
,; ~,: ~
., .. ~
'~ ~
".'.:~
, ~.~,,,,,. ~ "
: . .,. ~ ~..;
.. . . . . .
