Re: [EFM] RE: Pause frame usage in transport networks
Ben,
You are correct on most counts.
Unfortunately, the functionality does not exist that you refer to in your
comment: "The only other way around this would be to have built a protocol
on top of the Ethernet PHY. This protocol would have an envelope for the
encoded data stream and an overhead for the service provider's OAM."
I attempted to propose something of this nature early on the "decision"
process of the 802.3 TF but it was rejected. I think, as is the case now,
that most of the people in the TF only knew about the way that "packet"
services function and were unaware of their lack of understanding of how
all other services function.
Within this TF, I believe that it is too late to go back and develop that
functionality for PHYs other than the 802.3ah copper PHY. Since "Ethernet"
is the specific domain of the 802.3 WG, it is unlikely that any other
standards body will develop that functionality.
As such, it must be recognized that for service provider support
capability, other than the copper PHY, 802.3ah is functionally limited to
"packet" services.
Thank you,
Roy Bynum
At 11:59 AM 2/21/2003 -0500, Ben Brown wrote:
>Roy,
>
>Since I am also fairly new to the transport market, I'm the most
>familiar with "packet" services. In these kinds of services, 802.3ah
>OAM would be used between the ONU and the OLT. Another kind of OAM
>would be necessary between the OLTs (SONET OAM, perhaps). The
>service provider would have to monitor all of these to understand
>the quality of the overall link.
>
>In the service you refer to as "private", the 802.3ah OAM would
>traverse the entire "link" from ONU1 to ONU2. If the "link" goes
>down or begins to deteriorate, it is up to the service provider
>to use any additional OAM operating over the network to determine
>which of the physical links is the source of the problem. That
>part of the transport network that uses a SONET type protocol
>can use SONET OAM. However, two of these physical links are the
>ONU to OLT links. If these are ethernet (if they're not, why are
>we talking about this), there is no additional OAM that can be
>operated over them. Therefore, something else must be done, e.g.
>tapping off the data stream to determine the number of coding
>violations or FCS errors. I don't know if this is considered
>illegal or not in any countries.
>
>The only other way around this would be to have built a protocol
>on top of the ethernet PHY. This protocol would have an envelope
>for the encoded data stream and an overhead for the service
>provider's OAM. Doesn't something like this already exist? Isn't
>this the reason for the huge interest these days in Ethernet over
>Sonet protocols? Perhaps this is what you were pushing for 4 years
>ago at the beginning of 10GE. There are too many PHYs that already
>exist to make these kinds of changes to them.
>
>Regards,
>Ben
>
>Roy Bynum wrote:
> >
> > Ben,
> >
> > It appears that we are starting to have some "ships in the night" effects
> > in this thread.
> >
> > From what you are saying, all your comments, including reference to
> > E.ethna would only apply to "packet" services. Since "packet" services,
> > including so called "broadband services" are relatively new and are getting
> > most of the attention of people trying to "create" a market it is
> > understandable that most people would think of only these services as a
> > market for 802.3ah.
> >
> > In reality, the long time established market, and the vast majority of the
> > bandwidth in the data communications "core" is not "packet". It would
> > behove the TF to remember that the potentially larger market for 802.3ah is
> > actually in the "private" services sector and make provisions to
> support it.
> >
> > Personally, I believe that the MAC Frame based OAM does provide end to end
> > support for the customer, but still leaves nothing for the service provider
> > for leased line services. Unlike the 10GbE WAN phy, GbE, even with 802.3ah
> > OAM still does not provide OAM support for the service provider. In this
> > respect, little has changed since I made my presentation in 1999 stating
> > the need of service provider level OAM for dark fiber and other "leased
> > line" types of Ethernet services.
> >
> > From a service provider view point, the 802.3ah OAM is only useful for
> > "packet" services, which in many cases already have other "in band"
> > management capabilities in their existing capital equipment. I would begin
> > to question why, in this age of shrinking capital budgets, would service
> > providers replace their existing equipment/interfaces with 802.3ah capable
> > equipment/interfaces. This goes directly to the criteria of "broad market
> > potential".
> >
> > Thank you,
> > Roy Bynum
> >
> > At 10:50 AM 2/21/2003 -0500, Ben Brown wrote:
> >
> > >Shahram,
> > >
> > >As Roy Bynum has pointed out, the "leased line" network would pass
> > >the OAM frames end to end. The "packet" networks would not. Just
> > >use the appropriate protocol based on your network type.
> > >
> > >Regards,
> > >Ben
> > >
> > >Shahram Davari wrote:
> > > >
> > > > Ben,
> > > >
> > > > > -----Original Message-----
> > > > > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > > > > Sent: Friday, February 21, 2003 10:27 AM
> > > > > To: Shahram Davari
> > > > > Cc: 'Siamack Ayandeh'; Roy Bynum; Geoff Thompson; mattsquire@xxxxxxx;
> > > > > Chau Chak; stds-802-3-efm@ieee.org
> > > > > Subject: Re: [EFM] RE: Pause frame usage in transport networks
> > > > >
> > > > >
> > > > >
> > > > > Shahram,
> > > > >
> > > > > OAM is a link specific protocol.
> > > > > If a customer wants to check
> > > > > connectivity within his private network and there are multiple
> > > > > links with switches between his end stations, he would not use
> > > > > OAM.
> > > >
> > > > But if a customer is buying a leased-line or private-line service (like
> > > EOS),
> > > > he expects the service behave like a single link for him. So he should
> > > > be able to run 802.3ah OAM between its sites. Note that I am not
> talking
> > > > about switched services, I am talking about pure point-to-point
> services.
> > > >
> > > > This same thing would apply to an access/transport network
> > > > > that has multiple links. You have to use a higher layer protocol,
> > > > > something that is not link specific.
> > > >
> > > > Agree.
> > > >
> > > > Yours,
> > > > -Shahram
> > > >
> > > > >
> > > > > Regards,
> > > > > Ben
> > > > >
> > > > > Shahram Davari wrote:
> > > > > >
> > > > > > Hi Siamak,
> > > > > >
> > > > > > What should a customer do if he wants to check the
> > > > > connectivity between his sites?
> > > > > > You need to be able to pass OAM frames through the core.
> > > > > >
> > > > > > -Shahram
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Siamack Ayandeh [mailto:sayandeh@xxxxxxx]
> > > > > > > Sent: Thursday, February 20, 2003 10:30 PM
> > > > > > > To: Shahram Davari
> > > > > > > Cc: Roy Bynum; Ben Brown; Geoff Thompson; mattsquire@xxxxxxx;
> > > > > > > Chau Chak;
> > > > > > > stds-802-3-efm@ieee.org
> > > > > > > Subject: Re: [EFM] RE: Pause frame usage in transport networks
> > > > > > >
> > > > > > >
> > > > > > > Sharam, So its settled then.
> > > > > > >
> > > > > > > Siamack
> > > > > > > P.S. you never mentioned what OAM function needs to be sent
> > > > > > > beyond OLT. Why
> > > > > > > for example the far side may be interested in BER of the
> > > > > near side?
> > > > > > >
> > > > > > > Shahram Davari wrote:
> > > > > > >
> > > > > > > > Siamak and all,
> > > > > > > >
> > > > > > > > I was just talking to a major carrier and in their initial
> > > > > > > deployment
> > > > > > > > of EOS they are relying on customer shaping/rate limiting.
> > > > > > > They don't send
> > > > > > > > any PAUSE at all.
> > > > > > > >
> > > > > > > > Yours,
> > > > > > > > Shahram
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Shahram Davari
> > > > > > > > > Sent: Thursday, February 20, 2003 2:21 PM
> > > > > > > > > To: 'Siamack Ayandeh'; Roy Bynum
> > > > > > > > > Cc: Ben Brown; Geoff Thompson; mattsquire@xxxxxxx; Chau Chak;
> > > > > > > > > stds-802-3-efm@ieee.org
> > > > > > > > > Subject: [EFM] RE: Pause frame usage in transport networks
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Siamak and all,
> > > > > > > > >
> > > > > > > > > Thanks for starting discussion on my original question.
> > > > > > > > > But my original question was more related to 802.3ah OAM.
> > > > > > > > > Do you think that the OLT should terminate 802.3ah OAM
> > > > > > > > > frames received from ONU?
> > > > > > > > >
> > > > > > > > > Please see some comments in-line.
> > > > > > > > >
> > > > > > > > > Yours,
> > > > > > > > > -Shahram
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Siamack Ayandeh [mailto:sayandeh@xxxxxxx]
> > > > > > > > > > Sent: Thursday, February 20, 2003 10:49 AM
> > > > > > > > > > To: Roy Bynum
> > > > > > > > > > Cc: Ben Brown; Geoff Thompson; mattsquire@xxxxxxx; Shahram
> > > > > > > > > > Davari; Chau
> > > > > > > > > > Chak; stds-802-3-efm@ieee.org
> > > > > > > > > > Subject: Re: Pause frame usage in transport networks
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Roy,
> > > > > > > > > >
> > > > > > > > > > I suggest that we shy away from generalizations that arise
> > > > > > > > > > from a broad brush
> > > > > > > > > > discussion. I made very specific comments on the
> > > > > mailing list
> > > > > > > > > > and would be happy to
> > > > > > > > > > discuss specifics. Here is a brief summary (Please
> > > > > note that
> > > > > > > > > > discussion was
> > > > > > > > > > focused on EoS for Ethernet Private Line type services. So
> > > > > > > > > > both ends of the service
> > > > > > > > > > would have the same traffic parameters. More
> > > > > involved service
> > > > > > > > > > definitions were not
> > > > > > > > > > part of this discussion):
> > > > > > > > > >
> > > > > > > > > > 1. Network to subscriber Pause has advantages over
> > > > > shaping at
> > > > > > > > > > subscriber
> > > > > > > > >
> > > > > > > > > I wouldn't call it advantage. I think both are
> > > > > > > acceptable. In one case
> > > > > > > > > the ONU drops packet while in other case the OLT.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > 2. Subscriber to network Pause is UNlikely to be invoked as
> > > > > > > > > > most often the backbone
> > > > > > > > > > link is the bottleneck. However if it does network would
> > > > > > > > > > buffer and subsequently
> > > > > > > > > > drop packets.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Agree. The link BW is usually more than the SONET VC. Besides
> > > > > > > > > OLT can't
> > > > > > > > > back pressure the SONET.
> > > > > > > > >
> > > > > > > > > >Sending Pause to the far end is not practical
> > > > > > > > > > as it would require
> > > > > > > > > > large buffers to absorb the wide area round trip delays.
> > > > > > > > >
> > > > > > > > > We have heard some customers requiring this
> functionality. The
> > > > > > > > > problem is, how can we have both ONU-OLT pause and
> > > > > ONU-ONU pause?
> > > > > > > > >
> > > > > > > > > > 3. Pause would not interfere with OAM, if anything it
> avoids
> > > > > > > > > > loss of OAM frames and
> > > > > > > > > > the resulting time outs.
> > > > > > > > >
> > > > > > > > > Actually if you read 802.3ah section 55.1.6.3 it says that
> > > > > > > > > PAUSE frames
> > > > > > > > > may delay/prevent signaling of critical events. I think the
> > > > > > > > > reason is that
> > > > > > > > > PAUSE frames are treated the same as user MAC frames.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards, Siamack
> > > > > > > > > >
> > > > > > > > > > Roy Bynum wrote:
> > > > > > > > > >
> > > > > > > > > > > Ben, Siamack,
> > > > > > > > > > >
> > > > > > > > > > > In these comments I am seeing the movement toward an link
> > > > > > > > > > facility that can
> > > > > > > > > > > be labeled as "Ethernet", but has little or none of
> > > > > > > the inherent
> > > > > > > > > > > characteristics of reliability and low latency variance.
> > > > > > > > > > Any Ethernet
> > > > > > > > > > > service that claims to be full duplex, but drops frames
> > > > > > > > > > without generating
> > > > > > > > > > > a "collision" when congested will fail meet the basic
> > > > > > > reliability
> > > > > > > > > > > characteristic of any 802.3 standard that I am aware of.
> > > > > > > > > > This is NOT Ethernet.
> > > > > > > > > > >
> > > > > > > > > > > The ONU should be allowed to "pause" the GFP/OLT
> > > > > on any one
> > > > > > > > > > link, and the
> > > > > > > > > > > GFP/OLT, should be allowed to "pause" the ONU on any one
> > > > > > > > > > link. With proper
> > > > > > > > > > > configuration of the operands, an ONU at one end of
> an end
> > > > > > > > > > to end "link"
> > > > > > > > > > > should be able to "pause" the ONU at the other end.
> > > > > > > Without that
> > > > > > > > > > > capability, what is being defined is no more reliable
> that
> > > > > > > > > > what exists
> > > > > > > > > > > today, and is some respects is less reliable than the
> > > > > > > alternative.
> > > > > > > > > > >
> > > > > > > > > > > When an end to end link starts "dropping" frames, the
> data
> > > > > > > > > > packets get
> > > > > > > > > > > retransmitted in new frames which now adds to the
> > > > > > > > > > congestion of a link and
> > > > > > > > > > > thus lowers the effective access bandwidth that can be
> > > > > > > > > > utilized. This has
> > > > > > > > > > > the effect of lowering the effective committed
> > > > > > > > > information rate even
> > > > > > > > > > > more. This is one of the primary reasons that
> experienced
> > > > > > > > > > WAN networking
> > > > > > > > > > > architects design IP networks to run as a nominal 30%
> > > > > > > > > > utilization. (I
> > > > > > > > > > > remember reading something by David Boggs about ~30%
> > > > > > > > > > utilization being the
> > > > > > > > > > > effective performance ceiling of congestion domain
> > > > > > > > > > networks. I turns out
> > > > > > > > > > > that he knew what he was talking about.)
> > > > > > > > > > >
> > > > > > > > > > > The current defined X.86/OLT does make use of "pause"
> > > > > > > > > > functionality, and
> > > > > > > > > > > will allow an ONU at one end of an end to end link
> "pause"
> > > > > > > > > > the ONU at the
> > > > > > > > > > > other end. By properly use of active flow control,
> > > > > > > the service
> > > > > > > > > > > communications link can perform as a non-congestion
> domain
> > > > > > > > > > link. With
> > > > > > > > > > > properly configured operands at the ONUs, this would be
> > > > > > > > > > highly reliable at
> > > > > > > > > > > the cost of lower predetermined bandwidth
> > > > > > > utilization, but without
> > > > > > > > > > > retransmissions. In experiments performed in the
> > > > > 1998-2000
> > > > > > > > > > time frame,
> > > > > > > > > > > effective utilization was found to be a direct ratio of
> > > > > > > > > > link/circuit speed
> > > > > > > > > > > to distance (I am having to write this from memory
> because
> > > > > > > > > > I no longer have
> > > > > > > > > > > access to the data.) Properly configured use of active
> > > > > > > > > > flow control can
> > > > > > > > > > > allow architecture designs with much higher effective
> > > > > > > > > > bandwidth utilization
> > > > > > > > > > > than 30%.
> > > > > > > > > > >
> > > > > > > > > > > Thank you,
> > > > > > > > > > > Roy Bynum
> > > > > > > > > > >
> > > > > > > > > > > At 10:15 PM 2/18/2003 -0500, 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@ieee
> .org
> > > > > > > > > > > > > > > > > > >+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@ieee
> .org
> > > > > > > > > > > > > > > > > > >+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
>-----------------------------------------