RE: [EFM] version field in 802.3ah frame
Thanks,
Sure it helps. As you may know MEF is working on defining Eth service OAM.
My goal is to have its format as similar to 802.3ah format as possible.
Just wanted to know what is your opinion regarding the following service OAM frame format:
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| OAM Dest MAC |
+--------+--------+--------+--------+
| OAM Dest MAC | Source MAC |
+--------+--------+--------+--------+
| Source MAC |
+--------+--------+--------+--------+
| VLAN Ethertype | VLAN Tag |
| (Optional) |
+--------+--------+--------+--------+
| OAM Ethertype |version | Flag |
+--------+--------+--------+--------+
| Flag | Type | Data |
+--------+--------+--------+--------+
| Data... |
+--------+--------+--------+--------+
· OAM Destination MAC Address. The OAM destination MAC address is one of the two multicast MAC addresses reserved for Ethernet service OAM, or is the address of a specific Unicast MAC address at another ECF. Using a reserved multicast MAC address is recommended for status reports and device discovery while Unicast addressing to a specific virtual MAC is recommended for diagnostic and connectivity testing. The globally defined multicast MAC-addresses can also be used, but should be used with discretion on multipoint Trails, because many devices could be addressed by it.
· Source MAC Address. The source MAC address in the packet is the MAC address of the virtual MAC sourcing the OAM packet.
· VLAN Ethertype. The optional Ethertype, 0x8100, which may be required at the service ingress port, to select the appropriate Service/Trail when OAM is used at the Trail Level
· VLAN Tag. The optional Vlan Tag (stack), which may be required at the service ingress port to select the appropriate Service/Trail, when OAM is used at the Trail Level.
· OAM Ethertype. The OAM Ethertype is a 2-octet value. It could be one of the Ethertype values reserved for service layer OAM (to be assigned by IANA).
o Transparent OAM Ethertype. This reserved Ethertype could be used by connectivity verification, status monitoring and other end-to-end OAM functions. The property of this Ethertype is that, the node terminating the end-to-end OAM frame only uses it. All other intermediate nodes pass the frame containing this Ethertype transparently.
o Non-transparent OAM Ethertype. This reserved Ethertype could be used by Loopback, ping and Traceroute functions. The property of this Ethertype is that, every node in the path examines and possibly modifies the contents of frame containing this Ethertype. Such as TTL decrementing at every node.
· Version. The Version field identifies the OAM protocol version number. Implementations confirming to this version of the Ethernet Services OAM standard should set the value of 1 in this field. Version 1 implementations will accept packets of higher versions, if the OAM frame type is one of those specified below. It will be the responsibility of the protocol specifications of higher versions to provide backwards compatibility. This field replaces the Subtype field in IEEE Link OAM frame.
· Flags. The bits in the flags field are defined as follows:
o Bit 0 - reception-confirmed. Serves to acknowledge reception of OAM messages from the remote entity at the last 4 seconds. Serves for the hello procedure, which is described below.
· OAM Frame Type. The OAM frame type defines the type of OAM frame, where the OAM frame types are: