[EFM] Re: Pause frame usage in transport networks
Siamack,
Yes, this thread certainly has been busy. Thanks for tolerating
me.
Regards,
Ben
Siamack Ayandeh wrote:
>
> Ben,
>
> Thanks for the clarification. It seems that this thread is gone on for long enough and we are beginning to
> forget where we started i.e. my statement that "the SONET/SDH (OLT1-OLT2) is often the bottleneck link". So I
> try to conclude:
>
> Sorry that I don't seem to have made myself clear re persistent congestion (vs. transient). I guess if I
> explain this then we are all done:-) So here I try again.
>
> Remember the original question "Re OAM" was in the context of EoS. Then one would expect that there is an SLA
> in place. Pause frames are not going to help the subscriber to exceed its committed rate (CIR) except for
> short duration's of time (i.e. transients) that are determined by the parameters of the SLA, the service
> interface, and the size of the OLT buffer. This is however a benefit you would not have without Pause
> frames.
>
> If the subscriber is persistently exceeding its CIR, then the egress buffer at ONU absorbs the excess. Once
> that's gone, the ONU can figure out what to do (nothing to do with the network). Pause is not a remedy to
> this persistent congestion, it is simply a trigger.
>
> If you have any further comments I appreciate receiving them off the mailing list.
>
> Take care, Siamack
>
> Ben Brown wrote:
>
> > Siamack,
> >
> > I guess this is where I keep getting hung up.
> >
> > Siamack Ayandeh wrote:
> > >
> > > 3) I already said several times; Pause is not meant to solve
> > > persistent congestion.
> >
> > I fully agree. However, in the model we've described:
> >
> > ONU1 ------ OLT1/GFP ------------------- GFP/OLT2 ------ ONU2
> > Ethernet SONET Ethernet
> >
> > we're not talking about your generic ethernet link. The transport
> > portion of this link is (significantly?) slower than the 2 access
> > links. To me, this makes persistent congestion much more likely
> > than the general ethernet we're all accustomed to. So, as you've
> > said above, "Pause is not meant to solve persistent congestion."
> >
> > Regards,
> > Ben
> >
> > Siamack Ayandeh wrote:
> > >
> > > 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
> > > > -----------------------------------------
> >
> > --
> > -----------------------------------------
> > 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
-----------------------------------------