MAC
Mark
I seem to be developing a misunderstanding of MAC -- how necessary it can be
in specifica cases. Let me give an example: I have a SoC, consisting of
ARM-based proccessor with some peripherial (serial interfaces, timers etc.)
and switching fabric - everything is on the same chip. The only interface
between the control processor and the switch is DMA logic, i.e. CPU
receives/transmits packets only via DMA.
This puzzles me: how come that CPU doesn't have MAC block? Isn't it required
by the standard to present? Isn't it required by operating systems for
proper implementation of device drivers? And lastly - how is MAC address
assigned to CPU port in such case ?
Hopefully you can clarify my doubts. Thanks.
--
Mark
Rich Seifert
A MAC (Medium Access Control) entity is only required for a *network*
interface. You said that all you have is a processor, serial ports,
timers, and a switching fabric--no network interface(s), hence no MAC.
MAC addresses are not ordinarily assigned to CPU ports, but to network
interfaces
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
glen herrmannsfeldt
(snip)
> A MAC (Medium Access Control) entity is only required for a *network*
> interface. You said that all you have is a processor, serial ports,
> timers, and a switching fabric--no network interface(s), hence no MAC.
> MAC addresses are not ordinarily assigned to CPU ports, but to network
> interfaces
Except for Sun. Well, many Sun boards have ethernet on the same
board as the CPU. I beleive that even ones that don't, have the MAC
address PROM on the CPU board. When sending a board in for repair
(usually exchange), Sun wants one to remove the PROM before sending
the board in.
-- glen
Mark
news:cb7daa61-2f56-4848...@m7g2000prd.googlegroups.com...
>> Let me give an example: I have a SoC, consisting of
>> ARM-based proccessor with some peripherial (serial interfaces, timers
>> etc.)
>> and switching fabric - everything is on the same chip. The only interface
>> between the control processor and the switch is DMA logic, i.e. CPU
>> receives/transmits packets only via DMA.
> A MAC (Medium Access Control) entity is only required for a *network*
> interface. You said that all you have is a processor, serial ports,
> timers, and a switching fabric--no network interface(s), hence no MAC.
I might have expressed myself not very clearly. The software runs on the
CPU; device driver, being a part of that control software, obviously should
treat a switch fabric as network interface. If it so, then MAC is necessary,
isn't it ?
> MAC addresses are not ordinarily assigned to CPU ports, but to network
> interfaces
I have a Realtek switch, which when run 'show mac address-table' shows a MAC
address belonging to a CPU port, something like this:
MAC Address Port VLAN FID Static Age
-----------------------------------------------------------
xx:xx:xx:xx:xx:xx Fa0/18 1 0 0 6
... lots of MACs here
aa:aa:aa:00:00:01 CPU 1 0 1 15
...
where 'aa:aa:aa' is official Realtek OUI.
--
Mark
Rich Seifert
Which is exactly why I said MAC addresses are not *ordinarily*
assigned to CPU ports. Sun uses (used?) the model that I actually
prefer, i.e., that the MAC address identifies the *station*, rather
than the network interface. There is a discussion of these two models
in "The Switch Book," excerpted here:
"There are actually two philosophies for interpreting unicast
addresses. One philosophy follows the premise that a unicast address
identifies a device (e.g., a workstation or server), as opposed to a
network interface installed within the device. Under this philosophy,
when a device has multiple interfaces, it uses the same address on all
of them. This approach was used in the original Xerox Network System
(XNS) and most Sun Microsystems’ products.
The other philosophy, that an address uniquely identifies the
interface rather than the device, sees more widespread application
today, and is the model assumed in this book (even though the author
has an affection and longing for the 'architectural purity' of the
single address per device model). Using the address-per-interface
philosophy, a device with multiple interfaces will have multiple
unicast addresses assigned to it.
Both philosophies are valid, in the sense that both can be made to
work properly in a practical network. In neither case is there any
ambiguity about the destination for a frame sent to a given unicast
address."
Rich Seifert, The Switch Book (Wiley, © 2000) All rights reserved.
Rich Seifert
>
> I might have expressed myself not very clearly. The software runs on the
> CPU; device driver, being a part of that control software, obviously should
> treat a switch fabric as network interface. If it so, then MAC is necessary,
> isn't it ?
>
Why would a CPU directly connected to a switch fabric treat the fabric
as a network interface? Does the CPU appear as a station on the
network being switched by the fabric, or is it simply the control
processor?
> > MAC addresses are not ordinarily assigned to CPU ports, but to network
> > interfaces
>
> I have a Realtek switch, which when run 'show mac address-table' shows a MAC
> address belonging to a CPU port, something like this:
>
In this case, the CPU port appears as a station on the network, hence
the CPU is assigned a MAC address. This allows stations connected to
other ports on the switch to send messages to the switch CPU. If this
is also the case with your SoC application, then you may also need to
assign a MAC address to the CPU.
However, this does NOT mean that the CPU must "talk" to the switch
fabric through a MAC entity, e.g., an Ethernet-like interface. The CPU
can talk to the switch fabric through whatever means are available
(i.e., a DMA channel), and receive messages sent to it by decoding the
MAC address assigned to the CPU. Don't confuse the function of
assigning a MAC *address* to a CPU (for the purpose of determining
whether messages are being sent to that CPU or not) with the inclusion
of a network interface containing a MAC entity (such as an Ethernet
interface).
Does that make sense?
Mark
On Dec 23, 4:34 pm, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Why would a CPU directly connected to a switch fabric treat the fabric
> as a network interface? Does the CPU appear as a station on the
> network being switched by the fabric, or is it simply the control
> processor?
Actually, the switch' SDKs I saw were designed in this way (although they
supported only one operating system - Linux). Perhaps this is because among
the driver models available in Linux (character, block, network, PCI, USB
drivers), the network driver is the most appropriate to match requirements.
[skip]
> Does that make sense?
I think, now it is clear to me. Thanks a lot for clarifications.
--
Mark