Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L43/00—Arrangements for monitoring or testing data switching networks
  • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
  • H04L43/0823—Errors, e.g. transmission errors
  • H04L43/0829—Packet loss
  • H04L43/0835—One way packet loss
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/34—Signalling channels for network management communication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports

Definitions

• the present invention relates to loss measurement for data delivery in multicast transmissions.
• the invention relates to an exact loss measurement for Ethernet multicast connections.
• Ethernet services are increasingly widely deployed, especially in metro networks.
• the Metro Ethernet Forum defines the basic Ethernet services to be supported by an Ethernet network, such as E-Line, E-Tree and E-LAN (MEF 6.1 : "Metro Ethernet Services Definitions Phase 2" (April 2008)).
• E-Line is a point-to-point service
• E-Tree is essentially a point-to-multipoint service
• E-LAN is a multipoint-to-multipoint service.
• E-Tree can be implemented by establishing a multicast transmission, and embedding users' data frames corresponding to a service ("service frames") in multicast frames in a metro region.
• service frames service
• E-LAN might be implemented as a set of multicast trees. Operators of networks need to take measurements in order to monitor the performance of those networks.
• OAM Operation Administration Maintenance
• Service parameter measurement is a key issue both for operators and their subscribers, in order to verify their agreements and to check whether the requirements for specific services are met.
• Frame loss measurement methods are also defined in the same document. However, accurate frame loss measurement methods are not yet defined for multicast services, though the corresponding parameters have been recently defined in ITU-T Rec. Y.1563 (01/2009): “Ethernet frame transfer and availability performance”.
• Provider and customer networks are typically separated by full header encapsulation at the edge of the provider network.
• FIG 1 is a schematic illustration of a provider network 101 , which uses this approach.
• the provider network 101 is bordered by Backbone Edge Bridges (BEB) 102, 103, 104, 105, 106, 107, and includes Backbone Core Bridges (BCB) 108, 109, 1 10 inside the network.
• BEB Backbone Edge Bridges
• BCB Backbone Core Bridges
• Measurements are invoked by Maintenance End Points (MEP), which reside in edge nodes of the network.
• MEPs exchange OAM frames for the measurement of service parameters.
• Intermediate nodes such as BCBs 108, 109, 1 10 may include Maintenance Intermediate Points (MIP).
• MIP Maintenance Intermediate Points
• Point-to-multipoint services can be efficiently implemented in Ethernet networks by the usage of multicast frames. In a basic Ethernet network where there is no support for multicast frame forwarding, all multicast frames are sent to all bridges in the network, as the proper forwarding is not set for the multicast destination addresses. This operation is illustrated in Figure 2, which shows the network 101 of Figure 1 .
• BEB1 102 is a source node of a multicast service; BEB2 103 and BEB3 104 are the recipients registered for the service.
• every node receives the frames 201 corresponding to the multicast service if no protocol for multicast support is running in the network.
• This means that the service frames are received by the registered nodes BEB2 103 and BEB3 104, but also by the unregistered end nodes such as BEB4 105, BEB5 106 and BEB6 107.
• the unregistered end nodes BEB4 105, BEB5 106 and BEB6 107 therefore need to drop the frames they are not registered to receive.
• the diagram is illustrative only, and there may be more than one subscription simultaneously active per destination. There may also be more than one source for any given multicast destination address.
• MMRP Multiple Registration Protocol
• IGMP Internet Group Management Protocol
• multicast frames are forwarded as illustrated in Figure 3: the frames 301 corresponding to the service whose source is BEB1 102 are only forwarded to BEB2 103 and BEB3 104, which are the registered recipients for that service.
• Any method that is applied for accurate loss measurement corresponding to a multicast service will depend on the forwarding scheme applied in the network, i.e. whether or not MMRP (or IGMP snooping) is applied.
• the document MEF 6.1 referred to above describes the measurement of the loss of synthetic OAM frames, but not the loss of service frames.
• synthetic loss measurement the real loss of service frames can only be estimated: precise measurement is not possible.
• OAM frames used for measurement typically contain counters containing a value obtained from corresponding counters maintained in the network nodes. For example, a "sent frames" counter maintained in the source node is read out and copied into the loss measurement OAM frame.
• the OAM frame thus carries a record of the number of service frames sent by the source node for a particular service.
• the receiving node receives the OAM frame, it compares the counter with the number of service frames actually received. The difference between the two numbers should provide a measurement of the number of lost frames.
• OAM destination addresses defined in ITU-T Rec. Y.1731 are not the same as the service multicast address. This means that there is a chance of reordering or that the service and OAM frames are forwarded on a different path. As a result of this, service frames sent after the counter readout may arrive before the loss measurement OAM frame containing the counter value, or service frames sent before the counter readout may arrive before the loss measurement OAM frame. This causes inaccuracy in the loss measurement. Furthermore, unless IGMP snooping, MMRP or a similar method is used as shown in Figure 3, multicast service frames are transmitted to all bridges in the network, regardless of whether the bridge is subscribed for the service, as illustrated in Figure 2. Both cases raise issues.
• IGMP snooping or MMRP is not used, then all multicast frames reach all nodes. If a receiving node subscribes to the multicast service during a measurement period, the counter in the first loss measurement OAM frame received by the receiving node will account for some service frames sent before the receiving node subscribed to the service. These service frames will never be received by the receiving node and the first measurement after subscription will inevitably be inaccurate.
• MMRP and IGMP snooping set the forwarding in intermediate nodes according to the subscription to a multicast service, and thus eliminate the forwarding of multicast service frames to unsubscribed nodes. They manipulate the forwarding for the service multicast destination address but do not contain any explicit information on the subscribed nodes.
• the loss measurement OAM frames may still reach an unsubscribed node if the service and OAM destination addresses are different. In such a situation the loss measurement is very inaccurate at an unsubscribed node: the OAM frames contain the "sent frames" counter of the source, which includes all multicast frames sent out by the source for a particular service, and has the same value irrespective of the subscription by receiving nodes. If the receiving node is not subscribed it will never receive any of the corresponding service frames, and this results in a huge false loss value in the measurements.
• the filtering of service frames but not OAM frames due to MMRP or IGMP results in a continuous false positive loss when a receiving node is not subscribed.
• the first loss measurement immediately after subscription will also be inaccurate in just the same way as if MMRP or IGMP snooping is not deployed.
• loss and delay measurement frames defined in ITU-T Rec. Y.1731 do not include an additional reference to the relationship for which the measurement is made. This is not a problem for point to point transmissions. However, it is a problem for multicast systems, where address measurements for each multicast are desired.
• the loss and delay measurement reply frames defined in ITU-T Rec. Y.1731 are addressed to the unicast address of the root (source node), and are therefore able to measure leaf to root (destination to source) unicast point-to-point performance. They also contain information for the root about the root to leaf direction, which could be a point-to- multipoint multicast relation without extensions. Therefore multicast measurement reply frames containing unicast backward measurement information may result in confusion or contain redundant information compared to bidirectional unicast measurements.
• This invention proposes alternative solutions for exact loss measurement for Ethernet multicast transmissions depending on the forwarding approach used in the Ethernet network.
• a method of measuring loss in a multicast transmission in a network Service frames including a service multicast destination address are sent from a source node towards a receiving node. A counter of the number of service frames sent is maintained at the source node. This counter is periodically read, and its value copied into a loss measurement OAM frame.
• the loss measurement OAM frame includes a unique identifier and an OAM destination address which is different to the service multicast destination address, and is sent from the source node towards the receiving node. Every time the sent frames counter is read, a measurement indicator frame is also sent from the source node towards the receiving node.
• the measurement indicator frame includes the unique identifier so that it can be related to the loss measurement OAM frame.
• the measurement indicator frame also includes the service multicast destination address, although the measurement indicator frame is distinguishable from the service frames.
• the receiving node eventually receives the loss measurement OAM frame and the measurement indicator frame, and calculates the number of lost or delayed service frames by comparing the number of service frames received at the receiving node at the time the measurement indicator frame is received with the sent frames counter value contained in the loss measurement OAM frame. The calculation is only performed when the loss measurement OAM frame and measurement indicator frame having the same identifier have been received by the receiving node.
• a measurement indicator frame is inserted into the service frame flow whenever an OAM message is sent.
• the measurement indicator frame may provide an indication of the service frames between which it was sent.
• the measurement indicator frame may be distinguishable from the service frames by being a different type of frame. For example, it could be an OAM Ethertype, or may have a new OAM message type.
• the identifier may be a globally unique identifier.
• the identifier may be locally unique to a particular multicast service, in which case a multicast service address for the particular multicast service may be included in the loss measurement OAM message.
• Service frames including a service multicast destination address are sent from a source node towards a receiving node.
• a counter of the number of service frames sent is maintained at the source node. This counter is periodically read, and its value copied into a loss measurement OAM frame.
• the loss measurement OAM frame (which includes the service multicast destination address) is sent from the source node towards the receiving node and received at the receiving node.
• the number of lost or delayed service frames is calculated by comparing the number of service frames received at the receiving node with the counter value contained in the loss measurement OAM frame.
• the service multicast address is used as the destination address of the OAM frames.
• the calculation of the number of lost or delayed frames at the receiving node after receipt of the first loss measurement OAM frame after the receiving node subscribes to the multicast transmission may be suppressed.
• This suppression helps to eliminate the inaccuracy introduced by dynamic changes to the multicast forwarding topology through use of control protocols, such as MMRP and IGMP snooping.
• the suppression may be achieved by the receiving node maintaining a received frames counter for recording the number of service frames received, and increasing said received frames counter to the counter value in the first loss measurement OAM frame received after subscription to the multicast service.
• the receiving node may also maintain a correction counter.
• the correction counter may be updated based on the counter value in the first loss measurement OAM frame received after subscription to the multicast service, and added to the received frame counter when the loss is calculated.
• the loss may be reset to zero for the period in which the receiving node was not subscribed to the multicast transmission.
• the receiving node may explicitly inform the source node when it subscribes to the multicast transmission, for example by extending the IGMP or MMRP protocol, or by an explicit unicast notification message.
• a unicast loss reply message may be sent from the receiving node towards the source node.
• the unicast loss reply message may contain the results of the loss calculation but not counters to measure loss for packets travelling from the receiving node to the source node.
• the network may be an Ethernet network.
• the bridge node for use in a network.
• the bridge node comprises a receiver for receiving multicast service frames, measurement indicator frames and loss measurement OAM frames from a source node in the network.
• the multicast service frames have a service multicast destination address.
• the measurement indicator frames also have the service multicast destination address, and the loss measurement OAM frames have an OAM destination address different to the service multicast destination address.
• a processor is operatively connected to the receiver for performing loss measurements.
• a memory is operatively connected to the processor for storing a received frames counter. The processor is arranged to count the number of received service frames and record this using the received frames counter.
• the processor When a loss measurement OAM frame is received, the processor recovers a sent frames counter value from the loss measurement OAM frame.
• the sent frames counter indicates the number of frames sent by the source node.
• the processor calculates a number of lost or delayed service frames by comparing the received frames counter value with the sent frames counter value.
• a bridge node for use in a network.
• the bridge node comprises a receiver for receiving service frames and loss measurement OAM frames from a source node in the network in the same data flow.
• a processor is operatively connected to the receiver for performing loss measurements.
• a memory is operatively connected to the processor for storing a received frames counter.
• the processor is arranged to count the number of received service frames and record this using the received frames counter.
• the processor recovers a sent frames counter value from the loss measurement OAM frame, and calculates the number of lost or delayed service frames by comparing the received frames counter value with the sent frames counter value.
• the bridge node may also comprise a transmitter operatively connected to the processor for sending a unicast loss reply message towards the source node, the unicast loss reply message containing the results of the loss calculation but not counters to measure loss for packets travelling from the receiving node to the source node.
• a bridge node for use in a network.
• the bridge node comprises a processor.
• a memory is operatively connected to the processor for storing a sent frames counter.
• a transmitter is operatively connected to the processor for sending multicast service frames towards a receiving node in the network, the service frames including a service multicast destination address.
• the processor is arranged to record the number of service frames sent using the sent frames counter.
• the processor periodically reads the sent frames counter from the memory, generates a loss measurement OAM frame having an OAM destination address different to the service multicast destination address and a unique identifier, and copies the sent frames counter into the loss measurement OAM frame.
• the processor also generates a measurement indicator frame having the service multicast destination address and the unique identifier.
• the transmitter is arranged to send the loss measurement OAM frame and measurement indicator frame towards the receiving node.
• a bridge node for use in a network.
• the bridge node comprises a processor for performing loss measurements.
• a memory operatively connected to the processor for storing a sent frames counter;
• a transmitter for sending multicast service frames towards a receiving node in the network, the service frames including a service multicast destination address;
• processor is arranged:
• the transmitter is arranged to send the loss measurement OAM frame towards the receiving node.
• Figure 1 is a schematic illustration of a provider network
• Figure 2 is a schematic illustration of the provider network of Figure 1 in which multicast frames are sent to all bridge nodes;
• Figure 3 is a schematic illustration of the provider network of Figure 1 in which multicast frames are only directed towards addresses registered to the multicast service;
• Figure 4 is a schematic illustration of a provider network with measurement indicator frames inserted into the service frame flow
• Figure 5 is a schematic illustration of a provider network with loss measurement OAM frames inserted into the service frame flow
• Figure 6 is a flowchart indicating the actions taken by a source node in sending out loss measurement frames
• Figure 7 is a state diagram illustrating the operation of a receiving node.
• Figure 8 is a schematic illustration of a bridge node.
• Measurement is typically carried out using OAM frames, and this approach has the advantage that users' service frames need not be modified for measurement purposes.
• Measurement Indicator frame In order to ensure that OAM frames are used correctly by a receiving nodes, and to solve the problem of measurement inaccuracy caused by the different destination address of the service and OAM frames, a new frame, hereinafter called a "Measurement Indicator frame", may be inserted into the flow of service frames corresponding to a multicast service.
• the usage of Measurement Indicator frames is illustrated in Figure 4.
• Figure 4 is a schematic illustration of a network 401 , similar to the network 101 shown in Figures 1 , 2 and 3, which includes Maintenance End Points (MEPs) 402, 403 at the edges of the network.
• Service frames 404 corresponding to a multicast service are sent from a source MEP 402 towards a receiving MEP 403.
• OAM frames 405, 406 are periodically issued by the source MEP 403, and may be forwarded in a different path from the service frames.
• Measurement Indicator frames 407, 408 are inserted into the flow of service frames.
• a Measurement Indicator frame 407, 408 is sent every time the counter at the source MEP 403 is read out and its value copied to the OAM frame 405 that is about to issue for loss measurement.
• the operation of the source MEP 402 is shown in a flow-chart in
• the Measurement Indicator frame shows the two service frames between which the counter was read out.
• One way of achieving this is for the Measurement Indicator frame 407, 408 to contain the sequence number of the service frames either side.
• the destination address of the Measurement Indicator frame 407, 408 is the same as the multicast service address, but the indicator frame has an OAM EtherType.
• Measurement Indicator frame is distinguishable from service frames despite having the same destination address as the service frames and being forwarded on the same path.
• Each Measurement Indicator frame 407, 408 also contains a unique identifier, which is also carried in the corresponding measurement OAM frame 405, 406. Thus, a one-to- one association is established between each OAM frame 405, 406 and its corresponding Measurement Indicator frame 407, 408 which shows the time instance of the measurement counter read-out. For the receiving MEP 403, the evaluation of the OAM frame 405 becomes unambiguous because it should be evaluated only when the corresponding Measurement Indicator frame 407 has also been received. This ensures that the measurement is exact.
• Figure 7 is a state diagram illustrating the operation of the receiving MEP 403.
• S72 Every time a loss measurement OAM frame 405, 406 is received, a check is made to see if a corresponding measurement indicator frame 407, 408 has been received.
• S73 Every time a corresponding measurement indicator frame 407, 408 is received, a check is made to see if a corresponding loss measurement OAM frame 405, 406 has been received.
• the unique identifier which confirms the association between loss measurement OAM and measurement indicator frames may be a globally unique identifier, or may be locally unique for each multicast service. In the second case the multicast service address is also sent together with the identifier in the loss measurement OAM message.
• the application of multicast frame forwarding optimization methods such as MMRP and IGMP snooping introduces inaccuracy to the loss measurement if the OAM frames and the service frames have different destination addresses. This inaccuracy can be avoided by "suppressing" these false loss measurements when the node is not subscribed to the specific multicast address.
• the source MEP 402 periodically sends OAM frames 405, 406 for loss measurement to the dedicated OAM destination address. These OAM frames are received by all nodes (both subscribed and unsubscribed) because MMRP and IGMP snooping only control the forwarding of service frames. When a node receives OAM frames relating to a multicast service to which the node is not subscribed, the loss measurement is simply not carried out.
• MMRP or IGMP snooping also raises another issue, as discussed above.
• the first loss measurement will refer partially to an unsubscribed and partially to a subscribed period. Thus, the loss measurement becomes incorrect.
• further counter manipulation is required in order to suppress this first loss measurement. It is desirable to modify existing calculation processes as little as possible, since they are usually already implemented.
• a "received frames" counter at the receiving node 403 is modified to show that all service frames have been received when the first OAM message is received after subscription is started. Therefore, the "received frames” counter value of the receiving node 403 is increased to the value of the counter in the received frame loss measurement OAM message.
• a separate correction counter in the receiving MEP 403 is used. The correction counter is updated based on the counter in the first frame loss measurement OAM message received once subscription has started. The value of the correction counter is added to the received frames when the loss is calculated. In another approach, no correction of the counters is required. Instead, when (or after) calculating the loss, the result is changed to a zero loss for the unsubscribed period.
• an alternative approach to solving the problems introduced by the use of MMRP or IGMP snooping involves informing the source MEP 402 about the membership status of the receiving MEP 403.
• the source MEP 402 is informed about the membership of the multicast group. This way the source MEP 402 always has an up-to-date list of the receiving nodes (e.g. MEP 403) actually subscribed to a specific multicast address to which the source node sends frames. This implies that a separate counter has to be maintained in the source MEP 402 and in the OAM frames for every destination / multicast address combination.
• Option 1 Extending existing protocols, like IGMP or MMRP, to be able to convey multicast group membership information to the source node 402. This is not the planned behaviour of these protocols but such a solution could be implemented.
• Option 2 Explicit membership notification from the receiving node.
• the receiving MEP 403 sends a unicast frame, containing its membership information, to the source MEP 402, immediately after receiving the first multicast service frame 404.
• the receiving MEP 402, having recently subscribed to the service, is able to determine the address to which the explicit notification is to be sent because it is the source address field of the received multicast service frame.
• informing the source MEP of membership status could in some cases be carried out by the node performing the multicast frame filtering (e.g. IGMP snooping).
• FIG. 5 illustrates the operation of such an approach.
• Figure 5 is a schematic illustration of a network 501 , similar to the network 401 shown in Figure 4, which includes Maintenance End Points (MEPs) 502, 503 at the edges of the network.
• Service frames 404 corresponding to a multicast service are sent from a source MEP 502 towards a receiving MEP 503.
• OAM frames 505, 506 are periodically issued by the source MEP 503, and are forwarded on the same path as the service frames 404.
• the OAM frames 505, 506 have the same address as the service frames 404 then they have to be filtered from the service frames 404 by some other means. Such filtering might be based, for example, on EtherType and MEG level. The first loss measurement result immediately after subscription will also still need to be suppressed in this case as well.
• LMM and LMR OAM messages are used for point to point loss measurement.
• these OAM messages 405, 406 will need to include an identifier to ensure that they are linked to their corresponding measurement indicator messages. This can be achieved by the introduction of a new OAM message, the Multicast Loss Measurement Message (MLMM) and optionally the Multicast Loss Measurement Reply (MLMR), for the multicast loss measurement.
• MLMM Multicast Loss Measurement Message
• MLMR Multicast Loss Measurement Reply
• the existing Y.1731 LMM and LMR messages could be extended to include the identifier.
• the identifiers may be globally unique, or locally unique. If they are locally unique the multicast service address has to be sent together with the identifier in the loss measurement OAM message 405, 406.
• the Loss Measurement Reply OAM message defined in ITU-T Y.1731 includes the counters needed for leaf to root loss measurement. In the multicast case there is no need to include the unicast loss counters to the loss measurement reply.
• the reply to the multicast loss measurement OAM message can therefore be made optional. If it is used, the multicast loss measurement reply message need only contain the counters for the root to leaf direction.
• FIG 8 is a schematic illustration of a bridge node 801 that implements the method described above.
• the bridge node 801 has a memory 802 to store the measurement counters.
• a processor 803 is provided for the implementation of MEP functions and the described measurement methods.
• a receiver 804 is provided for receiving service and OAM frames, which instruct the bridge node to invoke certain parts of the measurement method if the bridge node is a destination of the multicast transmission.
• a transmitter 805 is provided for issuing service and OAM frames to further bridge nodes if the bridge node is a destination of the multicast transmission.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Environmental & Geological Engineering (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (4)

Applications Claiming Priority (1)

Publications (1)

Family

ID=41719113

Family Applications (1)

Country Status (4)

Cited By (2)

Families Citing this family (3)

Citations (2)

Family Cites Families (4)

• 2009
  • 2009-07-10 IN IN315DEN2012 patent/IN2012DN00315A/en unknown
  • 2009-07-10 US US13/383,301 patent/US8879401B2/en active Active
  • 2009-07-10 WO PCT/EP2009/058878 patent/WO2011003478A1/en not_active Ceased
  • 2009-07-10 EP EP09780477.7A patent/EP2452464B1/en not_active Not-in-force

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events