Glen,
After re-reading your email, I am confused, again.
Why do you reference figure 11-1?
Specific to the scenario I posited: 802.1Q-2018 Clause 6.3 specifically says that “A VLAN-aware end station can use the EISS Multiplex Entity (6.17) to provide multiple SAPs, one per VID of interest, to separate
MAC Clients”. I am confused why you did not reference this in your response.
I specifically asked how the proposed 1904.2 layering diagram aligns with the 802.1 layering. Figure 11-1 does not help clarify the relationship between UMT and 802.1Q.
Figure 11-1 is specific to describing the operation of MVRP. MVRP would be only tangentially relevant to VLAN tagging operation and only if it is deployed in the end station. Ultimately, MVRP exists, if implemented/deployed,
to support the EISS, so referencing MVRP doesn’t seem to actually answer the questions I am asking.
You have previously indicated that UMT Sublayer didn’t need to participate in MVRP and that UMT Sublayer’s tag manipulation is transparent to 802.1Q. However, I am wondering, if MVRP is in use and UMT Sublayer
is adding VLAN tags, how the rest of the network is expected to know about those tags such that the intermediate switches will accept UMT’s VLAN tags for forwarding to the next hop. Should there be a requirement that UMT cannot add a tag if that VLAN is not
also configured in MVRP?
--kan--
--
Kevin A. Noll
Sr. Director, Systems Architecture
Tibit Communications
kevin.noll@xxxxxxxxxxxx
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Monday, May 4, 2020 at 6:29 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,
The figures you had in your email illustrated a bridge. In a single-port end station, there is no MAC Relay Entity, since there are no multiple ports to relay the frames from and to. The figure
below shows a bridge on the left and a VLAN-aware end-station on the right.
An end station connected to a VLAN-aware bridge via aP2P link does not have to be VLAN aware. The bridge generally takes care of all VLAN-related filtering for the data sent to that station.
But end stations may be VLAN-aware for other reasons, such as source pruning or to support multiple MAC clients served by a single physical port. So, I guess your example wants to look at this latter scenario – one MAC client is an
IP Client X and another MAC client is an IP Client Y.
I am assuming that if there is no any UMT support (i.e., no UMT sublayer) in this end station and in the rest of VLAN-aware bridged network, then there are no questions about IP Clients X and
Y use of VLAN tags X and Y and we don’t need to go into any details. After all, this is 802.1Q stuff that exists today and that has nothing to do with 1904.2.
Now, the question is what happens if this end-station does have an UMT sublayer? There are no rules provisioned for the IP frames, so these frames pass through UMT sublayer unchanged. IP clients
X and Y continue operating as if the UMT sublayer does not exist.
As for the UMTPDUs, we want the UMT sublayer to insert VLAN tag X in UMTPDUs that carry OAM or OMCI payload (presumably because the rest of the bridged networks require those VLAN tags in order
to properly transport the UMTPDUs).
So, in the TX direction, we provision these egress tunnel entrance rules:
1)
For OAM:
IF( DA == SP_DA and ETH_LEN_TYPE == 0x88-09 and Subtype == 0x03 ) THEN
CHANGE( DA, <provisioned unicast addr> )
CHANGE( ETH_TYPE_LEN, 0xA8-C8 )
ADD( VLAN0, X )
2)
For OMCI:
IF( exists( OMCI_DATA) ) THEN
ADD( DA, <provisioned unicast addr> )
ADD( ETH_TYPE_LEN, 0xA8-C8 )
ADD( UMT_SUBTYPE, 0x04 )
ADD( VLAN0, X)
There are some difficulties integrating non-Ethernet-based protocol, such as OMCI into the Ethernet-based protocol stack. But there are a few approaches we can take:
1)
“exists( OMCI_DATA )” checks to see if the data represents OMCI data. The “exists” operator is already defined in Table 6-1. We don’t need to specify the exact mechanism used for determining that the data
is OMCI, but we do need to add a field code for that OMCI data.
2)
Another approach is to specify codes for interfaces from which the Request primitive is received {UMTSI:UMTPDU, UMTSI:OMCI, UMTSI:MA_DATA}.
If we do that, then the condition for this rule can be written as
IF( REQUEST_FROM( UMTSI:OMCI ) ) THEN …
This maybe a better approach because it also can be used for demultiplexing the received data to the above three interfaces
There are no any other egress rules, so anything that arrived from UMTSI:MA_DATA.Request primitive and that does not match a rule, is simply passed down as the MACCSI:MA_DATA.Request
primitive. This applies to all frames sourced from IP Clients X and Y. They already have their VLAN tags inserted by their respective Clients.
Now, for the RX direction we have these ingress tunnel exit rules:
1)
For OAM:
IF( DA == <local_addr> and ETH_LEN_TYPE == 0xA8-C8 and Subtype == 0x03 and exists(VLAN0) ) THEN
CHANGE( DA, SP_DA )
CHANGE( ETH_TYPE_LEN, 0x88-09 )
DELETE( VLAN0 )
INDICATION_TO( UMTSI:MA_DATA )
2)
For OMCI:
IF( DA == <local_addr> and ETH_LEN_TYPE == 0xA8-C8 and Subtype == 0x04 and exists(VLAN0) ) THEN
DELETE( DA, <provisioned unicast addr> )
DELETE( ETH_TYPE_LEN, 0xA8-C8 )
DELETE( UMT_SUBTYPE, 0x04 )
DELETE( VLAN0, X)
INDICATION_TO( UMTSI:OMCI )
Note, the above RX rules simply check for the existence of the VLAN tag (exists(VLAN0)), but do not require a specific value.
If needed, these conditions can be changed to “VLAN0==X” to verify that the VLAN value is exactly X. But I don’t think this is needed.
Again, there are no other rules that match IPv4 Ethertype 0x08-00, so all these frames simply pass through the UMT sublayer unchanged, i.e., from MACCSI:MA_DATA.Indication, they simply change
into UMTSI: MA_DATA.Indication. Per 802.1Q, the EISS Multiplex Entity then would demultiplex the received packets to their respective clients based on the value of VLAN tag. This is all done at a higher layer and out of scope for 1904.2.
I hope this helps.
-Glen
From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Sent: Friday, May 01, 2020 7:40 PM
To: Glen Kramer <glen.kramer@xxxxxxxxxxxx>;
stds-1904-2-TF@xxxxxxxxxxxxxxxxx
Cc: Curtis (CableLabs) <c.knittle@xxxxxxxxxxxxx>; Pradeep Kondamuri <pkondamu@xxxxxxxxx>
Subject: Re: VLANs and UMT Sublayer
1)
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.
2)
UMTPDU subtype is irrelevant for the example… it could be anything, but let’s make examples of OAM and OMCI.
3)
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
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