- Yes. The MAC DA is the receiving port’s MAC. I failed to state in the diagrams that the stack represents a single-port device… presumably a host/server.
- UMTPDU subtype is irrelevant for the example… it could be anything, but let’s make examples of OAM and OMCI.
- The network administrator’s intent is to ensure that all UMTPDUs and all IP Network X are carried on VLAN X throughout the network and all IP Network
Y is carried in VLAN Y throughout the network. The host/station in the example is VLAN aware. If it receives a frame for VLAN X, then it accepts it and processes it (how it processes it is the question I would like to answer). By “process it”, I mean that
UMTPDUs that have VLAN X on them will be accepted and processed by the host in the corresponding sublayer, IP Packets that have VLAN X on them will also be processed by the corresponding sublayer(s) and network layer in the host. IP packets with VLAN Y on
them will be processed by the corresponding sublayer(s) and network layer in the host. Frames received with any other VLAN tag will not be accepted by the host, and, since the host is not a bridge, the frames will not be forwarded elsewhere.
Thank you for pointing out where the EISS and ISS are defined and providing the diagram. Unfortunately, this is the source of my confusion. It is unclear to me how the UMT layering maps onto the 802.1 layering.
I understand that the higher layers should not even realize that the UMT Sublayer is present, but it continues to be fuzzy to me how that will work when UMT is manipulating VLAN tags.
This gets especially confusing when you have UMT CONFIG being sent between UMT stations to configure the CTE (which might be filtering on VLANs) and some switch in the middle of the network is also manipulating
VLAN tags, potentially removing the very tag that UMT CONFIG has configured in the remote UMT Sublayer. In this case, how would UMT CONFIG work? I suppose the answer is that there will need to be a centralized management entity for UMT that is fully aware
of all the VLAN manipulation that is occurring in the network.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
kevin.noll@xxxxxxxxxxxx
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Friday, May 1, 2020 at 5:52 PM
To: Kevin Noll <kevin.noll@xxxxxxxxxxxx>, "stds-1904-2-TF@xxxxxxxxxxxxxxxxx" <stds-1904-2-TF@xxxxxxxxxxxxxxxxx>
Cc: "Curtis (CableLabs)" <c.knittle@xxxxxxxxxxxxx>, Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: RE: VLANs and UMT Sublayer
Kevin,
I will be happy to show the exact rules that would accomplish what you need if you could clarify what exactly your use case tries to do.
Specifically, please, clarify these questions:
1)
For all three frames types, is the DA equal to the receiving port’s MAC address?
2)
What is the UMTPDU subtype?
3)
Do you want the receiving device to verify that the UMTPDU is received with exactly VLAN X and discard the frame is it is either untagged or if VLAN value is not X?
The answer to your question in red is No, the EISS is not the same as MA_DATA.request/indication. ESS is located in different place (see the figure below) and its primitives (EM_UNITDATA.request
and EM_UNIDATA.indication) have many more parameters then are present in MA_DATA primitives. The MA_DATA interfaces maps into ISS (M_UNITDATA.request/indication primitives) and the mapping is described in the 802.1AC, Section 13.1.
I am not sure why this is even a question, though. Anything above UMT remains as it is now. None of the higher layers even know if UMT sublayer is there or not.
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Friday, May 01, 2020 1:39 PM
To: stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Glen Kramer <glen.kramer@xxxxxxxxxxxx>; Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: VLANs and UMT Sublayer
Glen,
I continue to be puzzled by the ability of UMT sublayer to add/remove and filter based on VLAN tags.
Could you take a look at the attached figures and help me understand how this would work and what I am misunderstanding.
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1