4

Assumption for flow:

  • Ethernet connection between two nodes through switches/bridges only

  • Either of:

    • No VLAN (802.1Q) header
    • VLAN having same ID and priority (same PCP, DEI, and VID)

May frame reordering (misordering) then occur, or is it safe to assume that frames for the flow are received in same order as transmitted?

Background for question: I am implementing a hardware module that handles Ethernet frames at L2 level, and I consider whether I can safely assume that frames are not reordered when going from the source to destination through switches/bridges. The network is assumed to be a star topology, thus without loops, so based on this I assume that the comment in "K.3 Frame misordering" below does not apply, since there is no possibility for change of topology through e.g. STP/RSTP.

Standard information: From "802.1D-2004 Media Access Control (MAC) Bridges":

6.3.3 Frame misordering

The MAC Service (9.2 of ISO/IEC 15802-1) permits a negligible rate of reordering of frames with a given user priority for a given combination of destination address and source address.

...

K.3 Frame misordering

A change in the active topology between two communicating end stations can result in frame misordering, as a frame sent after reconfiguration can experience a lower transit delay, being queued at fewer Bridge Ports or for less time.

8
  • If it has no dot1q header, where's the dot1p stuff being encoded? It's possible frames could be reordered, but not likely with a FIFO queue. I've never worked with hardware that did QoS at layer-2. Do you have a list of hardware to research?
    – Ricky
    May 29, 2014 at 19:02
  • I have clarified the question regarding VLAN, since it is either no VLAN or VLAN with same ID and priority. I have no specific hardware in mind, so my question concerns if switches/bridges in general may reorder the frames for same flow.
    – EquipDev
    May 29, 2014 at 19:57
  • 1
    @EquipDev, your edit now muddies the waters. While your original question is about frame (L2) reordering, but now you added in a quote about packet (L3) reordering, specifically from an MPLS RFC. As I touched on in my answer, this is addressing tunneling Ethernet and how it should address the hard invariants (sequential delivery and non-duplication of frames).
    – YLearn
    May 30, 2014 at 14:05
  • 1
    I'm sorry but could you give us a clue why you're asking? It's starting to sound like you don't know what you need to ask for. Knowing why you're asking and what problem you're solving would really help.
    – user5025
    May 30, 2014 at 14:58
  • 1
    @EquipDev, again my answer still stands. An active topology change would indicate an unstable network of some kind, for instance a failure or while the network is being changed. These states would move the network out of a "properly working" state until the network re-stabalizes. I also concur with user5025, so maybe some more background on why you are asking would help?
    – YLearn
    May 30, 2014 at 15:06

2 Answers 2

7

Sequential delivery of frames is considered a hard invariant. This means that in any properly working network, the frames should always be delivered in the order they are received.

When you get above L2, this is not always the case as packets can be received out of order. However if you do tunnel L2 traffic over L3, then the process ideally should account for making sure that sequential delivery of the frames is enforced even if the packets are received out of order. In practice this is often not the case.

4
  • Technically tunneling L2 frames provides no assurance of ordered delivery. There are some conditions outside the control of the protocol, for instance the use of per-packet-load-balancing on the tunneled traffic (regardless of how bad of an idea it typically is). If packets in that same stream transit two different physical paths, reordering is possible. Jun 3, 2014 at 1:15
  • @MikePennington, that is the point I was attempting to make in the second paragraph. While a protocol designed to tunnel L2 over a higher layer should try to account for sequential delivery, this is by no means guaranteed.
    – YLearn
    Jun 3, 2014 at 1:19
  • I am objecting more to the last sentence because enforcing ordered delivery simply isn't true for at least one of the most common tunneling protocols: EoMPLS Pseudowires. Jun 3, 2014 at 1:23
  • @MikePennington, I see what you are getting at, so I edited in an attempt to clarify what my thought was when adding that sentence. Hopefully this is clearer now.
    – YLearn
    Jun 3, 2014 at 1:30
6

It sounds like you are trying to put some boundaries on code you are writing for packets through a network.

Reordering should not happen on the switched LAN that you mentioned in your original question. Reordering could happen if you transit any kind of MPLS pseudowire, since MPLS is a fundamentally routed technology; routing introduces new forms of multi-path which don't exist in a traditional bridged LAN.

All that said, packet loss could be equally destructive to assumptions about "no reordering". Plan on packet loss through ethernet. If you are building your own packet transport layer, the SIMPLEST way around the insanity of building your own layer is to use the one that's been tested for more than 20 years: TCP over IP.

2
  • 1
    Correction: TCP over IP is known to sucks for 20 years, and it has been hacked/patched up so it works reasonably well on most typical networks, i.e. Those with plenty of capacity, no packet reordering and little jitter and packet loss. That, and it's a resource hog and an absolute pain to implement in hardware since it's a pile of backward compatible patches.
    – BatchyX
    May 31, 2014 at 8:14
  • 3
    For a protocol that's allegedly so awful, it seems to have built a rather large base of users. I am not sure what your point is other than ranting about some overblown FUD. Please troll elsewhere.
    – user5025
    May 31, 2014 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.