Inline…
Kevin, More comments/questions inline. I removed the items that are not contentious. 2. The UMT Tunnel Multiplexer block looks at the Source MAC and Destination MAC to determine the Tunnel Instance to which this frame is associated. The get_tid(SA,DA) function defined in 4.3.1.4rand used in state diagram 4-9, returns a tunnel identifier. Based on the returned TID, the UMT Tunnel Multiplexer passes the frame to the selected UMT Tunnel Adapter (there are one or more instances of the UMT Tunnel Adapter). [GK: ] I understand about the SA. But I don’t think DA can be used like this. A MAC is associated with only a single address. If MAC matched the received DA to its own address, the UMTPDU will be passed to UMT sublayer for further processing. If MAC’s address does not match, the UMTPDU will either be passed to relay entity or will be dropped.
[KN] I assume by “MAC” you mean the underlying MAC layer. Please reference Fig 4-1… UMT needs to be able to match on MAC addresses that are NOT the local station’s MAC address. I may have the diagramming or text incorrect to properly specify this, but it is a required function… for example… how would I send an OAM SDU from a management station on on Ethernet link (for example, a 1000BaseT port) across a switch to an OLT system and onto the PON and ultimately to an ONU that is not aware of UMT? I would like to simply send the UMT frame to the ONU’s MAC address and have the OLT recognize the need to snag that frame and reformat it as an OAM PDU/frame on the PON. This requires that the OLT be able to receive frames that do not have the OLT’s DA. [GK: ] If the ONU is UMT-aware, the OLT is expected to simply relay the UMTPDU to the ONU. If the ONU is UMT-unaware, the OLT is expected to locally process the UMTPDU, repackage it as plain OAMPDU and forward to the ONU.
[KN] Agreed
So, first question, how would the OLT know whether ONU is UMT-aware or not?
[KN] Discovery of UMT stations and their capabilities is not included in this draft. We must assume, as stated in relevant sections of the text, that an administrator configures the tunnels or an as-yet-unspecified automatic discovery mechanism configures the tunnels. Until now, we always assumed a straightforward rule that if the DA in a received UMTPDU matches the local MAC address, that device would terminate the tunnel and process the UMTPDU payload.
[KN] Agreed If DA does not match the local MAC address, and the receiving MAC entity is configured in a promiscuous mode, the received frame is simply passed to Bridge Relay entity and forwarded further without any additional parsing.
[KN] I am proposing that we permit the possibility that a shim be added (as depicted in Fig 4-1), similar to the way shims are described in 802.1AC and 802.1Q, that allows UMT to “see” UMT frames that have a DA other than the local station. In the past, we discussed that intermediate nodes don’t need to be UMT-aware, because they simply relay UMTPDUs by their DA addresses without any additional parsing (just like any other data frames).
[KN] I’ve purposely avoided defining and using the term “Intermediate Node” because
(1) it was a point of contention in my original proposals in 2017 (2) it isn’t needed and (3) causes confusion (as evidenced by point 1).
As far as the proposed text is concerned, there are UMT stations and non-UMT stations. With respect to this “relay” function, a UMT station can implement such a relay, and the standard should allow it, but that function is currently unspecified.
Your approach is very different, and I cannot quite put everything together yet. For example, if some ONUs are UMT-aware and some are not, I suppose the OLT would need to relay some UMTPDUs (depending on DA) and repackage others into OAMPDUs (for other DAs).
How would the OLT know what to do for different DAs? Will it be provisioned by UMT master/manager with some special UMT DA tables?
[KN] The OLT (technically a UMT relay function in a OLT system) would need to be configured manually by an administrator or by an as-yet-undefined automatic discovery mechanism.
[KN] Again, I am open to ideas. However, one requirement that I would like to not preclude is that the “relay” function be able to operate on the MAC SA/DA fields, and not an address that is embedded in the UMT data.
I am open to ideas on this.
4. The UMT User Adaptation block simply transforms the decapsulated UMT data into a format that can be consumed by the UMT User. This is an abstract and unspecified function as far as the standard is concerned. [GK: ] “UMT User” (i.e., “UMT Client”) must be outside the scope of 1904.2. Do you agree? The “UMT User Adaptation” block is shown within the same dashed box with “UMT User”. What is the significance of this grouping? Is the “UMT User Adaptation” in or out of scope for 1904.2?
[KN] The text clearly states that the UMT User (Client) and the UMT User Adaptation are out of scope.
[GK] I couldn’t find the text that either UMT User or UMT User Adaptation are out of scope. If both of these entities are out of scope, we should not separate them. Whether there is any Adaptation layer, many adaptation layers, or some other functions, for this standard it all should be considered part of UMT Client functionality, and all of it is out of scope. We should not look inside the UMT Client, no should we specify any interfaces internal to the UMT Client (UMTUAL.request and UMTUAL.indication).
The text now says that “The UMTUAL.request and UMTUAL.indication, service primitives described in this subclause are mandatory”, but does not provide any formal definitions of these primitives or their attributes.
[KN] My bad, it isn’t quite so clear…
4.2.4.1 … "Generally, interactions with the peer UMT User is out of the scope of this standard”...
4.2.4.2.1.2 … "The semantics of the primitive are implementation specific” ...
4.2.4.2.2.1 … "This primitive is specific to the UMT User protocol and is implementation specific.” …
4.2.4.2.2.2 … "The semantics of the primitive are implementation specific”
Early on I considered combining some of the blocks, but ultimately decided against it because doing so didn’t simplify the actual specification language and, in fact, seemed to make it more complex. For example, I considered using the tuple (SA, DA, UMT Subtype) to identify a tunnel. Doing so made the state diagrams an order of magnitude more complex. I also think doing this would complicate future enhancements to specify tunnel maintenance functions and tunnel discovery and automatic setup. Before deciding how to name individual functional blocks, let’s discuss if we even need them all. When each block is expanded, they all look identical inside: Parser in the Rx direction, Multiplexor in the Tx direction. This parsing and multiplexing is shown to happen to UMTPDUs 3 times: in what is currently called “UMT sublayer”, “UMT Tunnel Multiplexor” and “UMT Tunnel Adapter” (see figure below). Each Parser (demultiplexor, really) demultiplexes frames to different outputs based on a value of one or several specific fields in the received UMTPDU. So, I would like to clarify first which fields each of the three boxes operate on. This will clarify if we need them all and how to name them. There is currently already a UMT Tunnel Multiplexer, so I guess UMT PDU Multiplexer would work. The block only does PDU (frame) multiplexing, correct? So how about “UMT Multiplexer” or “UMT PDU Multiplexer”? I’m okay with this approach. What would we call the functional block that is currently labeled “UMT Sublayer”? We probably should not use the word “layer” in this case. Layers are defined in OSI reference model and there are exactly seven of them (Physical, Data Link, Network, Transport, etc.) What 802 did and what we should do as well, define sublayers for those OSI layers. For example, 802.3 split the physical layer into several sublayers: PMD, PMA, PCS, and RS. Similarly Data Link was split into MAC, MAC Control, OAM, MAC Client sublayers. We also should not use the word “system”, as it generally encompasses operations at both the transmitting end and the receiving end and includes all layers in a device. To keep the terminology and the layering model consistent with other closely-related standards, I suggest we enclose the entire UMT functionality in a sublayer called “UMT sublayer”. That will be the total thing that 1904.2 will define. Within the UMT sublayer, as it is typically done, we will define multiple “functional blocks”. These blocks, as well as their connections will be illustrated in a figure called “UMT functional block diagram”. That figure will be similar to what is now shown in Figure 4-2. UMT Layer is the entire UMT system. UMT Sublayer is a component in the UMT layer. Now that you’ve asked the question, I notice that Fig 4-1 does not make that very clear because the tunnel adapters are shown outside the UMT Layer, and the UMT Layer is not properly labeled as "UMT Layer”. In the baseline text proposal, is "UMT Layer" and "UMT Sublayer" the same thing? I see about 50 instances of UMT Sublayer and 6 instances of UMT layer. Specifically, my question is (in reference to the picture below): Are UMT Tunnel Multiplexors and UMT Tunnel Adaptors part of UMT Layer or not? They are not shown to be part of UMT Sublayer, since the UMT sublayer is shown as a separate box. Per the agreement in our meeting yesterday, I am forwarding the MS Word and PDF versions of the baseline text presented during the meeting. Please review and send comments directly to me or to the list for discussion. When commenting, please include the line number of the text for which the comment is directed and supply suggested changes to the text. Please send me comments by 17 August so I have time to update the text before the next meeting. ________________________________________________________________________
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
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
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
|