Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-10GEPON] Discussion of the liaison from ITU Q2/15 regarding P2P optical access links



All,

To answer Jeff’s question: I believe that the proposed application of the OAM extension messages is indeed aiming at just carrying the OMCI datagrams over the link.  This seemed to fit, given that the OMCI carries OAM information, and the extension mechanism is sitting right there...  But, since this is a slow protocol, we inherit the 10 frame limit (except for this link critical thing.) 

 

To Jeff’s third point, there are many ways that the OMCI information could be carried over the point to point Ethernet link… Just from a purely practical viewpoint, nearly any field in the Ethernet frame could be used as a multiplexing method: MAC address, Ethertype, Slow-protocol type, OAM-sub-type, LLID (for EPON), or whatever… But, what the decision comes down to is what method “fits best” with the overall architecture, and that is a subjective question.  I would be interested to hear more opinions on this matter.  

 

Actually, here is a different question I just thought about: OAM is a slow protocol, right? So, it is supposed to live within the restrictions of the slow protocol.  But, the link critical behavior would seem to enable the OAM protocol to violate the 10 frames per second restriction.  How can this be allowed?  

 

If such “bending of the rules” is allowed, then would it be possible to define a similarly bent “Slow protocol for OMCI” that is not so slow?  J

 

In reality, the 10 frames per second rule is not relevant for the systems that we are talking about here ? so all of this is really just window-dressing.

I think we should keep that in mind.

 

Sincerely,

Frank E.

 

 


From: Jeff Mandin [mailto:Jeff_Mandin@xxxxxxxxxxxxxx]
Sent: Sunday, February 22, 2009 3:18 AM
To: Frank Effenberger
Cc: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx; STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: RE: [8023-10GEPON] Discussion of the liaison from ITU Q2/15 regarding P2P optical access links

 

Frank hi,

 

1.  I agree with Mr. Yokomoto's characterization of the alarm issue.  More specifically:

 

    *  The "critical" parameter in figure 57-6 is explicity associated with the 3 OAM events/PDUs that are listed in 57.2.10.1. 

    *  These events are generated by the control entity depicted in 57.3 and not by an OAM client

 

Consequently using the "critical" parameter together w/ OMCI alarms would unavoidably entail a modification to clause 57.

 

2.  It would be helpful to receive clarification on what aspects of OAM are of benefit to Q2/15. Is there a desire to use features such as Discovery, remote loopback, active/passive mode etc.?  Or Is OAM merely a way of encapsulating the OMCI messages? 

 

3.  If the latter, then an alternative approach is to simply define OMCI as a management application above the MAC layer (ie. parallel to OAM rather than on top of it).  To do this it is likely sufficient to define only an ethertype and encapsulation format. 

 

Regards,

- Jeff Mandin

 


From: Frank Effenberger [mailto:feffenberger@xxxxxxxxxx]
Sent: Wednesday, February 18, 2009 7:03 PM
To: STDS-802-3-10GEPON@xxxxxxxxxxxxxxxxx
Subject: [8023-10GEPON] Discussion of the liaison from ITU Q2/15 regarding P2P optical access links

Dear All,

 

The 802.3 group received a liaison from Q2/15 in the past month.  Please see: http://www.ieee802.org/3/minutes/mar09/0309_ITU_SG15_to_802_3_LS16.pdf

 

I wanted to initiate an Email discussion of this liaison, because it asks a question that we should try to answer.  

 

Specifically, the issue is presented in the following passage from the liaison:  

“On the issue of OAM specification, our basic approach is to implement a higher layer management channel based on the “ONU management and control interface (OMCI)” recommendations (G.984.4).  The key issue here is how to carry the OMCI messages across the GbE link.  Various alternatives have been considered, and the Slow Protocols channel was one possibility.  However, we have identified a possible issue that requires clarification, explained as follows:

One of the functions of the OMCI channel is to carry alarms from the ONU to the OLT.  Many of these alarms are time critical, and should be delivered as fast as possible.  The first reading of the slow protocols channel suggests that there is a restriction of 10 frames per second, which may be limiting.  But, on closer examination, we find that in the state diagram of the OAM Transmit mechanism (Fig.57-6 in clause 57.3.2.2.4), it seems that link critical events do not decrement the pdu_cnt variable, and therefore do not count against the 10 frames per second limit.  If we could characterize our alarm messages as link critical events, then it seems that this potential issue is resolved.  We would like to confirm the appropriateness of this characterization of alarms messages as critical link events.”

 

The 802.3av group reviewed the liaison at the January interim.   

 

In the 802.3av group, I recall two basic opinions:

1)     Sure, you can call your alarms critical, if you want…  Nobody is going to stop you.  

2)     This question should be formulated as a request for interpretation, and input into that process.

That is where we left it. 

 

 

Just today, I received a side-communication from Mr. Tetsuya Yokomoto, who mentioned the following:

This is Tetsuya Yokomoto of Fujitsu. I would like to show my interpretation regarding this matter.

With respect to OMCI over OAM/Ethernet, ideally it's better to use the Organization Specific OAMPDU (Code field = 0xFE) with the Critical event flag set (Flags field bit2 = 1) to convey an OMCI on the Ethernet frame.

According to IEEE 802.3-2008 document, however, a critical event shall use an Information OAMPDU (Code field = 0x00), not an Organization Specific OAM PDU.

Sub-clause 57.2.5.1.2 says that the indications corresponding to Flags field bits 2:0 are contained in the OAM_CTL.request service primitive, which means the Critical event has to be generated from an OAM_CTL.request.

But in sub-clause 57.2.5.3.2 and 57.3.2.2.6 (or 57.7.3.1 OFS7), the OAM_ CTL.request with the local_critical_event parameter set should cause a transmission of an Information OAMPDU with the Critical Event bit of the Flags field set, not an Organization Specific OAMPDU.

I think that ITU-T can either go with an Information OAMPDU to convey an OMCI (, which seems to me kind of unnatural though,) or ask IEEE to modify 802.3 standard to allow the critical event to be transmitted on an Organization Specific OAMPDU.

So, that is additional food for thought. 

 

In my own opinion, I think that as long as a proposed behavior is not forbidden and does no harm, it can be allowed.  And, the particular application we are talking about here would be for a specific link-type (P2P GbE optical access links) and the OAM messages are link-local, so it has a controlled scope.  I don’t think it could ever result in an interoperability issue.    

 

I encourage all interested parties to comment on this matter, so we can get all views on the table. 

 

Thank you for your time.   

 

Sincerely,

Dr. Frank J. Effenberger      弗兰克 埃芬博格

Huawei Technologies USA

1700 Alma Drive, Plano TX 75075

Cell (908) 670 3889

Office/Home (732) 625 3001