WO2016202377A1

WO2016202377A1 - Avb frame forwarding

Info

Publication number: WO2016202377A1
Application number: PCT/EP2015/063557
Authority: WO
Inventors: Dnyaneshwar Kulkarni; Christian Mardmoeller
Original assignee: Renesas Electronics Europe Limited
Priority date: 2015-06-17
Filing date: 2015-06-17
Publication date: 2016-12-22

Abstract

An AVB-compliant Ethernet bridge (3) is disclosed. The bridge comprises a plurality of ports (13, 13₂, _…, 13_N) and a switch fabric (15) configured to forward a frame (7) received by one of the ports to at least one of the ports in dependence upon the stream identifier (50; Fig. 4).

Description

AVB frame forwarding Field of Invention

The present invention relates to Audio Video Bridging (AVB) frame forwarding.

Background

Audio Video Bridging (AVB) allows data to be transmitted through local area networks (LANs) reliably and with guaranteed maximum latency compared with non-AVB Ethernet networks. Data packets can be transmitted between end stations through AVB-compliant Ethernet bridges using switching based on Open Systems

Interconnection (OSI) model Layer 2 and/or Layer 3.

For example, an Ethernet switch can use Layer 2 information to identify one or more output ports. Switching is based on a 48-bit MAC destination address found in the Ethernet frame header. Frames with multicast addresses are usually forwarded to all ports. However, this is inefficient for AVB since all streams are multicast.

Alternatively, an Ethernet switch can use Layer 3 and higher-layer information to identify one or more output ports. In this case, switching is based on 16-bit Ethernet Type, 16-bit VLAN tag and/or upper layer frame information. Frames with multicast addresses are restricted to ports used for Layer 3 communication, such as broadcast domains. When using VLAN tagging in AVB networks, a relationship between a reserved stream and VLAN needs to be established. Furthermore, the number of VLANs is limited to 4096 values (i.e. 2¹²). Also, depending on the protocol used, configuration by network management may be required.

Summary

According to a first aspect of the present invention there is provided an AVB-compliant Ethernet bridge (which may also be referred to as a "switch") comprising a plurality of ports and a switch fabric configured to forward a frame received by one of the ports to at least one of the ports in dependence upon a stream identifier.

Thus, a stream identifier can be used not only for identifying media streams at a receiver, as described in WO 2011/115900 Ai, but also for switching and such switching can be integrated into a switch fabric capable of Layer 2 and Layer 3 switching. Also, the bridge can control a greater number of streams than there are VLANs, for example, up to 65536 (i.e. 2¹⁶) per source/talker.

The switch fabric may comprise logic configured to determine whether a frame has a valid AVB stream format (for example, compliant with IEEE 1722) and, upon a positive determination, to determine whether to forward the frame according to the stream identifier.

The bridge may further comprise a forwarding table comprising at least one entry, wherein each respective entry comprises first and second fields associating a given stream identifier with at least one of the ports. Each respective entry may further comprises a third field for associating the given stream identifier with a queue. Each respective entry may further comprise a fourth field for associating the given stream identifier with a frame processing instruction.

The switch fabric may comprise logic configured, in response to a determination that the frame does not have a valid AVB stream format, to determine whether the frame includes a VLAN identity for VLAN tagging.

The bridge may comprise an Ethernet switch block comprising the switch fabric and ports. The bridge may further comprise a memory. The bridge may further comprise an interconnect (for example AXI interconnect) between the ports and switch fabric and, optionally, the memory. The bridge may further comprise a CPU sub-system. The CPU sub-system may comprise one or more CPUs and memory. The bridge may take the form of an integrated circuit. The integrated circuit may be a microcontroller. The integrated circuit may be an application specific integrated circuit (ASIC). The integrated circuit may be a system on a chip (SoC). The bridge may comprise a set of one or more integrated circuits comprising a first integrated circuit comprising the switch fabric and ports. The first integrated circuit may further include the switch memory. The first integrated circuit may further include a CPU-subsystem. The set of one or more integrated circuits may comprise a second integrated circuit comprising switch memory. The set of one or more integrated circuits may comprise at least a third integrated circuit comprising a CPU.

According to a second aspect of the present invention there is provided a motor vehicle comprising a network which comprises at least one bridge.

The motor vehicle may be a motorcycle, an automobile (sometimes referred to as a "car"), a minibus, a bus, a truck or lorry. The motor vehicle may be powered by an internal combustion engine and/or one or more electric motors.

According to a third aspect of the present invention there is provided an integrated circuit for providing an AVB-compliant Ethernet bridge, the integrated circuit comprising a plurality of ports and a switch fabric configured to forward a frame to at least one port in dependence upon a stream identifier.

The integrated circuit may comprise an Ethernet switch block comprising the switch fabric and the ports. The integrated circuit may further comprise memory. The integrated circuit may further comprise an interconnect between the ports and switch fabric. The integrated circuit may further comprise a CPU sub-system.

The integrated circuit may be a microcontroller. The integrated circuit may be an application specific integrated circuit (ASIC). The integrated circuit may be a system on a chip (SoC).

According to a fourth aspect of the present invention there is provided a method of forwarding AVB-compliant Ethernet frames. The method comprises forwarding a frame to at least one port in dependence upon a stream identifier.

The method is preferably implemented in hardware logic. Brief Description of Drawings

Certain embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure l is a schematic block diagram of an Ethernet network comprising a plurality of bridges deployed in a motor vehicle;

Figure 2 is a schematic block diagram of a bridge used in an Ethernet network shown in Figure l;

Figure 3 schematically illustrates shows a forwarding table;

Figure 4 schematically illustrates shows an AVB-related part of the forwarding table shown in Figure 3;

Figure 5 schematically illustrates a frame which includes an IEEE 1722 packet;

Figure 6 schematically illustrates forwarding of a frame; and

Figure 7 is a process flow diagram of a method of handling stream frames. Detailed Description of Certain Embodiments

Ethernet network 1

Referring to Figure 1, an Ethernet network 1 which is capable of supporting Audio Video Bridging (AVB) is shown. The Ethernet network 1 comprises a plurality of end stations 2 (which may serve as sources (or "talkers") and/or destinations (or

"listeners")) and bridges 3 interconnecting the end stations 2. The bridges 3 support IEEE 1722 and, optionally, IEEE 1733 protocols, as well as IEEE 802. lQ, IEEE

802.iQav, IEEE 8o2.iQat, IEEE 802.1BA and IEEE 802.1AS protocols.

The network 1 includes at least one AVB domain 4, i.e. portion(s) 4 of network 1 which carry AVB traffic between end stations 2 via AVB-compliant bridges 3. Two or more AVB domains 4 can be connected one of more non-AVB domains (not shown), i.e.

portion(s) of network which carry non-AVB traffic via non-AVB bridges (not shown).

The network 1 is deployed in a motor vehicle 5. The network 1 can be shared by at least two systems 61, 6₂ belonging to one or more different vehicle domains, such as, for example, infotainment, driver assistance, diagnosis, chassis safety and body electronics. Thus, the network 1 may carry Ethernet frames 71, 72 for use in different systems 61, 6₂, such as video and audio frames 71 for an infotainment system and video frames 72 for a driver assistance system. Consequently, sources and/or destinations 2 in one system 61 can differ from sources and destinations 2 in another system 6₂. As shown in Figure 1, frames 71 from one vehicle domain can be transmitted to the same vehicle domain (as illustrated by a long-chain arrow) or to another, different domain (as illustrates by a short-chain arrow). Furthermore, latency requirements for different systems 61, 6₂ can differ, particularly if they belong to different vehicle domains.

As will be explained in more detail hereinafter, bridges 3 in the network 1 are able to forward frames 71, 72 according to IEEE 1722 stream identity using hardware-based logic. This can help not only to improve forwarding efficiency, but also to enable enhanced filtering and prioritisation.

Bridge 3

Referring also to Figure 2, a bridge 3 is shown in more detail.

The bridge 3 comprises an Ethernet switch block 11 and a central processing unit (CPU) sub-system 12. The bridge 3 preferably takes the form of an integrated circuit, for example, an microcontroller or system-on-a-chip.

The Ethernet switch block 11 comprises a plurality of external ports 131, 132, 13N, switch block random access memory (RAM) 14 and a switch fabric 15 connected by an interconnect 16, such as an Advanced extensible Interface (AXI) interconnect. The Ethernet switch block 11 also comprises a central timer 17 which supplies timing data 18 to each of the external ports 131, 132, 13 for receive and transmit time stamping.

Each external port 131, 132, i3 has a media access control (MAC) interface 191, 192, 19 connected to a respective physical layer (PHY) module 2O1, 20₂, 20N. The switch fabric 15 comprises ingress filtering logic 22, a forwarding table 23, queue handling logic 24 and optional data manipulation logic 25. As will be explained in more detail hereinafter, the switch fabric 15 allows hardware-based processing of frames 7 based on IEEE 1772 protocol without the need for using the CPU sub-system 12. The CPU sub-system 12 includes a CPU 26 and system RAM 27 connected by bus system 28.

The CPU 26 can be used to configure the ports 131, 132, 13N, the switch fabric 15, PHY modules 2O1, 20₂, 20 and a CPU interface 29 (which may be referred to as "Port o"). The CPU 26 can implement network control functions such as Address Resolution Protocol (ARP) for Layer 2, IEEE 8o2.iQcc Stream Reservation Protocol (SRP) and/or IEEE 802.1AS Generalized Precision Time Protocol (gPTP). The CPU 26 can be used to provide additional switching functionality, for example, in cases where switching is not handled by the switch fabric 15. The CPU 26 can be used to manage bridge-related communication, such as, for example, network management and downloading software. The CPU 26 can be used for bridge power management, for example, by placing the bridge 3 into sleep mode and waking it up.

The bridge 3 includes a data interface 30 to the CPU 26 and a control interface 31 between the CPU 26, the central timer 17 and the external ports 131, 132, 13 .

The switch block 11 will now be described in more detail: CPU interface 29

The CPU interface 29 is an abstraction which allows the CPU sub-system 12 to participate in Ethernet communication via the data interface 30. Frames 7 provided by the CPU 26 can be forwarded according to the forwarding table 23 and/or forwarded directly to specific external ports 131, 132, 13 as specified by the CPU 26. The CPU interface 29 can flag status of frames sent to or generated by CPU 26. To limit the time that frames are stored in the switch block RAM 14, frame data may be exchanged via CPU interface 29 and be stored in system RAM 27 in the CPU subsystem 12.

External ports i3i . 13? 13N

Each external port 131, 132, 13 is able to perform a plurality of functions including a (a) queue-based transmit selection/schedule function based on data provided by queue handling logic 24, (b) a transmit time stamping function having an interface to the CPU 19 either directly or via the switching fabric 14, (c) a receive pre-filtering function which can be performed in combination with ingress filtering in the switch fabric 15, (d) a receive pre-queuing function which may be performed in combination with ingress filtering in the switch fabric 15 and (e) a receive time stamping function having an interface to the CPU 26 either directly or via the switching fabric 14.

Each external port 131, 132, 13 is able to implement MAC functionality according IEEE 802.3. Each external port 131, 132, 13 has at least one receive interface to provide a received frame and status (not shown) to the switch fabric 15. The port 131, 132, 13 can provide a receive frame as a whole element after reception or on the fly during reception. If the port 131, 132, 13 implements pre-emption according to IEEE 8o2.iQbv, then it has at least two receive interfaces to avoid blocking at the switching fabric level.

Each external port 131, 132, 13 is able to determine a time stamp (not shown) for a receive frame. The time stamp (not shown) is provided as part of frame status (not shown) to the switching fabric 15 or directly to the CPU 26.

Each external port 131, 132, 13 has transmit interface for each transmit queue maintained by the switching fabric 15.

Each port 131, 132, 13 has at least two transmit queues for different traffic classes, for example A and B.

Transmit frames can be provided as whole element after scheduling by the switching fabric 15 or on the fly during transmission. Pre-emption is a queue-based protocol and so no additional interfaces are required. If the switching fabric 15 provides data on the fly, the switching fabric 15 is able to support express MAC (eMAC) and pre-emptive MAC (pMAC) in parallel for time sensitive network (TSN) switching.

Each external port 131, 132, 13 may be able to provide transmit select and schedule function. This may be a distributed function which is synchronised by the queue handler 24. This can help to allow scheduling precisely to frame transmission on the media independent interface. To achieve this, a port 131, 132, 13 may be provided with functionality to allow local queue based buffering at least part of a frame so as to reduce switch fabric response time requirements.

Each external port 131, 132, 13 is able to determine a time stamp (not shown) for a transmit frame. The time stamp (not shown) is provided as part of frame status (not shown) to the switching fabric 15 or directly to the CPU 26. As shown in Figure 2, receive and transmit interfaces are implemented using a combined interface. However, different interfaces (not shown) can be used, for example, for different traffic classes. Switch block RAM 14

The switch block RAM 14 is data RAM used by the switch block 11 to buffer receive frames 7 for forwarding. The switch block RAM 14 can be provided internally in the Ethernet switch block 11 (i.e. on-chip) or externally (i.e. off-chip). The switch block RAM 14 can be divided into smaller blocks (not shown). The switch block RAM 14 can be, for example, 1 MB or 100 MB (or other memory size) and can be divided into blocks of, for instance, 512 B (bytes).

Switch fabric IF,

Ingress filter logic 22

The ingress filtering logic 22 in the switch fabric 15 analyses receive frames 7 to decide whether to discard or output each frame 7 to given ports 131, 132, 13 depending on information in forwarding table 23. Filtering may be distributed and some of the filtering may be performed by the external ports 131, 132, 13N. The ingress filtering logic 22 may implement ingress policing which can block a talker stream that exceeds a reserved bandwidth threshold. Ingress policing is similar to (egress) credit-based shaping, but which takes place for receive frames (as opposed to transmit frames) and is stream based. Preferably, the bandwidth for a talker is limited (as opposed to entirely blocking traffic for that talker). Ingress policing filters in the bridge 3 can monitor AVB streams and block streams that consume more bandwidth than reserved.

The ingress filtering logic 22 uses Layer 2 and Layer 3 information, in particular IEEE 1722 protocol frame information, to identify one or more output ports 131, 132, 13N. Switching is based on all or part of a 64-bit stream ID. AVB bridges support Stream Reservation Protocol (SRP) to configure output ports and reserve bandwidth. This information can be used directly to populate the forwarding table 23.

Filtering may also contain discard filters to eliminate unexpected or uninteresting traffic. Forwarding table 23

Referring also to Figure 3, the forwarding table 23 includes first, second and third parts

The first part 231 of the forwarding table 23 (hereinafter referred to as the "AVB-related part" of the forwarding table) is used for stream ID-based forwarding. The second part 232 of the forwarding table 23 (hereinafter referred to as the "VLAN tag-related part" of the forwarding table) is used for VLAN tag-based forwarding. The third part 23₃ of the forwarding table 23 (hereinafter referred to as the "DA-related part" of the forwarding table) is used for MAC address-based forwarding.

The AVB-related part 231 of the forwarding table 23 is addressed using stream identifier. It may comprise a unique forwarding table or a hash table. The other parts of the table 232, 23₃ can be addressed using VLAN tag and/or destination address.

The forwarding table 23 may be populated dynamically during runtime using information gathered during routing, for example, using Address Resolution Protocol (ADP) or Stream Reservation Protocol (SRP). Additionally or alternatively, the forwarding table 23 may be statically pre-configured.

Referring also to Figure 4, the AVB-related part 231 of the forwarding table 23 includes a set of entries 32. Each entry 32 includes a stream identifier 33, that is, an entry qualifier which is used to filter results, a target port 34, a target queue 35 and optional priority requirements 36 which can be used to handle frames in given situations, such as out-of-memory. The Stream identifier 33 can, optionally, be a mask covering a range of streams for a single entry 32. The target port field 34 can specify more than one target port, although only one queue is specified per port.

The forwarding table 23 can specify forwarding to the CPU 26 via the CPU interface 29.

The forwarding table 23 is checked for each IEEE 1722-compliant receive frame 7 received by a port 131, 132, 13 and/or CPU interface 29.

Queue handling logic 24

The queue handling logic 24 controls the position where input ports 131, 132, 13 store receive data in the switch block RAM 14, controls where transmit is stored in the switch block RAM 14 and schedules fetching of transmit frames by ports 131, 132,

13N. Queue handling may be distributed and some of the queue handling functionality may be performed by logic in the external ports 131, 132, 13N. In relation to receive frames, a filtering scheme based on one or more receive queues per port can be used.

The queue handling logic 24 may implement transmit traffic shaping. The logic 24 can decide when and from which transmit queue transmission starts, for example, based on fixed priority, round robin, credit-based shaping etc. Traffic shaping may be distributed and some of the traffic shaping functionality may be performed by logic in the external ports 131, 132, 13 .

The queue handling logic 24 collects and stores frame status in switch block RAM 14. It can block frame area until a frame is transmitted.

The queue handling logic 24 can also handle timestamping for receive and transmit frames. Timestamping may be distributed and some of the queue handling

functionality may be performed by logic in the ports 131, 132, 13N. Timestamps are can be used for IEEE 802. lAS protocol frames handled by CPU 26 via the internal CPU interface 29. For other types of frames, no-hop related timestamping may be required.

Data manipulation logic 25

The optional data manipulation logic 25 can be used to change frame content when forwarding a frame to a port 131, 132, 13 .

The data manipulation logic 25 may, for example, change the tag control information (TCI) 48 (Figure 5) in the VLAN tag 45 (Figure 5) or PCP (not shown). The data manipulation logic 25 may, for example, may be used for frame duplication as required for redundancy in multipath networks, for example, for implementing IEEE 802.1CB.

Any such data manipulation can be performed by switch fabric 15, for example, based on configuration specified in the forwarding table 23. However, data manipulation, particularly where deeper changes are needed, may be performed by the CPU 26, in which case the switch fabric 15 forwards the frame 7 to the CPU 26 via the CPU interface 29.

Referring to Figure 5, an IEEE 802. lQ compliant Ethernet frame 7 is shown.

The frame 7, which may be preceded by a preamble 39 and a start-of-frame delimiter (SFD) 40, comprises an 18-byte header 41, a payload 42 which comprises o to 1500 bytes and a 4-byte frame check sequence (FCS). The frame 7 has a minimum length of 64 bytes.

The header 41 comprises a 6-byte destination address 43, a 6-byte source address 44, a 4-byte VLAN tag 45 and a 2-byte Ethernet tag 46.

The 4-byte VLAN tag 45 comprises a 16-bit tag protocol identifier (TPI) 47 and a 16-bit tag control identifier (TCI) 48.

The payload 42 includes a 4-byte 1772 header 49, an 8-byte stream identifier 50 and additional header and payload 51. The stream identifier 50 is used to address the AVB- related part 231 of the forwarding table 23 (Figure 4).

The 1772 header 49 includes subtype data 52 which includes a stream ID valid (SV) bit 53 and a three-bit 1722 version 54.

The destination address 43, Ethernet tag 46, the tag protocol identifier 47, the stream identifier 50, the SV bit 53 and, optionally, the 1772 version bits 54 are checked to identify the frame 7 as being a 1722 frame and to extract information for frame forwarding.

Identifying an 1722 frame

Referring to Figures 2 and 5, the bridge 3 implements IEEE 1722 protocol-based Layer 3 switching and Layer 2 switching required for basic Ethernet functionality.

In an IEEE 1722 protocol Ethernet frame 7, a defined range of multicast is defined in the destination address field 43, a tag protocol identifier 47 is set to 0x8100 and the Ethernet type 46 is set to OX22F0. Inside the payload 42, the SV bit 53 is set to Ί'. The SV bit 53 should only be set to '0' for control protocol AVTPDUs not related to an individual stream. The three-bit 1722 version 54 is set to Ό', i.e. obooo. The stream identifier 50 specifies a 64-bit address. Filtering example

Referring to Figures 2, 5, 6 and 7, a method of forwarding a frame 7 is described.

In the following, it is assumed that ports 131, 132, 13 do not carry out any filtering of receive frames 7, that the switch fabric 15 can process receive frames 7 in parallel and that the complete frame 7 is available. However, to reduce latency, only a portion of the frame 7, e.g. frame header 41 and data up to byte 29, need be processed initially. In 1 Gbps, the shortest frame (payload of 60 bytes) is around 0.5 μβ. By starting processing early, buffering and overlapping can be reduced. The switch fabric 15 waits to receive a frame 7 (step Si).

Once a receive frame 7 is received, a first logic circuit 55 in ingress filtering 22 examines bytes o to 18 to determine whether the frame 7 is an IEEE 1722 protocol compliant frame based on destination address 43, tag protocol identifier 47 and the Ethernet type 46 (step S2).

A second logic circuit 56 in ingress filtering 22 examines bytes 22 to 29 to determine whether the stream ID 50 of the 1722 frame 7 is found in the AVB-related part 231 of the forwarding table 23 (step S3). If an entry 32 for the stream ID 50 is found in the forwarding table 23, the a third logic circuit 56 in ingress filtering 22 forwards the frame 7 according to the AVB-related part 231 of the forwarding table 23 (step S4). Otherwise, the frame 7 is forwarded to the CPU 26 via the CPU interface 29 (step S5).

Other ingress forwarding logic circuits 58 can examine the frame 7 to determine whether the frame 7 is an IEEE 802. lQ protocol frame based on the Ethernet type 46 (step S6) and forward the frame 7 as appropriate using the VLAN-ID (steps S7, S5 and S6).

Other ingress forwarding logic circuits 58 can examine the frame 7 to determine whether the frame 7 is a multicast frame based on the least-significant bit of the destination address 43 (step S8) and, if so, to forward the frame 7 to all or some of the ports (step S9).

If the frame 7 is not multicast, the ingress forwarding logic circuits 58 examine the destination address 43 to check if it is the forwarding table 23 (strep Sio) and, if so, to forward the frame 7 appropriately (step S4). Otherwise, the frame 7 is forwarded to the CPU 26 via CPU interface 29 (step S5).

The forwarding table 23 can be checked complete or in a paged mode. Paging the forwarding table 26 reduces the overhead required to identify a potential entry 32. As explained earlier, hash algorithms can be used for paging.

It will be appreciated that many modifications may be made to the embodiments herein before described.

The network need not be deployed in a motor vehicle. The network can be used in an AVB-based network, such as professional audio systems (for example, used in stadia).

Claims

1. An AVB-compliant Ethernet bridge comprising:

a plurality of ports (131, 132, 13N); and

a switch fabric (15) configured to forward a frame received by one of the ports to at least one of the ports in dependence upon the stream identifier (50).

2. A bridge according to claim 1, wherein the switch fabric comprises:

logic (22) configured to determine whether a frame has a valid AVB stream format and, upon a positive determination, to determine whether to forward the frame according to the stream identifier.

3. A bridge according to claim 1 or 2, further comprising:

a forwarding table (23) comprising at least one entry (32), wherein each respective entry comprises first and second fields (33, 34) associating a given stream identifier with at least one of the ports.

4. A bridge according to claim 3, wherein each respective entry (33) further comprises a third field (35) for associating the given stream identifier with a queue.

5. A bridge according to claim 3 or 4, wherein each respective entry (33) further comprises a fourth field (36) for associating the given stream identifier with a frame processing instruction.

6. A bridge according to any preceding claim, wherein the switch fabric comprises: logic (22) configured, in response to a determination that the frame does not have frame has a valid AVB format, to determine whether the frame has a VLAN identity for VLAN tagging.

7. A bridge according to any preceding claim in the form of an integrated circuit.

8. A motor vehicle comprising a network which comprises at least one bridge according to any preceding claim.

9. A method of forwarding AVB-compliant Ethernet frames comprising:

forwarding a frame to at least one port in dependence upon a stream identifier.

10. A method according to claim 9, which is implemented in hardware logic.