Talk:Medium access control
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||
|
Text and/or other creative content from this version of Talk:Media access control/oldversion was copied or moved into Media access control with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
Is it and Address?
[edit]An adress is a descriptor that describes a location within a framework. If one has knowledge of the framework and its rules, the address is sufficient to locate something. This is not true of a MAC. Despite its common usage, a MAC is not an address. it is an identifier, and a reasonable attempt at a globally unique one. —Preceding unsigned comment added by Enkidofriend (talk • contribs) 21:49, 27 April 2009 (UTC)
Is it Media or Medium Access Control Layer?
[edit]The correct form as used in the standards is "MEDIA access control". Whether that's correct grammatically is up for debate in some forum (fora?) perhaps - but not here please.--Snori 19:06, 8 September 2006 (UTC)
i was confused by that too - are we talking of the same thing? i am looking for an explanation of the medium access control (MAC) sub-layer as in:
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-392.pdf —Preceding unsigned comment added by 81.156.182.86 (talk) 01:52, 17 March 2010 (UTC)
- I've searched the IEEE 802.3 (2012) standard and see a handful of "Medium access control" instances and hundreds of "Media access control" instances. I propose we go with the later which would mean renaming the article. ~Kvng (talk) 14:50, 28 August 2018 (UTC)
- On the other hand, IEEE 802 (2014) says "medium access control" more than it says "media access control", as does IEEE 802.11 (2016). I propose we ask somebody at the IEEE which we should use. :-) Guy Harris (talk) 20:53, 28 August 2018 (UTC)
- If you're serious, I do have contacts in IEEE Standards that I could ask about this. WP:TITLE basically says we should go by what readers are likely to be most familiar with. On Wikipedia I see 70 instances of "Medium access control" and 180 for "Media access control". On Google, results are more evenly split. ~Kvng (talk) 16:39, 1 September 2018 (UTC)
- "Medium" denotes an individual node, whereas "Media" indicates multiple nodes. While it is not incorrect to say "medium" in this context, it is improper. Referring to the "Media Access Control" or "MAC" sublayer is to properly mention its function: to talk to the "media" (as in "many mediums"). I have worked in IT and have held multiple industry certifications, and this is the first time I've seen the single-case word "Medium" used in the name. 71.125.11.157 (talk) 19:56, 30 January 2023 (UTC)
- "Medium" denotes an individual medium ("The materials or empty space through which signals, waves or forces pass."), whereas "Media" indicates multiple media (plural of medium). A medium, such as a thick yellow cable, may have multiple hosts attached to it as nodes. Guy Harris (talk) 22:18, 30 January 2023 (UTC)
- That is what I said. Yes, a "medium" is an individual piece of material or other such item (wave, signal, etc) that the signal passes to/through/from. Media is the industry term for the collection of items which pass the signal, thus it is known as the Media Access Control layer. For reference, please look at Comptia and Cisco's certifications. Here's information from Professor Messer: https://www.professormesser.com/network-plus/n10-007/access-control/ I hope this helps. 71.125.11.157 (talk) 17:18, 31 January 2023 (UTC)
- "Medium" denotes an individual medium ("The materials or empty space through which signals, waves or forces pass."), whereas "Media" indicates multiple media (plural of medium). A medium, such as a thick yellow cable, may have multiple hosts attached to it as nodes. Guy Harris (talk) 22:18, 30 January 2023 (UTC)
- "Medium" denotes an individual node, whereas "Media" indicates multiple nodes. While it is not incorrect to say "medium" in this context, it is improper. Referring to the "Media Access Control" or "MAC" sublayer is to properly mention its function: to talk to the "media" (as in "many mediums"). I have worked in IT and have held multiple industry certifications, and this is the first time I've seen the single-case word "Medium" used in the name. 71.125.11.157 (talk) 19:56, 30 January 2023 (UTC)
The video is talking about "access control" - "network access control", rather than "{medium,media} access control" - in the sense of permissions, as in, for example, "this MAC address is allowed to send packets to and receive packets from this switch port". "Access control" in the phrases "{medium,media} access control" is - or, at least, originally was - about "access control" in the sense of partitioning access to a shared medium, using various channel access methods. (An analogy to the "permissions" sense of access control would be a limited-access road that is a private road where you have to show a badge in order for the operator to open a gate to allow you to enter the road. An analogy to the "partitioning access to a shared medium" sense of access control would be a ramp meter at the entrance to a limited-access road.) The MAC address is used for some forms of permission access control, but MAC addresses were not created for access-control purposes.
And what is the "collection of items which pass the signal"? Is it referring to all the LAN segments in a corporate network, for example? If so, for a given station, the MAC layer only involves the segment to which that station is connected.
As this article says in Medium access control § Functions performed in the MAC sublayer, multiple functions are performed by that sublayer, one of which is "Control of access to the physical transmission medium". MAC addresses are used by another function, "Addressing of destination stations (both as individual stations and as groups of stations)".
IEEE Std 802-1990, which always uses "medium access control", says that "these medium access control (MAC) standards are defined for a variety of physical media". Earlier in the document, it says "The IEEE 802 LAN is a shared-medium peer-to-peer communications network that broadcasts information for all stations to receive.", so this predates switched networking, such as switched Ethernet, in which stations have point-to-point full-duplex links to a switch, and "access control" in the "partitioning access to a shared medium" sense is not required. "Medium" is used in that standard to refer to a particular medium, such as, at the time tnat standard came out, 10BASE5 thick yellow cable, 10BASE2 thin black cable, 1BASE5 twisted pair, all for Ethernet, and IEEE 802.5 twisted pair. "Media" refers to the various particular media supported by various IEEE 802 standards.
IEEE Std 802-2001 says MAC stands for "medium access control, media access control", with a footnote saying "Both forms are used, with the same meaning. This standard uses “medium.”" It again uses "medium" to refer to a particular physical medium and "media" as a plurality of physical media. IEEE Std 802-2014 does the same.
So it appears that the IEEE uses "media" to refer to the set of various physical media types supported by IEEE 802 standards, rather than the industry usage.
Both "medium access control" and "media access control" work. For a given physical mediaum, there's a particular "medium access control" protocol, and there are "media access control" protocols for all the different physical media. Guy Harris (talk) 03:15, 1 February 2023 (UTC)
- If we agree that medium is singular and media is plural, then our current title would arguably be the preferred title per WP:SINGULAR. In any case, there doesn't appear to be a clear consensus to change the title. ~Kvng (talk) 14:33, 4 February 2023 (UTC)
Checksum verification in the MAC sublayer?
[edit]I felt certain before reading this article that all forms of reliability insurance measures were the alotted responsibility of the Logical Link Control sublayer of the Data link layer, rather than of the MAC layer. If I'm right, shouldn't the point on error detection and correction by means of checksum verification belong in the article on the Logical Link Control sublayer?
- Dominio
- I think I found the precise information. See my contrib. Regards. Gtabary 13:44, 26 February 2006 (UTC)
Yes, the checksum verification is actually one of the things that the MAC layer DOES do. See 802.3-2002 section 4.1.4. Why do people keep saying that the MAC address is handled in the MAC layer? That is WRONG. It is handled much higher, in the ARP cache. — Preceding unsigned comment added by 74.96.165.138 (talk) 14:19, 26 August 2011 (UTC)
I added the FCS verification back, and the IEEE reference again. Bentogoa keeps deleting it. Apparently he wants everyone to think that a MAC is just a MAC address.
Function of MAC (controller)
[edit]The statement "the MAC address is not actually handled in the MAC layer" seems suspect. Is there a reference for this? I have seen hardware that directly contradicts this (Look at the altera TSE which runs at 1G for instance). Also letting the hardware handle address filtering doesn't preclude the use of software ARP. — Preceding unsigned comment added by 196.215.48.7 (talk) 15:28, 26 June 2012 (UTC)
Move discussion in progress
[edit]There is a move discussion in progress which affects this page. Please participate at Talk:Logical Link Control - Requested move and not in this talk page section. Thank you. —RM bot 03:21, 27 October 2011 (UTC)
Connection-oriented or connectionless?
[edit]I generally think of lower layer protocols (e.g. those in data link and network layers; physical?) being connectionless and higher level ones (transport to application layer) being connection-oriented, but I could be wrong. I am just saying in general. WorldQuestioneer (talk) 22:08, 17 July 2020 (UTC)
- And what are you suggesting may need to be changed in the article to reflect that? Guy Harris (talk) 22:35, 17 July 2020 (UTC)
- The lower layers are not "connectionless" at all, rather different styles of connections. Think of a hub versus a switch versus a router. The router uses IP addresses to forward information, while switches use the media access control (MAC) address to send information, and hubs send information to the ports. Most hubs fall into the "dumb" device category. They typically send information out to every port, with each device seeing what every other device is sending. There are "smart" layer one devices that can be set to forward traffic between specific ports.
- Each layer is named appropriately for their function. "All People Seem To Need Dirty Popsicles" is a way to remember the 7-Layer OSI model: Application, Presentation, Session, Transport, Network, Data-Link, Physical. Without "NDP", you don't have a connection. The rest define the way the connection works and its end function. I hope that helps. 71.125.11.157 (talk) 17:38, 31 January 2023 (UTC)
- The first edition of the OSI model document, ISO 7498 (1984), states in section 5.3 "Communication between peer-entities" that an "(N)-connection" is "An association established by the (N)-layer between two or more (N + 1)-entities for the transfer of data", so you can have connections at all layers other than the Application Layer (as that's layer 7, and there's no layer 8, so there are no "(7 + 1)-entities" to establish a connection atop the Application Layer).
- THe second edition, ISO 7498 (1994), says the same thing, but in section 5.3.3 "Modes of communication" speaks of both "connection-mode service" and "connectionless-mode service" - "An (N)-layer may offer a connection-mode service, a connectionless-mode service, or both, to the (N+1)-layer...".
- In the connection-mode (5.3.3.2) of the (N-1) layer, a connection is made between two or more peer-(N)-entities as the first phase of the use of the connection-mode service, followed by data transfer over the connection, and finally releasing the connection.
- In the connectionless-mode (5.3.3.3) of the (N-1) layer, there's only the data transfer.
- There's no connection establishment phase in Ethernet at the data link layer. There is a mechanical connection, and an electrical or optical connection, but that's a connection to the medium for shared-medium Ethernet, to the hub for star-topology non-switched Ethernet, and to the switch for switched Ethernet; it's not a physical-layer connection beetween the source and the destination. The switch might determine the MAC address of the host plugged into it from the source address of the packet it sees coming from the host, and only send unicast packets to that port if they have that destination MAC address, but that's an underneath-the-protocol optimization, not a part of the Ethernet protocol. There's also autonegotiation, but I'm not sure that autonegotiation involves establishing a connection.)
- ISO 11575 has mappings between the connection-mode and connectionless-mode data link layer services and various data link layer protocols. ISO/IEC 7776, which is X.25 LAPB, as well as HDLC Unbalanced Operation Normal response mode Class and 802.2 LLC Type 2 map to the connection-mode data link layer service; HDLC connectionless-mode Balanced and Unbalanced classes of procedure, and 802.2 LLC Type 1, map to the connectionless-mode data link layer service. For Ethernet, other 802 LANs, and FDDI, that's at the LLC layer, not the MAC layer.
- There's also no connection establishment in IPv4 or IPv6. OSI has a connectionless-mode network protocol, ISO 8473; it doesn't appear to have its own connection-mode network protocol, although ISO 8878 and ITU-T X.223 are (slightly different) specifications for using the X.25 Packet Layer Protocol to provide the connection-mode network service.
- So, no, there aren't always connections, in the OSI sense, at the data link and network layers. Guy Harris (talk) 08:55, 1 February 2023 (UTC)
MAC address and Message Authentication Code -- Should or shouldn't there be a distinction?
[edit]I previously added a distinguish tag because I got confused between the 2, especially since the latter is less known, and since they have similar functions. To add more details,
- Both Message Authentication Code and MAC address are abbreviated the same
- Both are networking and security concepts
- Both can be used to achieve authentication (MAC address specifically can be used for authorization, too) and non-repudiation - within IAM and PAM systems
@Fgnievinski reverted my edit, justifying that it's an unlikely confusion. I beg to differ
I wanted to start up a discussion to prevent an edit-war TAbdiukov (talk) 09:01, 22 September 2023 (UTC)
- @TAbdiukov: My rationale was that WP:NOTAMB applied here. That would still leave the possibility of WP:HATREDIR. But looking at the redirects, only MAC layer and MAC protocol redirect here [1], where the second word provides sufficient disambiguation. I've also checked whether MAC address has any ambiguous redirects, such as MAC code, but that doesn't seem to be the case [2]. The key issue is that "MAC" doesn't redirect anywhere, it's a DAB page. So, I still think there's unlikely confusion. That said, you might want to discuss, with sources, the third point (about authentication, authorization, and non-repudiation) in the body of MAC address. In that case, a DAB hatnote would still be discouraged, because of WP:RELATED. fgnievinski (talk) 23:43, 22 September 2023 (UTC)
- I think fgnievinski has it right as far as what the guidance on hatnotes tells us to do. TAbdiukov can you describe a scenario where readers looking for Message authentication code would end up here? ~Kvng (talk) 14:25, 25 September 2023 (UTC)
- No worries , and thanks for detailed explanation @Fgnievinski!
- > TAbdiukov can you describe a scenario where readers looking for Message authentication code would end up here?
- In my personal case (which may or may not be common), I looked for "Message authentication code" in the context of cloud network security (as opposed to traditional networking), which I naively abbreviated as "MAC" (for not knowing better) and concluded that it must be a counterpart of a burnt-in MAC-address in the cloud context. It is somewhat easy to make this mistake: in the cloud, networking is predesigned and largely virtualized (down to virtualized IS-IS topologies, virtual switches, virtual LAN adapters). However, we know that they are distinct: "Message authentication code" changes for every message by design, and MAC-address (is supposed to) stay the same for L2 protocols communication.
- Furthermore, Message authentication code itself reads,
- > The term message integrity code (MIC) is frequently substituted for the term MAC, especially in communications to distinguish it from the use of the latter as media access control address (MAC address).
- I hope this is helpful
- TAbdiukov (talk) 04:50, 25 October 2023 (UTC)
However, we know that they are distinct...
...and serve completely distinct purposes.- MAC addresses were originally used on a shared medium to allow a frame to be handled by a particular host on the medium, so that if a network adapter on the medium sees the frame, it can check to see if it's addressed to that adapter's MAC address, and accept it if it is and otherwise ignore it (as on a shared-medium Ethernet) or pass it on to the next host (as in a token ring). That function was not primarily concerned with security, authentication (hosts pretty much trusted the source MAC address, so it was more identification than authentication), or authorization; use for those purposes came later.
- Message authentication codes are intended to be used for verifying the sender and the integrity of the message, and have nothing to do with specifying the destination of the message. Guy Harris (talk) 07:01, 25 October 2023 (UTC)
- I think fgnievinski has it right as far as what the guidance on hatnotes tells us to do. TAbdiukov can you describe a scenario where readers looking for Message authentication code would end up here? ~Kvng (talk) 14:25, 25 September 2023 (UTC)
- C-Class Computing articles
- Mid-importance Computing articles
- C-Class Computer networking articles
- Mid-importance Computer networking articles
- C-Class Computer networking articles of Mid-importance
- All Computer networking articles
- All Computing articles
- C-Class Telecommunications articles
- Mid-importance Telecommunications articles