[EFM] Re: Pause frame usage in transport networks
Ben,
1) RED and its variation ought to be used when any buffer that is carrying aggregate TCP traffic is
over flowing whether at ingress or egress.
2) Shaping is static, prone to miss configuration, does not adapt to network conditions, and it needs
configuration. It may also not be available on all CPE's. The service is supposed to be Ethernet
friendly. Not "rate shaped Ethernet".
3) I already said several times; Pause is not meant to solve persistent congestion. Complexity of ONU
is a question of what device and where in the network. Gateway to a home would be different to that of
an enterprise. Even tail dropping at the subscriber has the advantage of keeping track of what's going
on. Shaping is not going to save you from losing the OAM frames at the ONU, if there is persistent
congestion. You need priority, frames need to be scheduled based on priority etc.
4) In the scenario that you describe, OAM frames would be lost at the OLT anyway since there is no room
in the buffer. And the only way of knowing about this is a time-out. Now which one is better: to Pause
for a few or tens of milliseconds or to time-out at the OAM layer? If Pause duration exceeds the
time-out which is highly unlikely then you are back to the time-out! If repeated time-outs occur then
the problem is some where else, not in the use of Pause frame.
Regards, Siamack
Ben Brown wrote:
> Siamack,
>
> The discard that's likely to happen in the OLT is a tail drop. RED
> typically requires a lot more buffering than you might see in a
> device of this type. Also, RED is often used when an egress buffer
> gets full, not an ingress buffer so an OLT might not be an appropriate
> application for RED. This helps keep the complexity of the OLT low.
>
> Whether an ONU implements rate shaping or simply responds to flow
> control (the difference is semantics and a few thousand gates),
> the ONU needs a significant amount of buffering in order to
> implement a "RED-like" algorithm to deal with the backup of
> packets. Passing that flow control back into the system is
> perhaps a less than ideal solution. However, now we're delving
> into router architectures and that's an entirely larger discussion.
>
> OAM frames originate in a sublayer above MAC Control. When the
> MAC is paused, OAM frames are paused just like data frames. To
> the MAC, there's no difference. I'm not suggesting they should
> travel from ONU1 to ONU2 across the GFP/SONET transport network.
> However, when the OLT pauses the ONU, the ONU can't even get OAM
> frames to the OLT. This is probably okay if the pause is only
> for a short amount of time and doesn't break the OAM protocol.
> If the OLT uses pause to flow control the ONU for large amounts
> of time, then the OAM protocol might break. If we recommend pause
> at all, how do we restrict it so that OAM doesn't break?
>
> MPCP is the Multi-Point Control Protocol used for Ethernet Passive
> Optical Networks (EPONs) for the Point to Multi-Point EFM links.
> These protocols are within a new MAC Control sublayer so they are
> not affected by flow control. If the OLT buffer really is full and
> the ONU sends MPCP frames, then the OLT may not be able to handle
> these frames (depending whether they use the same buffering).
> However, since the OLT tells each ONU when to transmit, presumably
> it can account for its own buffer depths. If it is full, it keeps
> all ONUs quiet...
>
> Regards,
> Ben
>
> Siamack Ayandeh wrote:
> >
> > Ben,
> >
> > I agree that flow control in this case is only to deal with speed miss match and the resulting
> > transient. For persistent congestion packets would be lost any way. As you mention there is some
> > advantage in dropping at the premise and the ability to keep track of it happening. You also
> > bring up a good point that if Pause is not supported by the OLT then some form of RED/WRED should
> > be supported. So the complexity does not go away as far as the OLT is concerned. And since not
> > all CPE's would be capable of shaping, the network would probably need the Pause capability
> > anyway.
> >
> > Re inhibiting control frames: "The PAUSE operation cannot be used to inhibit transmission of MAC
> > Control frames". So we are back full circle to the point of previous thread. Which OAM frames,
> > what do they do and why is there a need to send them across to the far side. Or is there a need?
> >
> > Re MPCP, you got me there. What is MPCP. I am not exactly up to speed on EFM. But again if its
> > anything to do we keeping the pulse of the access loop going, then it should not be inhabited.
> > Pause applies only to payload.
> >
> > Regards, Siamack
> >
> > Ben Brown wrote:
> >
> > > Siamack,
> > >
> > > You make a strong argument. I agree that the 3rd scenario is
> > > not particularly friendly. I think the 2nd scenario is the best
> > > practical solution.
> > >
> > > Flow control merely pushes the problem from the access link
> > > to inside the customer premise. If this is a business, with
> > > multiple applications being the accumulated source of the
> > > data stream, flow control from the OLT to the ONU must then
> > > propagate backwards to multiple users or parts of the network.
> > >
> > > More likely, there is a router of sorts just behind the ONU
> > > that is implementing some kind of RED algorithm (and has the
> > > capability to perform rate limiting on its uplink port) so
> > > that, rather than pushing the flow control back into the main
> > > network, random packets will be discarded so that TCP will
> > > lower the overall network usage. In this scenario, the
> > > difference between some fancy RED algorithm dropping the
> > > random packets from individual conversations vs. the OLT
> > > dropping the overflow packets from multiple streams probably
> > > isn't much. Granted, in one case the customer owns the device
> > > that is doing the discards while in the other the service
> > > provider is doing it and that may not please the customer.
> > > However, in the larger picture, I don't see much difference.
> > >
> > > Does it simply come down to a perception issue? It's okay for
> > > a customer to discard his own packets, but the service provider
> > > better not do it, even if the overall effect is the same, even
> > > if the peak burst is reduced to implement flow control vs.
> > > having the customer perform the rate limiting.
> > >
> > > Getting back to EFM:
> > > How do we resolve the issue of flow control inhibiting the
> > > exchange of OAM frames? How do we resolve the issue of flow
> > > control not inhibiting the MPCP frames?
> > >
> > > Regards,
> > > Ben
> > >
> > > Siamack Ayandeh wrote:
> > > >
> > > > Ben,
> > > >
> > > > You are right about the OLT buffer depth (BD), minus head room, as setting the maximum
> > > > burst size (MBS). Here are the three main scenarios that impact the discussion:
> > > >
> > > > 1) Subscriber responds to Pause frames: In this case there is no configuration or shaper
> > > > complexity at CPE. Bursts of up to MBS go through, and anything beyond is shaped by flow
> > > > control. No packet loss at ingress due to flow control.
> > > >
> > > > 2) Subscriber has built in shaper (no Pause support): More complexity because of CPE shaper
> > > > and need for configuration. Would work just fine under normal conditions. But if for any
> > > > reason there is a discrepancy between the configured parameters and the network, packets
> > > > would be lost. Such reasons may be misbehaving subscriber, miss configuration, faults in
> > > > network that would shrink the bandwidth on the backbone pipe, etc.
> > > >
> > > > 3) Subscriber does NOT respond to Pause frames: Performance would suffer as any bursts
> > > > beyond buffer depth (BD) result in lost packets. Lost packets mean time outs and
> > > > re-transmissions hence good put goes down. You may say that I like to live dangerously.
> > > > But for EoS the wide area pipe is fixed in bandwidth. There is no stat-muxing and its not
> > > > like that one may get away with it if the network is idle. So could we size BD to capture
> > > > the bursts. Well traces show that traffic coming out of the enterprise has a heavy tail.
> > > > Traffic coming out of homes, today, maybe. Can one get creative with buffer management,
> > > > sure you can. But it seems to me that we end up with a lossy scenario anyway.
> > > >
> > > > I have to disagree about the 3rd scenario being more reliable (argument that there is no
> > > > Pause frame to lose). If measure of reliability is probability of packet loss, then the 3rd
> > > > scenario is by far the least reliable. The probability of losing packets in scenario-3 far
> > > > exceeds the probability of losing a Pause frame.
> > > >
> > > > So it seems to me that in the balance, Pause frame is a useful mechanism. Whether it is
> > > > activated is left to configuration. However I expect it from my Service Provider or I will
> > > > vote with my feet.
> > > >
> > > > Best regards, Siamack
> > > >
> > > > Ben Brown wrote:
> > > >
> > > > > Siamack,
> > > > >
> > > > > Pause frames defeat the whole notion of peak bursts, don't they?
> > > > > Isn't the true peak burst limit the depth of the ingress buffering
> > > > > at the OLT? Once the OLT is beyond this peak limit, Pause frames
> > > > > simply limit the ONU to its agreed throughput. In fact, due to
> > > > > worst case response times, the ONU will likely be paused before
> > > > > the OLT's ingress buffer is full. If the ONU chooses to ignore
> > > > > (or loses) a Pause frame, the OLT must be capable of discarding
> > > > > frames that exceed its ingress buffer depth (buffer overflow).
> > > > >
> > > > > Pause frames can be used to smooth out an ONU's burst. So could
> > > > > a rate limiter at the output of the ONU. Either would work to
> > > > > enforce the SLA. Ultimately, the only guaranteed SLA enforcer
> > > > > is the ability to discard frames at the OLT. If you can trust
> > > > > the ONU to respond to Pause frames, why not trust it to rate
> > > > > limit its output? This is actually more reliable because you
> > > > > don't have to worry about a Pause frame getting lost due to
> > > > > a network error.
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > Siamack Ayandeh wrote:
> > > > > >
> > > > > > Ben,
> > > > > >
> > > > > > Please see my comments interleaved.
> > > > > >
> > > > > > Regards, Siamack
> > > > > >
> > > > > > Ben Brown wrote:
> > > > > >
> > > > > > > Siamack,
> > > > > > >
> > > > > > > This comment is way off track of the original question but I
> > > > > > > feel a need to ask this question. That's why I changed the
> > > > > > > subject. I'll even redraw the network so that we're all using
> > > > > > > the same context.
> > > > > > >
> > > > > > > ONU1 ------ OLT1/GFP ------------------- GFP/OLT2 ------ ONU2
> > > > > > > Ethernet SONET Ethernet
> > > > > > >
> > > > > > > Why are Pause frames used on the Ethernet links? The ONU should
> > > > > > > never be allowed to Pause the OLT as that would back-pressure
> > > > > > > the entire WAN. Since the WAN doesn't support back-pressure,
> > > > > > > packets over the SONET link that exceed the OLT's egress buffers
> > > > > > > would wind up being dropped at the OLT.
> > > > > >
> > > > > > That's basically what I said "OLT can simply buffer and subsequently drop packets."
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The OLT could Pause the ONU but for what reason? The only reason
> > > > > > > that I can think of would be to enforce the ONU's SLA. The point
> > > > > > > of putting an SLA in place is to enforce some set of rules,
> > > > > > > usually having to do with the minimum and maximum throughput
> > > > > > > guaranteed at the OLT for the ONU. The reason an SLA needs to
> > > > > > > be in place is because each side doesn't really trust the
> > > > > > > other's "handshake" and a legal document of sorts is needed.
> > > > > > > So, if neither side "trusts" the other, why do you rely on
> > > > > > > Pause frames to enforce the SLA? If the ONU will attempt to
> > > > > > > use as much bandwidth as possible, it will likely do so by
> > > > > > > ignoring the Pause frames from the OLT. This means that the
> > > > > > > only way the OLT can truly enforce the SLA is to be able to
> > > > > > > discard the frames that exceed the bandwidth agreed to in
> > > > > > > the SLA. If the OLT is capable of this, why even bother with
> > > > > > > Pause frames?
> > > > > >
> > > > > > You forget two things:
> > > > > > 1. The bursty nature of traffic and the fact that peak is greater than the committed
> > > > > > rate of service
> > > > > > 2. That networks by definition protect themselves i.e. can not rely on subscriber
> > > > > > alone
> > > > > >
> > > > > > If the subscriber exceeds its SLA then yes, frames would be dropped. But if it's just
> > > > > > a burst, i.e. on average the subscriber is in compliance then buffering and Pause
> > > > > > should do the job.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Sorry for being long winded but I'm trying to make a logical
> > > > > > > argument. What assumptions did I make that aren't valid?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Ben
> > > > > > >
> > > > > > > Siamack Ayandeh wrote:
> > > > > > > >
> > > > > > > > Shahram,
> > > > > > > >
> > > > > > > > It would be helpful to this discussion if you indicate what you had in mind
> > > > > > > > with regard to OAM frames so one can think of a pragmatic answer. For example
> > > > > > > > if you are worried about Pause frames: In this case the SONET/SDH (OLT1-OLT2)
> > > > > > > > is often the bottleneck link. So Pause is used on the local link to protect the
> > > > > > > > OLT-1/2 buffers. If the egress ONU back pressures the network, then OLT can
> > > > > > > > simply buffer and subsequently drop packets. Otherwise fairly large buffers
> > > > > > > > would be required to absorb the round trip time of the wide area. If you think
> > > > > > > > about it as a two port bridge, again Pause is not propagated over the wide
> > > > > > > > area. If you look at various IETF Pseudowire flavors, again following the lead
> > > > > > > > of IEEE, Pause is not propagated over the wide area.
> > > > > > > >
> > > > > > > > Siamack
> > > > > > > >
> > > > > > > > Geoff Thompson wrote:
> > > > > > > >
> > > > > > > > > Matt-
> > > > > > > > >
> > > > > > > > > To further enrich the information that you provided below....
> > > > > > > > >
> > > > > > > > > 802.3 has a long, well established tradition of not supporting media
> > > > > > > > > converters.
> > > > > > > > >
> > > > > > > > > It would be my opinion that any "features" designed to specifically support
> > > > > > > > > media converters were out of scope unless they were specifically mentioned
> > > > > > > > > in the PAR.
> > > > > > > > >
> > > > > > > > > Geoff
> > > > > > > > >
> > > > > > > > > At 01:05 AM 2/12/2003 -0500, Matt Squire wrote:
> > > > > > > > >
> > > > > > > > > >My 2 cents.
> > > > > > > > > >
> > > > > > > > > >If there is a MAC layer in the ONU, then OAM terminates there. If a
> > > > > > > > > >vendor builds something without a MAC layer, then it doesn't terminate
> > > > > > > > > >there. If you put MACs in your ONU, you're really building something
> > > > > > > > > >akin to a 2-port bridge (likely with STP disabled permanently). If you
> > > > > > > > > >don't, then its more along the lines of a media converter. Both models
> > > > > > > > > >can work. Both models can interoperate. So do it anyway you want, and
> > > > > > > > > >maybe the market will agree with you.
> > > > > > > > > >
> > > > > > > > > >- Matt
> > > > > > > > > >
> > > > > > > > > >Shahram Davari wrote:
> > > > > > > > > > >
> > > > > > > > > > > Roy,
> > > > > > > > > > >
> > > > > > > > > > > Since EOS is a private line service, It seems that you agree with me
> > > > > > > > > > and Chak that for the EOS it seems from architectural point of view the
> > > > > > > > > > OAM MAC frames should not be terminated at OLTs. Is that correct?
> > > > > > > > > > >
> > > > > > > > > > > Yours,
> > > > > > > > > > > -Shahram
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > > > > > > > > > > Sent: Tuesday, February 11, 2003 12:26 PM
> > > > > > > > > > > > To: Chau, Chak; stds-802-3-efm@ieee.org
> > > > > > > > > > > > Subject: RE: [EFM] Question regarding OAM in 802.3ah D1.3
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Chak,
> > > > > > > > > > > >
> > > > > > > > > > > > Depending on the service definition and who owns the service
> > > > > > > > > > > > facilities,
> > > > > > > > > > > > end to end OAM functionality would not necessarily available. In all
> > > > > > > > > > > > packet services, the service provider would own at least a
> > > > > > > > > > > > portion, if not
> > > > > > > > > > > > all of the communications facilities. The OAM functionality
> > > > > > > > > > > > would then be
> > > > > > > > > > > > for the use of the service provider, not the customer. Only
> > > > > > > > > > > > with a Leased
> > > > > > > > > > > > Circuit type of service (also referred to as "Private Line")
> > > > > > > > > > > > would end to
> > > > > > > > > > > > end, OLT1 to OLT2 OAM functionality exist. For all other types of
> > > > > > > > > > > > services, the OAM for Link 1 would not be the OAM for Link 2.
> > > > > > > > > > > > Other than
> > > > > > > > > > > > with a Leased Circuit service, the services are defined to
> > > > > > > > > > > > alter, filter,
> > > > > > > > > > > > or drop customer originated frames/packets in one way or
> > > > > > > > > > > > another, including
> > > > > > > > > > > > the OAM frames. This is the gist of the work that is being done by
> > > > > > > > > > > > SG15/Q.10 under E.Ethna. Other than with a Leased Circuit
> > > > > > > > > > > > service, true
> > > > > > > > > > > > "transparency" does not exist.
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you,
> > > > > > > > > > > > Roy Bynum
> > > > > > > > > > > >
> > > > > > > > > > > > At 10:15 AM 2/11/2003 -0600, Chau, Chak wrote:
> > > > > > > > > > > > >Hi David and All,
> > > > > > > > > > > > >
> > > > > > > > > > > > >I though for a PtP application the OAMPDUs message should be
> > > > > > > > > > > > transparent
> > > > > > > > > > > > >form OLT1 to OLT2.
> > > > > > > > > > > > >Or else, this will defeat the purpose of PtP, i.e., no L2 frame
> > > > > > > > > > > > >processing. Which means that OAM for Link1 can be OAM for
> > > > > > > > > > > > Link2, is that
> > > > > > > > > > > > >correct? This topic may be reviewed outside of EFM if prefered.
> > > > > > > > > > > > >
> > > > > > > > > > > > >Kind Regards,
> > > > > > > > > > > > >Chak
> > > > > > > > > > > > >
> > > > > > > > > > > > >Chak Chau
> > > > > > > > > > > > >FUJITSU, Transmission Development
> > > > > > > > > > > > >Phone: (972) 479-2795
> > > > > > > > > > > > >chak.chau@xxxxxxxxxxxxxxx
> > > > > > > > > > > > >chakavuth.chau@xxxxxxxxxxxx
> > > > > > > > > > > > >-----Original Message-----
> > > > > > > > > > > > >From: David Martin [mailto:dwmartin@xxxxxxxxxxxxxxxxxx]
> > > > > > > > > > > > >Sent: Monday, February 10, 2003 2:59 PM
> > > > > > > > > > > > >To: stds-802-3-efm@ieee.org
> > > > > > > > > > > > >Subject: RE: [EFM] Question regarding OAM in 802.3ah D1.3
> > > > > > > > > > > > >
> > > > > > > > > > > > >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
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > -----------------------------------------
> > > > > > > Benjamin Brown
> > > > > > > AMCC
> > > > > > > 200 Minuteman Rd
> > > > > > > 3rd Floor
> > > > > > > Andover, MA 01810
> > > > > > > 978-247-8022 - Work
> > > > > > > 603-491-0296 - Cell
> > > > > > > 978-247-0024 - Fax
> > > > > > > 603-798-4115 - Home Office/Fax
> > > > > > > bbrown@xxxxxxxx
> > > > > > > -----------------------------------------
> > > > >
> > > > > --
> > > > > -----------------------------------------
> > > > > Benjamin Brown
> > > > > AMCC
> > > > > 200 Minuteman Rd
> > > > > 3rd Floor
> > > > > Andover, MA 01810
> > > > > 978-247-8022 - Work
> > > > > 603-491-0296 - Cell
> > > > > 978-247-0024 - Fax
> > > > > 603-798-4115 - Home Office/Fax
> > > > > bbrown@xxxxxxxx
> > > > > -----------------------------------------
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > AMCC
> > > 200 Minuteman Rd
> > > 3rd Floor
> > > Andover, MA 01810
> > > 978-247-8022 - Work
> > > 603-491-0296 - Cell
> > > 978-247-0024 - Fax
> > > 603-798-4115 - Home Office/Fax
> > > bbrown@xxxxxxxx
> > > -----------------------------------------
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 200 Minuteman Rd
> 3rd Floor
> Andover, MA 01810
> 978-247-8022 - Work
> 603-491-0296 - Cell
> 978-247-0024 - Fax
> 603-798-4115 - Home Office/Fax
> bbrown@xxxxxxxx
> -----------------------------------------
begin:vcard
n:Ayandeh;Siamack
tel;fax:781 271 9988
tel;work:781 276 4192
x-mozilla-html:FALSE
url:www.txc.com
org:Transwitch Corporation (Onex)
adr:;;34 Crosby Drive;Bedford;MA;01730;USA
version:2.1
email;internet:sayandeh@xxxxxxx
title:Senior Consulting Engineer
end:vcard