WO 2016/158541

PCT7JP2016/058881

[DESCRIPTION]
[Title of Invention]
METHOD FOR TRAFFIC MANAGEMENT AT NETWORK NODE,
AND NETWORK NODE IN PACKET-SWITCHED NETWORK
[Technical Field]
[0001]
The present disclosure relates to the field of packet flow processing in a packet-switched network node, in particular for Ethernet frames processing at a network node in an Ethernet-based network. [Background Art] [0002]
Packet-switched networks, and in particular Ethernet, are more and more used in domains other than data communications. [0003]
In particular, a number of industrial networks are known to use customized versions of Ethernet or protocols derived therefrom. In addition, the industrial network specifications published as "Profibus" and "Profinet" by the PROFIBUS and PROFINET International (PI) organization provide for the possibility to use Ethernet-based technology in industrial networks for automation applications. [0004]
The evolution introduced by these technologies mainly focuses on the improvement of the resilience of these networks: protection against single failure without affecting the data transmission rate. Standards such as the High-availability Seamless Redundancy (HSR) standardized by the International Electrotechnical Commission as IEC 62439-3 Clause 5, the Parallel Redundancy Protocol (PRP), standardized by the IEC as IEC 62439-3 Clause 4, and the Media Redundancy Protocol (MRP), standardized by the IEC as IEC 62439-2,
l

WO 2016/158541 PCT7JP2016/058881
have been developed so that they can be used in Ethernet-based industrial
networks.
[Summary of Invention]
[Technical Problem]
[0005]
However, industrial networks have specific constraints, such as the enforcement of strict temporal properties of the data transmission, which cannot be implemented using standard Ethernet. In particular, the transmission of control/command messages that requires tightly bounded latency and/or jitter, as well as a strict lossless transport, is not properly addressed in the currently available Ethernet specifications. [0006]
These properties can be enforced by applying network resource (buffer and bandwidth) reservation schemes, for ensuring that network resources are not oversubscribed, traffic shaping and scheduling mechanisms, for ensuring that the traffic is emitted according to the reserved resources, and traffic policing schemes for ensuring that there is no failing or misbehaving traffic source disturbing the resource reservation/traffic shaping equilibrium. [0007]
Traffic policing techniques have been implemented in telecommunication networks to enforce traffic contracts at specific network interfaces, such as those linking different carrier networks. A traffic contract (also referred to as a "Service Level Agreement", or SLA, in the related art) typically comprises a set of traffic parameters applicable to one or more data flows to be transported over a service network between two termination ends. The service provided by the network may be, for example, related to the control of an automat by a central controller, the transfer of video data at a certain transmission rate, etc. A traffic contract can be specified in general for any data flow carried through a network between a source and a destination, as a set of requirements related to the
2

WO 2016/158541 PCT7JP2016/058881
transportation of the data flow through the network (e.g. transmission rate, transmission time, jitter, packet size, etc.). The transportation of data associated with the flow over the network in compliance with the contract will require the fulfillment of the requirements defined in the contract. These requirements will generally be defined by the type of service provided by the data communication network. [0008]
As far as Ethernet is concerned, the IEEE Standard for Local and metropolitan area networks 802.1Q - 2005, entitled "Virtual Bridged Local Area Networks", includes a frame metering framework in clause 8.6.5 ("Flow classification and metering") and clause 8.6.7 (Queue Management). However this framework does not specify any specific metering algorithm, and merely refers to the metering algorithm described in the Metro Ethernet Forum Technical Specification MEF 10 as well as to the queue management algorithms specified in the IETF RFC 2309 (including the Random Early Decision (RED) algorithm and the Weighted Random Early Detection (WRED) algorithm). [0009]
Frame metering was introduced in the IEEE 802.1Q standard in order to provide a framework for setting and using the "drop eligible" parameter indicated by the DEI (Drop Eligibility Indication) in the S- and C-VLAN tags of the frames. [0010]
This standard specification was kept minimal in order to allow flexibility of implementation and adaptability to different target markets, such as the interconnection of metropolitan Ethernet networks for which the Metro Ethernet Forum (MEF) has specified the so-called bandwidth profiles. [0011]
The IEEE 802.1Q-2005 Standard clause 8.6.5 specifies the use of optional ingress meters, whose role is to set the drop eligible parameter associated with a
3

WO 2016/158541 PCT7JP2016/058881
frame. All frames handled by a given meter come from the same reception port and classification of frames, based on any combination of parameters including Destination Address (DA), Source Address (SA), VLAN Identifier (VID), and priority, for the application of different meters is possible. Metering is applied before the bridge queues and after all filtering functions (active topology enforcement, ingress VID, Filtering Database (FDB) and egress VID). Although the metering algorithm is not specified, the MEF algorithm is referenced. A two-color (green and yellow) scheme is made possible by using the DEI bit, extended with a third color (red) reserved to always-discarded frames. [0012]
With respect to queue management, the IEEE 802.1Q-2005 Standard clause 8.6.7 loosely specifies how to exploit the color indication carried by the frames: drop-eligible frames may have a higher probability of being discarded than non-drop-eligible frames. The implementer is free to choose a queue management scheme, such as, for example, tail-drop with different color thresholds, Random Early Detection, or Weighted Random Early Detection. [0013]
The Metro Ethernet Forum (MEF) Technical Specification MEF 10.3, entitled "Ethernet Services Attributes Phase 3", and dated October 2013, includes a policing algorithm, referred to as "Bandwidth profiles", which is based on a frame "colouring" scheme. [0014]
According to the MEF scheme, the color of a service frame is an attribute determined by the arrival time of the service frame at a meter relative to the history of arrival times of previous frames. In this respect the color is an attribute of a service frame different from its priority, which is attached to the service frame and determined by its contents. [0015]
4

WO 2016/158541 PCT7JP2016/058881
However, the MEF Technical Specification only provides a traffic metering algorithm for verifying the compliance or non-compliance to a service contract for incoming service frames. It does not specify a traffic policing algorithm or a traffic shaping algorithm, so that its efficiency for ensuring compliance to strict temporal properties and data loss properties of data transmissions, in particular in the context of use in industrial networks, is limited. Said otherwise, the MEF technical specification may not sufficiently provide the means for ensuring compliance to requirements defined in a service contract. [0016]
There is therefore a need for providing an improved data traffic management scheme and network node implementing the same that address the above-described drawbacks and shortcomings of the conventional technology in the art. [0017]
It is an object of the present subject disclosure to provide an improved data traffic management scheme and network node implementing the same. [0018]
Another object of the present subject disclosure is to provide an improved traffic management scheme and network node implementing the same for alleviating the above-described drawbacks and shortcomings of conventional data traffic control schemes. [0019]
Yet another object of the present subject disclosure is to provide an improved traffic management scheme and network node implementing the same for ensuring compliance with traffic profile requirements with respect to transportation of data in a network. [0020]
To achieve these objects and other advantages and in accordance with the purpose of the present subject disclosure, as embodied and broadly described
5

WO 2016/158541 PCT7JP2016/058881
herein, in one aspect of the present subject disclosure, a method for traffic management at a network node in a packet-switched network, the network node comprising at least one egress port for outputting packets belonging to a packet flow, and one or several ingress ports for receiving incoming packets of the packet flow, is proposed. The method comprises: perform traffic shaping on a current packet belonging to the packet flow and stored in a memory queue associated with the packet flow, the traffic shaping comprising, if a theoretical reception time, TRT, value of the current packet is smaller than or equal to a time counter value, output the current packet through the egress port. According to the proposed method, the TRT value of the packet is determined by performing traffic policing of incoming packets of the packet flow, using, when a previous packet of the packet flow received before the current packet has not been discarded by traffic policing, a size of the previous packet, a transmission rate value associated with the flow, and, if a TRT value of the previous packet is greater than an actual reception time, ART, value of the previous packet, using the TRT value of the previous packet, and otherwise using the ART value of the previous packet, or, when the previous packet has been discarded by traffic policing, using the TRT value of the previous packet. [0021]
In the case of networks transporting time and loss sensitive control and command flows, both ingress traffic policing and egress traffic shaping may advantageoulsy be applied in order to guarantee that the messages are transmitted in a secure (without any loss) and timely (with a guaranteed bandwidth and a minimal jitter) way. In addition, ingress policing allows handling and mitigating faulty operation of network nodes: replication of frame (queuing error), excessive transmission rate (shaping error), longer frames (tagging/padding error), forwarding in wrong transmission queue (switching error), excessive bridge/switch delay (hardware/software default), "babbling" node (faulty source or switch).
6

WO 2016/158541

PCT7JP2016/058881

[0022]
The proposed method advantageously provides a traffic shaping scheme and a traffic policing scheme which cooperate with each other, through the use at the traffic shaping stage of TRT values which have been determined by the traffic policing scheme. As such, the proposed method provides the cooperative operation of traffic shaping and policing. [0023]
In one or more embodiments, the proposed method may further provide that the traffic policing includes discarding a received packet that belongs to the packet flow whose size exceeds the available space in the memory queue associated with the packet flow. [0024]
In one or more embodiments of the proposed method, the traffic policing is performed at iterations of a traffic policing loop, an iteration of the traffic policing loop being executed when the time counter value has been incremented by at least one time unit. [0025]
In addition, the traffic shaping may also be performed at iterations of a traffic shaping loop, an iteration of the traffic shaping loop being executed when the time counter value has been updated. In one or more embodiments, such update may comprise incrementing the time counter, and an iteration of the traffic shaping loop may be executed when the time counter value has been incremented by at least one time unit. In other embodiments, such update may comprise shifting the time counter value used for traffic shaping by an offset for the next iteration of the traffic shaping loop, and an iteration of the traffic shaping loop may be executed when the time counter value has been shifted by a time offset. [0026]
7

WO 2016/158541 PCT7JP2016/058881
Operating the traffic policing and/or traffic shaping as loops driven by the above-mentioned time counter advantageously makes use of a single time reference for the traffic policing and traffic shaping, for example through the same time counter or through respective time counters based on the same time reference and shifted by a time offset (between the traffic shaping time counter and the traffic policing time counter). The traffic policing scheme being typically performed at an ingress port, and the traffic shaping scheme being typically performed at an egress port, this creates an opportunity to use the same time reference at both ingress and egress ports. This common time reference may also advantageously be designed to be used by all the ports at the level of a network node, but also by multiple network nodes in the packet-switched network. [0027]
This use of common parameters for the traffic shaping and traffic policing also decreases the complexity of implementation of those features, which is beneficial for the design of the network node implementing the same. [0028]
In one or more embodiments of the proposed method, when the TRT value TRT^l_1 of the previous packet is greater than the ART value ART^l_1 of the previous packet, the TRT value of the packet TRT^ may be determined as :
■ U i\ ■ ■ •
TRT£ = TRT^ + nyR. , where TRT^ is the TRT value of the previous
packet, 5^_x is the size of the previous packet, and Rt is the transmission rate value associated with the flow. Otherwise, when the TRT value TRT^l_1 of the previous packet is smaller than or equal to the ART value ART^-i of the previous packet, the TRT value of the packet TRT„ may be determined as :
8

WO 2016/158541 PCT7JP2016/058881
TRTi = ART^ + SnyR. L where ART^ is the ART value of the previous
packet, S^-i is the size of the previous packet, and Rt is the transmission rate value associated with the flow. In addition, when the previous packet has been discarded by traffic policing, the TRT value of the packet TRT£ may be determined as: TRT^ = TRT^-i, where TRT^-i is the TRT value of the previous packet. [0029]
In one or more embodiments of the proposed method, the ART value of the previous packet is determined using a value of the time counter corresponding to the reception of the previous packet at one of the one or several ingress ports. [0030]
In one or more embodiments of the proposed method, packets belonging to different flows are stored with respective TRT values in memory queues respectively associated with the flows, and the method further comprises: selecting the current packet according to its TRT value among head packets with respective smallest TRT values in the memory queues. Advantageously, the packet may be selected according to its TRT value being the smallest of respective TRT values of head packets of the memory queues. [0031]
Embodiments of the proposed solution advantageously provide joint policing and scheduling of time and loss sensitive flows that may be multiplexed through switching queues, based on a single time reference and theoretical per-flow schedule. The flow jitter or burst tolerance enforced by the policing function is directly coupled to the amount of available buffer reserved for the flow queue in egress ports. [0032]
9

WO 2016/158541 PCT7JP2016/058881
According to another aspect, a network node in a packet-switched network comprising a processor, a memory, operatively coupled to the processor, at least one egress port for outputting packets belonging to a packet flow, and one or several ingress ports for receiving incoming packets of the packet flow, wherein the network node is configured to perform a method for traffic management according to the proposed methods of the present subject disclosure, is proposed. [0033]
According to yet another aspect, a non-transitory computer-readable medium encoded with executable instructions which, when executed, causes a network node comprising a processor operatively coupled with a memory, to perform a method for traffic management according to the proposed methods of the present subject disclosure, is proposed. [0034]
According to yet another aspect, a computer program product comprising computer program code tangibly embodied in a computer readable medium, said computer program code comprising instructions to, when provided to a computer system and executed, cause said computer to perform a method for traffic management according to the proposed methods of the present subject disclosure, and a data set representing, for example through compression or encoding, a computer program, are proposed. [0035]
It should be appreciated that the present invention can be implemented and utilized in numerous ways, including without limitation as a process, an apparatus, a system, a device, and as a method for applications now known and later developed. These and other unique features of the system disclosed herein will become more readily apparent from the following description and the accompanying drawings. [Brief Description of the Drawings]
10

WO 2016/158541

PCT7JP2016/058881

[0036]
[Fig. 1]
Figure 1 is a schematic diagram illustrating an exemplary industrial network, in accordance with one or more embodiments. [Fig. 2]
Figure 2 is a block diagram illustrating exemplary functionality of a network node, in accordance with one or more embodiments. [Fig. 3]
Figure 3 is a block diagram illustrating exemplary functionality of an egress port of a network node, in accordance with one or more embodiments. [Fig- 4]
Figure 4 is a flow chart illustrating an exemplary traffic policing process, in accordance with one or more embodiments. [Fig. 5]
Figure 5 is a flow chart illustrating an exemplary traffic shaping process, in accordance with one or more embodiments. [Fig. 6]
Figure 6 is a flow chart illustrating an exemplary traffic shaping process, in accordance with one or more embodiments. [Fig. 7a]
Figure 7a illustrates reception and transmission operations at a network node, in accordance with one or more embodiments. [Fig. 7b]
Figure 7b illustrates reception and transmission operations at a network node, in accordance with one or more embodiments. [Description of Embodiments] [0037]
For simplicity and clarity of illustration, the drawing figures illustrate the general manner of construction, and descriptions and details of well-known
11

WO 2016/158541

PCT7JP2016/058881

features and techniques may be omitted to avoid unnecessarily obscuring the discussion of the described embodiments of the invention. Additionally, elements in the drawing figures are not necessarily drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of embodiments of the present invention. Certain figures may be shown in an idealized fashion in order to aid understanding, such as when structures are shown having straight lines, sharp angles, and/or parallel planes or the like that under real-world conditions would likely be significantly less symmetric and orderly. The same reference numerals in different figures denote the same elements, while similar reference numerals may, but do not necessarily, denote similar elements. [0038]
In addition, it should be apparent that the teaching herein can be embodied in a wide variety of forms and that any specific structure and/or function disclosed herein is merely representative. In particular, one skilled in the art will appreciate that an aspect disclosed herein can be implemented independently of any other aspects and that several aspects can be combined in various ways. [0039]
The present disclosure is described below with reference to functions, engines, block diagrams and flowchart illustrations of the methods, systems, and computer program according to one or more exemplary embodiments. Each described function, engine, block of the block diagrams and flowchart illustrations can be implemented in hardware, software, firmware, middleware, microcode, or any suitable combination thereof. If implemented in software, the functions, engines, blocks of the block diagrams and/or flowchart illustrations can be implemented by computer program instructions or software code, which may be stored or transmitted over a computer-readable medium, or loaded onto a general purpose computer, special purpose computer or other programmable
12

WO 2016/158541 PCT7JP2016/058881
data processing apparatus to produce a machine, such that the computer program instructions or software code which execute on the computer or other programmable data processing apparatus, create the means for implementing the functions described herein. [0040]
Embodiments of computer-readable media includes, but are not limited to, both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. As used herein, a "computer storage media" may be any physical media that can be accessed by a computer or a processor. In addition, the terms « memory » and « computer storage media" include any type of data storage device, such as, without limitation, a hard drive, a flash drive or other flash memory devices (e.g. memory keys, memory sticks, key drive), CD-ROM or other optical storage, DVD, magnetic disk storage or other magnetic storage devices, memory chip(s), Random Access Memory (RAM), Read-Only-Memory (ROM), Electrically-erasable programmable read-only memory (EEPROM), smart cards, or any other suitable medium from that can be used to carry or store program code in the form of instructions or data structures which can be read by a computer processor, or a combination thereof. Also, various forms of computer-readable media may transmit or carry instructions to a computer, including a router, gateway, server, or other transmission device, wired (coaxial cable, fiber, twisted pair, DSL cable) or wireless (infrared, radio, cellular, microwave). The instructions may comprise code from any computer-programming language, including, but not limited to, assembly, C, C++, Visual Basic, SQL, PHP, and JAVA. [0041]
Unless specifically stated otherwise, it will be appreciated that throughout the following description discussions utilizing terms such as processing, computing, calculating, determining, or the like, refer to the action or processes
13

WO 2016/158541 PCT7JP2016/058881
of a computer or computing system, or similar electronic computing device, that manipulate or transform data represented as physical, such as electronic, quantities within the registers or memories of the computing system into other data similarly represented as physical quantities within the memories, registers or other such information storage, transmission or display devices of the computing system. [0042]
The terms "comprise," "include," "have," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. [0043]
Additionally, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. [0044]
In the following description and claims, the terms "coupled" and "connected", along with their derivatives, may be used. In particular embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. [0045]
As used herein, the term packet may include a unit of data that may be routed or transmitted between nodes or stations or across a network. As used herein, the term packet may include frames, protocol data units or other units of
14

WO 2016/158541 PCT7JP2016/058881
data. A packet may include a group of bits, which may include one or more address fields, control fields and data, for example. A data block may be any unit of data or information bits. [0046]
It should be understood that embodiments of the present subject disclosure may be used in a variety of applications. Although the present invention is not limited in this respect, the method for traffic management disclosed herein may be used in many apparatuses such as in any network node of a packet-switched network, such as, for example, an Ethernet switch, an Ethernet bridge, or an Ethernet router. For clarity, the following description focuses on Ethernet networks. However, technical features of the present invention are not limited thereto. [0047]
Figure 1 illustrates an exemplary Ethernet-based industrial network 10 comprising an Ethernet service provider network 12 to which Customer Equipment (CE) devices 13a - 13c attach through respective Ethernet User-Network Interfaces (UNI) 14a - 14c using a standard Ethernet interface, such as a 10 Mbps, 100 Mbps, 1 Gbps, or 10 Gbps Ethernet interface. Ethernet services are provided to the CE devices 13a - 13c by the Ethernet service provider network 12 which includes a plurality of network nodes 11 a-lie in which embodiments of the present subject disclosure may be used. [0048]
The network nodes 11a - lie may be configured as Ethernet provider edge switches, and may be connected to one another in a ring topology using network connections 15a - 15c. The Ethernet service provider network may be, for example, an Ethernet metropolitan area network (MAN), or an Ethernet wide area network (WAN), and may include any other network nodes (not shown on the figure), such as, for example, switches or bridges. [0049]
15

WO 2016/158541 PCT7JP2016/058881
It will be appreciated by those having ordinary skill in the relevant art that any suitable network topology, such as, for example, a tree topology or a mesh topology, may be used in place of the ring topology for network 12 which is given by way of example only. [0050]
In one or more embodiments, the network 12 may be operated so that it provides respective Quality of Service (QoS) levels to subscribers, or applications in the context of industrial networks (e.g. automation control, video transfer, software update/upgrade, etc.), the QoS levels including packet loss properties and transmission time properties. From a subscriber/application's standpoint, the QoS levels provided by the network 12 may translate into so-called "bandwidth profiles" which define QoS parameters and/or traffic parameters (e.g. maximum transport delay, maximum delay variation (jitter), etc.). [0051]
As used herein, the term packet flow or flow may include a set of packets sharing one or several common parameters, such as, for example, an address, a source and/or a destination, a circuit identifier, an identifier, a type of transported protocol, a VLAN, a VID, a pair of addresses (for example a SA and DA), or a combination thereof. [0052]
Bandwidth profiles may be provided for each flow serviced by the network, or for a group of flows serviced by the network. [0053]
In accordance with embodiments of the present subject disclosure, one of the edge network nodes 1 la - lie implements a traffic management function for enforcing bandwidth profiles. [0054]
16

WO 2016/158541

PCT7JP2016/058881

Fig. 2 illustrates an exemplary network node 20 configured to use a traffic management feature in accordance with embodiments of the present subject disclosure. [0055]
The network node 20 includes a control engine 21, a switch engine 25, a multiplexing engine 26, a traffic policing engine 27, a traffic shaping engine 28, a plurality of ports 22a-d, a time reference engine 29, and a memory 23. [0056]
In the architecture illustrated on Fig. 2, all of the switch engine 25, multiplexing engine 26, traffic policing engine 27, traffic shaping engine 28, plurality of ports 22a-d, time reference engine 29, and memory 23 are operatively coupled with one another through the control engine 21. [0057]
In one embodiment, each of the ports 22a-d includes an Ethernet interface, so as to be coupled to an Ethernet link, and is capable of transmitting and receiving packets. In addition, one of the ports 22a, referred to as "egress" port, may be configured for transmitting outgoing packets, while a plurality of other ports 22b, 22c, 22d, referred to as "ingress" ports, may be configured for receiving incoming packets. [0058]
In one embodiment, the switch engine 25 processes received packets at the one or more ingress ports to be directed to one of the egress ports for outputting. In particular, the switch engine may be configured to identify the packet flow to which each received packet belongs, and to direct the received packet to an egress port allocated to the packet flow identifier. [0059]
In one embodiment, different packet flows (e.g. packet flows having different identifiers) may be received on respective ingress ports, and may be
17

WO 2016/158541 PCT7JP2016/058881
multiplexed by the multiplexing engine 26 so as to be outputted through the
same egress port.
[0060]
The traffic policing engine provides a traffic policing function 27 operating upon packet reception as described below. The traffic shaping engine 28 provides a traffic shaping function operating on packet transmission as described below. In embodiments of the present subject disclosure, the traffic policing function and the traffic shaping function operate in a coordinated manner in that the traffic shaping function uses theoretical reception time values of packets stored in memory 23 for transmission that are determined by the traffic policing function. [0061]
The time reference engine 29 may provide a time reference for the various processing operated by the traffic policing engine 27 and/or the traffic shaping engine 28. This advantageously allows, in one or more embodiments, to use a same time reference for the traffic policing and the traffic shaping performed in the network node 20. For example, the network node 20 may be configured so that all the links and ports 22a-d of the node use the same time reference. The time reference engine may in some embodiments implement a time counter, incremented per time units, depending on the implementation, and coupled to a reference clock device (e.g. a quartz device), whose value is used as a current time value by the traffic policing engine 27 and/or the traffic shaping engine 28. In some embodiments, a time counter value T may be incremented by one or several time units, depending on the implementation, every bit transmission time, the bit transmission time corresponding to the time duration of one bit given a binary transmission rate supported by the network node 20. For example, the bit transmission time corresponding to a 100 Mbps Ethernet link would be equal to 10 ns. [0062]
18

WO 2016/158541 PCT7JP2016/058881
The control engine 21 includes a processor, which may be any suitable microprocessor, microcontroller, Field Programmable Gate Arrays (FPGA), Application Specific Integrated Circuits (ASIC), Digital Signal Processing chip, and/or state machine, or a combination thereof. According to various embodiments, one or more of the computers can be configured as a multi-processor computer having multiple processors for providing parallel computing. The control engine 21 may also comprise, or may be in communication with, computer storage media, such as, without limitation, the memory 23, capable of storing computer program instructions or software code that, when executed by the processor, cause the processor to perform the elements described herein. In addition, the memory 23 may be any type of data storage computer storage medium coupled to the control engine 21 and operable with the one or more ports 22a-d to facilitate management of data packets stored in association therewith. [0063]
It will be appreciated that the network node 20 shown and described with reference to Fig. 2 is provided by way of example only. Numerous other architectures, operating environments, and configurations are possible. Other embodiments of the node may include fewer or greater number of components, and may incorporate some or all of the functionality described with respect to the network node components shown in Fig. 2. Accordingly, although the control engine 21, switch engine 25, multiplexing engine 26, traffic policing engine 27, traffic shaping engine 28, plurality of ports 22a-d, time reference engine 29, and memory 23 are illustrated as part of the network node 20, no restrictions are placed on the location and control of components 21-29. In particular, in other embodiments, components 21-28 may be part of different entities or computing systems. [0064]
19