Abstract:
There is provided a method of traffic management in a communication network, such as a Metro Ethernet network, in which communication resources are shared among different virtual connections each carrying data flows relevant to one or more virtual networks and made up of data units comprising a tag with an identifier of the virtual network the flow refers to and of a class of service allotted to the flow, and in which, in case of a congestion at a receiving node, a pause message is sent back to the transmitting node for temporary stopping transmission. For a selective stopping at the level of virtual connection and possibly of class of service, the virtual network identifier and possibly also the class-of-service identifier are introduced in the pause message.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims priority to the European application No. 04425794.7, filed Oct. 25, 2004 and which is incorporated by reference herein in its entirety.  
       FIELD OF THE INVENTION  
       [0002]     The present invention refers to computer communication systems, and more particularly it concerns a method of traffic management in a computer communication network and a network node implementing the method, as well as a network including said node.  
         [0003]     Preferably, but not exclusively, the invention applies in networks based on Ethernet specifications, in particular to bandwidth profile management at the ingress User Network Interface (UNI) of a Metro Ethernet Network.  
       SUMMARY OF THE INVENTION  
       [0004]     Ethernet is a widely used communication medium allowing communication through different interfaces and at various rates, up to the Gbit/s. Thousands of subscribers already use Ethernet services and their number is growing rapidly. Such subscribers are attracted by the benefits of the Ethernet services, including:  
         [0005]     ease of use  
         [0006]     cost effectiveness  
         [0007]     flexibility.  
         [0008]     At present metropolitan area networks based on Ethernet (Metro Ethernet networks) are being defined by the Metro Ethernet Forum (MEF). A Metro Ethernet network is substantially a publicly accessible metropolitan area network controlled by a single administrator, for instance an Internet Service Provider.  
         [0009]     An important feature of Metro Ethernet networks, of particular interest for the invention, is that they can be shared among different customer networks, each of them being unaware of the use of the Metro network by the other ones. Each of such networks is called Virtual Local Area Network (VLAN).  
         [0010]     A model for defining the services offered by a Metro Ethernet network is disclosed in Technical Specification MEF 1.0 “Ethernet Service Model, Phase 1”, published by the Metro Ethernet Forum on 10 Nov. 2003. The Metro Ethernet network administrator (the “provider”) offers the customers services differentiated according to some performance level (Class of Service, in short CoS), for instance related to frame loss and frame delay. The performance levels agreed between the provider and a customer are defined in the so-called Service Level Agreement (SLA) and Service Level Specifications (SLS). Assuring such a performance level implies use of traffic management mechanisms at the nodes (usually referred to as “switches” or “routers”) of the network.  
         [0011]     At the User Network Interface (UNI), which is defined as the demarcation point between the responsibilities of the Service Provider and of a customer, traffic management functions are based, inter alia, on the so-called Bandwidth Profile, which is a set of traffic parameters that governs the expected arrival pattern of customer traffic.  
         [0012]     Further information on the bandwidth profile can be found for instance in the above-mentioned Technical Specification of MEF and in a further MEF document (document D00029, “Traffic Management Specification, Phase I, Draft v.7.0”, published on 1 Mar. 2003).  
         [0013]     As disclosed in such documents, there are three ways in which a bandwidth profile can be applied at the ingress into the Metro Ethernet network:  
         [0014]     per Ingress UNI,  
         [0015]     per EVC (Ethernet Virtual Connection, that is the association of two or more UNIs that limits the exchange of service frames to UNIs belonging to the EVC itself), and  
         [0016]     per EVC and CE-VLAN CoS (CE stands for Customer Edge, which is the equipment on the subscriber side of a UNI); The Ingress bandwidth profile per ingress UNI applies to all ingress service frames at the UNI, without taking into account the EVCs the frames belong to. The Ingress bandwidth profile per EVC provides a bandwidth profile that applies to all service frames for a given EVC. The Ingress bandwidth profile per EVC and CE-VLAN CoS provides a bandwidth profile that applies to all service frames having a specific CoS in a given EVC. The bandwidth profile should be enforced by the provider&#39;s network since it is part of the SLS/SLA. When a violation of the profile occurs, for instance due to short-term transient overload conditions, the service provider has to take specific actions.  
         [0017]     According to the above mentioned document D00029 of MEF, a level of compliance of the service frames to the bandwidth profile may be identified by means of three different colours, and the actions may be recolouring or dropping frames. An alternative action that may be taken is exerting a backpressure on the upstream equipment by sending a PAUSE frame in order to limit the traffic coming from the customer(s) through a temporary suspension of the transmission. Use of pause frames is disclosed in IEEE Standard 802.3. The pause function (i.e. near flow control) is designed to prevent switches from unnecessarily discarding frames due to input buffer overflow under short-term transient overload conditions.  
         [0018]     However, the pause mechanism as defined in the standard has the drawback that it can only be applied to all frames at the UNI. Taking into account that Ethernet flows from different VLANs and with different Classes of Service are multiplexed on the UNI, this mechanism entails that also flows from VLANs and/or with Classes of Service that do not contribute to the overflow are stopped and unnecessarily delayed. Thus the need arises of a selective management of the pause mechanism. A proposal to this end is disclosed in U.S. Patent Application 2004095882. That document discloses a mechanism operating at the provider network level. A receiving node reads the identifiers of the ingress and egress nodes from a frame causing congestion and includes the addresses of the ingress and egress nodes in the pause frame. At a transmitting node, upon reception of the pause message, only frames having the ingress and egress node addresses specified in the pause frame are temporarily stopped. The selectivity provided by the prior art is not yet satisfactory.  
         [0019]     There is provided a method of traffic management in a communication network, in which communication resources are shared among different virtual connections each carrying data flows from one or more virtual networks, and in which data units in each flow comprise a tag including an identifier of the virtual network the flow refers to and an identifier of a service level required by the flow. At a receiving node of the network, said data flows are temporary stored and, upon detection of a congestion, a pause message is sent to a transmitting node for temporarily stopping data transmission; According to the invention, the method is characterised by the steps of:  
         [0020]     reading said tags at said receiving node;  
         [0021]     introducing into the pause message the virtual network identifier associated to at least one virtual network having given service level characteristics, e.g. the virtual network whose flows have the lowest priority;  
         [0022]     reading, at said transmitting node, the virtual network identifier from said pause message; and  
         [0023]     selectively stopping transmission of flows belonging to the virtual network identified in the pause message.  
         [0024]     The invention further concerns a node having a controller implementing the method and a network including said nodes. Preferably, the network is a Metro Ethernet Network, and the traffic management is performed at the ingress UNI interface. If the traffic management provides for applying an ingress bandwidth profile per virtual connection or per class of service, the selective stopping of transmission based on the tag included in the pause frame concerns one or more specific virtual connections or one or more specific classes of service. A more selective management of the pause mechanism than disclosed in the prior art is thus obtained.  
         [0025]     Preferred embodiments of the invention, given by way of non-limiting example, will now be disclosed with reference to the accompanying drawings. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0026]      FIG. 1  shows a schematic representation of the scenario of application of the invention;  
         [0027]      FIGS. 2A, 2B ,  2 C show graphical representations of the different rules of ingress bandwidth profile application at the UNI in a Metro Ethernet network;  
         [0028]      FIG. 3  shows the structure of the conventional pause frame;  
         [0029]      FIGS. 4 and 5  show the structure of the pause frame according to two embodiments of the invention;  
         [0030]      FIGS. 6 and 7  show two examples of application of the invention; and  
         [0031]      FIGS. 8 and 9  show diagrams of principle of the generation of the pause frame at a receiving node and of its processing at a transmitting node.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0032]     The invention will be disclosed hereinbelow with reference to the preferred application at the level of the UNI at the ingress into a Metro Ethernet network. The relevant scenario is depicted in  FIG. 1 . The drawing shows a customer network CN in which a number of VLANs VL 1 , VL 2  . . . are implemented. The Ethernet flows from VLANs VL 1 , VL 2  . . . are multiplexed at customer edge CE onto UNI interface U. Interface U transfers the flows to Provider Edge PE at the ingress of Metro Ethernet Network MN, from which the Ethernet flows are then forwarded to the concerned nodal queues, two of which are shown at Q 1 , Q 2 .  
         [0033]     According to the Ethernet specifications, the frames of VLANs VL 1 , VL 2  . . . are mapped at CE into a number of EVCs across the UNI. The frames may contain a tag (VLAN tag) with information allowing identifying the VLAN a certain flow refers to. Different sets of frames of a same VLAN (e.g. sets of frames belonging to different services) may be allotted different classes of service and hence different priorities. A portion of the tag includes priority bits identifying the different classes of service.  
         [0034]     For sake of a better understanding of the description, the different manners of application of the bandwidth profile at PE are reproduced in  FIG. 2A  (Profile Per Ingress UNI),  FIG. 2B  (Profile Per EVC) and  FIG. 2C  (Profile Per EVC and CE-VLAN CoS). Those Figures are taken from the aforementioned document D00029 of MEF. The essential features of the three kinds of profile management have been set forth in the introduction of the specification and it is not necessary to go in further details, which can be found in said document D00029.  
         [0035]     Still for sake of better understanding of the description,  FIG. 3  reproduces the structure of the conventional pause frame. As shown, the frame is organised into a number of fields, namely: destination and source address fields F 1 , F 2  (6 bytes each); control fields (grouped together in F 3  in the drawing and comprising in the whole 6 bytes), characterising the frame as a control frame, in particular a pause frame, and specifying the pause duration; a frame check sequence field F 4  of 4 bytes. Since Ethernet frames have a standard minimum length of 64 bytes, a field F 5  of 40 bytes, reserved for future uses, remains between fields F 3 , F 4 .  
         [0036]     In the scenario depicted in  FIG. 1 , the traffic management based on the pause frame shown in  FIG. 3  corresponds to the bandwidth profile application shown in  FIG. 2A  (profile per ingress UNI). Hence its application would imply stopping the transmission from the whole customer network CN. Should a selective action be desired, it could be based only on frame recolouring or dropping.  
         [0037]     In order to selectively apply the near flow control mechanism based on the pause frame, according to the invention the frame message includes, as shown in  FIG. 4 , a further field F 6  intended to contain the VLAN tag (more specifically, the VLAN identifier). The VLAN tag (two bytes) can occupy as many bytes of the reserved field. It could be also possible to insert a list of VLAN tags instead of a single VLAN tag.  
         [0038]     In order the modified pause frame can be exploited, the downstream equipment (PE in  FIG. 1 ) shall include a controller that, while looking at the filling state of the various input buffers, is also capable of extracting from the received frames the VLAN tag and inserting into the pause frame. Similarly, the downstream equipment (CE in  FIG. 1 ) shall include a controller that is capable of extracting the VLAN tag from the received pause frame and to selectively act on the various VLANs.  
         [0039]     However, the proposed solution is compatible with switches implementing the current near flow control. Indeed any such switch, upon receiving a pause frame with a VLAN tag as shown in  FIG. 4  from a downstream switch, will simply neglect the content of field F 6 , since it is not equipped for interpreting such field, and will continue stopping all egress Ethernet frames.  
         [0040]     The same principles can be adopted for managing the bandwidth profile application scenario shown in  FIG. 2C . In this case the pause frame includes (as shown in  FIG. 5 ) a further field F 7 , intended to contain the priority bits of the VLAN tag. Also field F 7  occupies a corresponding portion of the reserved field.  
         [0041]     Also in this case, a list of VLANs/Priorities could be introduced. Moreover, when field F 7  is used, field F 6  could even take a particular value meaning “ALL VLANs”: in such case the flow is identified only by the priority.  
         [0042]     Some examples of use of the invention are now described with reference to  FIGS. 8 and 7 . In the description of such examples, a comparison with the standard traffic management policy is made.  
         [0043]     In the example of  FIG. 6 , three switches or routers S 1 , S 2  and S 3  generate respective Ethernet flows and send them to a further switch S 4 . The Ethernet flows are shown by double line arrows in the drawing. The flows can be either untagged flows or flows already tagged with a VLAN tag. In the latter case, we assume that the flows from S 1 , S 2 , S 3  are tagged with VLAN tags “A”, “B” and “C”, respectively. If any of such flows is untagged, the proper tag A, B or C will be added by switch S 4 . The tagged flows are multiplexed by switch S 4  on a same transmission medium and forwarded to switch S 5 , which performs the policing on the flows in ingress. The flows are distinguished by VLAN tag. Therefore, in this example, switch S 5  is receiving three different flows. It is supposed that each flow has to be managed in different way: for instance the flow coming from switch S 1  has higher priority than the flow coming from S 2 , and the latter has higher priority than the flow coming from S 3 .  
         [0044]     Supposing that switch S 5  detects a congestion, two possible actions can be implemented with the current standard function:  
         [0045]     to discard the Ethernet frame coming from switch S 4  taking the priority defined by the SLA into account; or  
         [0046]     to send the pause frame towards switch S 4 ; thus stopping all Ethernet flows without taking the priority into account.  
         [0047]     By using the invention, the Ethernet flow with the lowest priority (identified by a given VLAN tag, here tag “C”) can be stopped (without being dropped), without affecting the Ethernet flows with higher priorities.  
         [0048]     Therefore, in case of congestion, the following actions have to be carried out:  
         [0049]     switch S 5  sends back the pause frame with VLAN tag “C” in field F 6  to switch S 4 ;  
         [0050]     switch S 4  sends back the pause frame to switch S 3  in order to stop the frame transmission.  
         [0051]     The pause frames are explicitly indicated in the drawing and are shown by single-line arrows.  
         [0052]     In the example shown in  FIG. 7 , a workstation S 6  sends tagged frames to switch S 7 . It is supposed that switch S 7  manages three different Classes of Service (e.g. three different service models):  
         [0053]     Expedited Forwarding (EF) for real time applications like VoIP (Voice over IP) or Video;  
         [0054]     Assured Forwarding (AF) for services with committed bandwidth; and  
         [0055]     Best Effort (BE) for using the available bandwidth.  
         [0056]     The VLAN priority inside the Ethernet frames identifies the Class of Service a given Ethernet frame belongs to. Supposing that switch S 7  detects congestion, two possible actions can be implemented with the current standard traffic policing:  
         [0057]     to discard the Ethernet frames coming from workstation S 6  taking the Class of Service priority into account;  
         [0058]     to send the pause toward workstation S 6 , thereby stopping all Ethernet flows, without taking the priority into account (in this case the real time application cannot be guaranteed).  
         [0059]     By using the invention, the Ethernet flow with the lowest priority (in the present example, the Best Effort traffic) can be stopped (without being dropped), without affecting the Ethernet flows with higher priorities (e.g. VoIP). Therefore, in case of congestion, switch S 7  has to send back the pause frame with the appropriate VLAN priority identifier to workstation S 6  in order to stop such a lowest priority Ethernet flow.  
         [0060]     Another possible situation is when an Ethernet bandwidth associated with one CoS exceeds the bandwidth stated in the SLA. Two possible actions can be implemented with the current standard function:  
         [0061]     to discard the Ethernet frames which exceed the bandwidth stated in the SLA, or  
         [0062]     to carry the Ethernet frames and, in case of congestion, to discard the frames which exceed the assigned bandwidth.  
         [0063]     Again, like in the case of congestion, the invention allows stopping the flow that exceeds the bandwidth stated in the SLA without frame loss.  
         [0064]     In a variant of the first application example, the VLAN priority could be used for distinguishing among different Ethernet flows and, in a variant of the second application, the VLAN tag could be used for distinguishing among different Service Classes of service.  
         [0065]      FIG. 8  shows a block diagram of the operating principles of the receiving side portion CR of the controller in a node. An input buffer IB in the node receives a plurality of Ethernet flows FLOW 1  . . . FLOWn belonging to different VLANs or having different CoS. In conventional manner, buffer IB could be virtually subdivided into different sections, each associated with one of the flows. Tags TAG 1  . . . TAGn of flows FLOW 1  . . . FLOWn are taken from the flows and stored in respective registers R 1  . . . . Rn. A congestion detector DE recognises the occurrence of a congestion in one or more buffer sections and signals the congestion to a selection logic SE. Upon occurrence of the congestion, selection logic SE selects, based on certain criteria, the tag(s) associated with one or more flows and sends it (them) to pause message generator PG, for insertion into the proper field of the pause frame. The criterion for tag selection could be related for instance to the priority allotted to the data flows, as disclosed in the above examples. The term “Tag” here can be the only VLAN identifier (see  FIG. 4 ) or can include both the VLAN and the priority identifiers ( FIG. 5 ). The flows outputting from buffer  1 B have not been indicated since they are not of interest for the understanding of the pause generation.  
         [0066]      FIG. 9  shows a block diagram of the operating principles of the transmitting side portion CT of the controller in a node arranged to handle the pause frames according to the invention. A pause receiver PR receives the pause frame with the tag(s) and extracts the tag(s) and the information about the suspension time. A tag decoder TD decodes the extracted tag(s) and consequently generates commands STOP 1  . . . STOPm for temporarily stopping transmission of the concerned flow(s) FLOW 1  . . . FLOWm by output buffer OB.  
         [0067]     In summary, the invention allows managing different traffic profiles (e.g. VoIP, Best Effort, . . . ) without framing loss, assuring the negotiated latency. Besides, the UNI interface can carry the traffic of several clients that are distinguished by VLAN tag. Based on SLS (SLA), a switch can manage the traffic of the different clients in different ways: for instance in case of over-subscription it is possible to stop some client Ethernet traffic and to carry some other traffic without frame losses. It is evident that the above description has been given only by way of non-limiting example and that changes and modifications are possible without departing from the scope of the invention. So, even if the invention has been described with particular reference to the traffic management at the ingress into the Metro Ethernet Network, the same idea can be applied in any node of a network where a resource is shared among different VLANs identified by respective tags and/or managing services requiring different service levels, e.g. different priorities, identified by respective priority identifiers and where a receiving node can exert a backpressure on a transmitting node through a pause message.