| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Marek, In the diagram, the OAM client has two inputs: one when the OAM payload was received in an OAMPDU, another one is when it was received in an UMTPDU.
The OAM client also has two outputs, one for OAMPDU, another for UMTPDU. The idea is that if the request was received in UMTPDU, the response should go in UMTPDU as well, and similarly if the request came in
OAMPDU, the response should go in OAMPDU. But the OAM client just deals with payload, and does not know how the payload was transported. So, the issue is that after the OAM client has generated a response, how does it know where to send it?
The IP client has the same issue. Some frames may arrive as IP over Ethernet frames , some frames may arrive as IP over UMT over Ethernet. The IP client does not know where to send the response. Glen From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Glen, I looked at the diagram and I cannot really pinpoint what you believe is wrong with it at this time. Are any functions missing ? Marek From: stds-1904-2-tf@xxxxxxxx [mailto:stds-1904-2-tf@xxxxxxxx]
On Behalf Of Glen Kramer Dear 1904.2 members, At the last meeting, I had an action item to redraw the UMT layering diagram. As a reminder, the diagram we discussed in Amsterdam is shown here:
http://www.ieee1904.org/2/meeting_archive/2014/08/tf2_1408_kramer_1.pdf Per the action item, the following changes were required: 1)
Show generic MAC Forwarding instead of UMT-specific MAC forwarding 2)
For TR-069 show IP client 3)
Show LLC layer similar to how it is shown in 802.1Q. Attached is the updated diagram (visio and pdf). It still has issues, I think. I would like to discuss it now, so that if there are any suggestions, I can implement them before the meeting. Please, ask questions and/or provide your feedback. Thank you, Glen |