RE: [EFM] Question regarding OAM in 802.3ah D1.3
David,
Since I was involved with the development of X.86, and attempted to prevent
many of the issues regarding the termination of the OAMPMUs for services
like "Private Line", I would like to be part of this conversation. I
believe that it is also pertinent to the usefulness of EFM in the industry
and would apply to the overall broad market application of the standard.
Thank you,
Roy Bynum
At 03:59 PM 2/10/2003 -0500, David Martin wrote:
>Shahram,
>
>
>
>Agreed, the EoS (e.g. GFP-F) mapping is a simple port-to-port mapping and
>doesn't include the full MAC sublayer processing (i.e. only terminates
>IPG, preamble, SFD). Inspecting the MAC DA and filtering off EFM OAMPDUs
>and processing them is required by the network application, since the
>Ethernet link / PHY to which they apply is terminated. OAM for link 1
>cannot be mixed with OAM for link 2 on the other side of the provider's
>network.
>
>
>
>ONU1 -------------- OLT1/GFP------------------ GFP/OLT2 ------------ ONU2
>
> Ethernet SONET Ethernet
>
>
>
>It might be more appropriate to continue this privately, or on the Q.12/15
>reflector.
>
>
>
>...Dave
>
>David W. Martin
>Nortel Networks
><mailto:dwmartin@xxxxxxxx>dwmartin@xxxxxxxx
>+1 613 765-2901 (esn 395)
>~~~~~~~~~~~~~~~~~~~~
>
>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@xxxxxxxxxxxxxx]
>Sent: Monday, February 10, 2003 3:16 PM
>To: Martin, David [SKY:QW10:EXCH]; stds-802-3-efm@ieee.org
>Subject: RE: [EFM] Question regarding OAM in 802.3ah D1.3
>
>
>
>David,
>
>
>
>I like to agree with you, but from layering architectural point of view,
>the EOS box does not have to implement MAC
>
>layer (i.e., do any MAC lookup), rather a P-2-P EOS is a kind of port
>transport in which all traffic coming form an Ethernet port are send over
>a specific SONET channel.
>
>
>
>Please see further comments in-line:
>
>
>
>Thanks,
>
>-Shahram
>-----Original Message-----
>From: David Martin [mailto:dwmartin@xxxxxxxxxxxxxxxxxx]
>Sent: Monday, February 10, 2003 3:00 PM
>To: stds-802-3-efm@ieee.org
>Subject: RE: [EFM] Question regarding OAM in 802.3ah D1.3
>Shahram,
>
>This question is somewhat out of scope wrt EFM, but the answer is yes, the
>EFM OAMPDU flow must be terminated at the Provider Edge. Otherwise it
>would flow through the provider's SONET network and get mixed in with a
>separate EFM OAMPDU flow at the far end.
>
>
>SD=> Which separate OAMPDU flow? do you mean from ONU2 to OLT2?
>
>
> Note that you have the terms ONU / OLT reversed.
>
>
>So the ONU is the customer side?
>
>This "filter function" is being defined in the ITU-T SG15 / Q.12 work in
>draft G.ethna (was G.etna) and in the OIF UNI v2.
>
>
>Thanks I will have a look.
>
>The PE-PE, or SONET portion is not an EFM link, but rather a SONET path,
>which has its own OAM (i.e. POH).
>
>
>Agree.
>
>
>...Dave
>David W. Martin
>Nortel Networks
><mailto:dwmartin@xxxxxxxx>dwmartin@xxxxxxxx
>+1 613 765-2901 (esn 395)
>~~~~~~~~~~~~~~~~~~~~
>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@xxxxxxxxxxxxxx]
>Sent: Monday, February 10, 2003 2:13 PM
>To: stds-802-3-efm@ieee.org
>Subject: [EFM] Question regarding OAM in 802.3ah D1.3
>
>
>Hi,
>
>
>802.3ah section 57 says that the OAM defined is for single link (or
>emulated link), and should not be forwarded by bridges/switches.
>
>
>My question is, in case of Ethernet over SONET transport (GFP + Virtual
>concatenation), should the OAMPDU be terminated at the EOS device or it
>should be transparently transported?
>
>
>Consider this example:
>
>
>
>
>OLT1 -------------- ONU 1------------------ ONU 2 ------------ OLT 2
> Ethernet SONET Ethernet
>
>
>
>
>Assume OLT1 and OLT2 are the customer equipments and ONU1 and ONU2 are
>provider
>transport equipments that transport Ethernet over SONET (but don't do any
>switching/bridging).
>
>
>In this case should ONU1 terminate OAMPDUs from OLT1 or it should sent
>them transparently to OLT2?
>In other words is OLT1--ONU1 considered a single link? what about ONU1 to
>ONU2, is this also a link?
>
>
>Thanks in advance,
>Shahram Davari
>Senior Product Research Engineer
>R&D Research Ottawa
>PMC-Sierra, Inc.
>Phone: (613) 271-4018
>Fax: (613) 271-6468
>