Re: [EFM] RE: OAM Proposals - a ping by any other name
Roy,
I sincerely thank you for the excellent educational material. Let's get
cracking on EFM OAM now.
Best Regards,
Rich
--
Roy Bynum wrote:
>
> Rich,
>
> There are two structures of what is and is not part of the customer payload
> bandwidth. Leased Circuit services have one definition and implementation
> standard. Packet services have an entirely different definition and
> implementation standard. My perception is that you are applying the Packet
> services definition and implementation standard to everything.
>
> For packet services, only the datagram content of the customers data is
> considered to belong to the customer. The contents of the datagram headers
> can be modified by service provider as needed relative to the services
> definition and implementation standard. Also, and bits in the un-encoded
> data stream that are not customer datagram can be used by the service
> provider as needed, often as service management traffic. In this services
> application, the IPG, Preamble, SFD can be considered and not belonging to
> the customer payload bandwidth. Of course, this will require a
> redefinition of what is and is not paid for by customers when it comes to
> selling this service to customers. A GbE service can may not be able to
> charged for at a 1000Mbps rate. It gets real complicated sometimes. Take
> a look at Frame Relay service implementations and practices.
>
> The standard for Leased Circuit services (often called "Private Line") is
> very different from Packet services. Every bit that is encoded with the
> customer datagram is part of the customer payload bandwidth. The standard
> states that the customer has exclusive use of the "circuit", which also
> includes the encoding of the customer data.
>
> I believe that there may also be a confusion about what is and is not part
> of the data link function from a data transmission services standards
> viewpoint. The encoding of the customer data, not the content of the
> encoding, not the frames only within the encoding, is part of the data link
> layer function of a data transmission service. I repeat, the encoding of
> the customer data is a data link layer function from a data transmission
> service standards viewpoint. That means from the standards that the
> service providers put in place and use as a basis for the leased service
> (Private Line) service contracts, the encoding of the customer data is part
> of the customer payload bandwidth. That means that the IPG, Preamble,SFD,
> and the Frames, all of which are defined as being part of Ethernet
> bandwidth, are all part of the customer payload bandwidth.
>
> To use as an example, for leased circuit services, except at the customer
> end points, the Path Payload is not un-encoded all of the way through a
> SONET transmission network. The Line, Section overheads are encoded
> separately from the Path Payload and overhead, and the Path Payload and
> overhead are maintained separately because in current usage, the Path
> Payload generally has a B8ZS encoding and the overhead does not. The B8ZS
> is not decoded anywhere in the service provider transmission network for
> any reason other than for law enforcement reasons.
>
> While you are correct as far as Packet services are concerned. You are not
> correct as far as leased circuit Private Line services are concerned.
>
> Thank you,
> Roy Bynum
>
> At 08:20 PM 4/30/2002 -0700, Rich Taborek wrote:
>
> >Roy,
> >
> >OAMinP as architected in the OAM Baseline proposal does not use ANY
> >customer payload bandwidth whatsoever, none, zilch, zero.
> >
> >Your argument seems to be with deleting IPG, delimiters, preamble, etc.
> >since that detracts from customer payload bandwidth. You may as well go
> >pound salt with that one. I'll wager that Ethernet will do away with
> >these mechanism as soon as SONET gets rid of its overhead.
> >
> >Other mappings, such as GFP, etc. have nothing to do with Ethernet.
> >However, I expect that OAM info from Ethernet would be "ccarried over"
> >to SONET, as appropriate, whenever the two networks are joined.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >Roy Bynum wrote:
> > >
> > > Martin,
> > >
> > > OAMiP is still, at best, a packet type service management technology. It
> > > will not provide the "exclusive use" of the customer payload bandwidth by
> > > the customer.
> > >
> > > There are several people that are attempting to argue this based in the
> > > idea that the PHY bandwidth does not belong to the customer. The problem
> > > with that argument is that the IPG and Preamble/SFD are included in the
> > > bandwidth of 1000BaseX and 100BaseX. The measurement of the maximum number
> > > of frames is base in the inclusion of the IPG and Preamble/SFD bits as part
> > > of the Ethernet frames when calculating the bit transfer rate of the
> > > un-encoded data. Since OAMiP is part of the un-encoded data bit transfer
> > > rate, it belongs to the customer, not the service provider.
> > >
> > > Service providers can use part of the customer un-encoded data bit transfer
> > > rate for packet type services. This is what they do with Internet services
> > > today. The best that they can do with non-packet services (in this case I
> > > am including Frame Relay as a packet service,) is replace the "inert" bits
> > > portion of the customer un-encoded data bits with other "inert" bits. By
> > > "inert" I mean not carrying any active information such as OAM that does
> > > not belong to the customer and the customer alone.
> > >
> > > Since the preamble is normally considered as "inert" it gets stripped of
> > > by private line mapping protocols such as X.86. (GFP can be problematic
> > > providing private line services because it has the ability to do OAM in the
> > > IPG/Preamble replacement.) Because any OAMiP information gets deleted
> > > without evaluation at the Ethernet/TDM interface, it is useless for this
> > > service.
> > >
> > > Attempts to market OAMiP technology for Private Line services will only
> > > cause a level of confusion in the vendor community, and problems for the
> > > service provider community. The end customers tend to be smart enough to
> > > buy what they know to be correct for their needs, not what the vendor
> > > market is pushing. The failure of the legacy free carriers is a
> > > demonstration of that. Even the next generation technology that the
> > > service providers have deployed has not paid for itself simply because
> > > there are not enough customers for it. I see stand alone OAMiP as one of
> > > those limited deployment niche technologies.
> > >
> > > Thank you,
> > > Roy Bynum
> > >
> > > At 10:38 AM 4/22/2002 -0400, Martin Nuss wrote:
> > > >Roy,
> > > >
> > > >I welcome your continued participation on this reflector! Please
> > > >continue to do so.
> > > >
> > > >The comparison with X.86 is a good one, because there is clearly OAM
> > > >functions in the service provider network (SONET/SDH), and then there is
> > > >OAM between the customer/client equipment attached to the endpoints of
> > > >the link.
> > > >
> > > >In the X.86 example, the service provider OAM is running completely
> > > >independent from the client OAMiF (the service provider probably likes
> > > >it that way).
> > > >
> > > >What we are looking for is an Ethernet OAM layer that can interoperate
> > > >and signal between an Ethernet-over-Optics network and a
> > > >Ethernet-over-SONET (X.86 or GFP) network, and provide OAM end-to-end.
> > > >After all, we can't afford to rip out installed infrastructure these
> > > >days. OAMiP should allow us to do that, and convert preamble signaling
> > > >and alarming in the Preamble to SONET/SDH signaling/alarming when the
> > > >preamble gets stripped as X.86 maps DA through FC into SONET/SDH.
> > > >
> > > >Martin
> > > >
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > >Sent: Monday, April 22, 2002 10:05 AM
> > > >To: Romascanu, Dan (Dan); bob.barrett@xxxxxxxxxxxxxxxxxx; Taborek, Rich;
> > > >Martin Nuss; Kevin.Daines@xxxxxxxxxxxxxxxxxxxx; hsuzuki@xxxxxxxxx
> > > >Cc: MSquire@xxxxxxxxxxxxxxxxxxxx; rbrand@xxxxxxxxxxxxxxxxxx
> > > >Subject: RE: OAM Proposals - a ping by any other name
> > > >
> > > >
> > > >Dan,
> > > >
> > > >What I have in mind is allowing the enterprise customer to manage his
> > > >network better over the TDM network with OAMiF. Ethernet Private Line
> > > >does
> > > >and Ethernet over MPLS should carry the customer generated Ethernet MAC
> > > >control frames, without modification, just like any other Ethernet
> > > >frames. This makes OAMiF valuable to the enterprise customer just as
> > > >much,
> > > >if not more so that to the service provider.
> > > >
> > > >Thank you,
> > > >Roy Bynum
> > > >
> > > >
> > > >At 01:10 PM 4/22/2002 +0300, Romascanu, Dan (Dan) wrote:
> > > > >Roy,
> > > > >
> > > > >I am uncertain about the scope of what you have in mind. On one side
> > > >you
> > > > >are mentioning 'remote element management' which is in line with what
> > > >is
> > > > >the scope of the EFM OAMiF proposal. On the other side you
> > > > >mention management of the high bandwidth Ethernet Private Line and
> > > > >Ethernet WAN Packet networks. This alludes in my mind to a network
> > > > >management layer that is well beyond the scope of EFM. Actually there
> > > >will
> > > > >be some discussions on this direction in the Management Area track in
> > > >the
> > > > >MEF Technical Committee meeting this week.
> > > > >
> > > > >Regards,
> > > > >
> > > > >Dan
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > > > > Sent: Sunday, April 21, 2002 6:12 AM
> > > > > > To: bob.barrett@xxxxxxxxxxxxxxxxxx; Taborek, Rich; Martin
> > > > > > Nuss; Kevin.Daines@xxxxxxxxxxxxxxxxxxxx; hsuzuki@xxxxxxxxx
> > > > > > Cc: MSquire@xxxxxxxxxxxxxxxxxxxx; Romascanu, Dan (Dan);
> > > > > > rbrand@xxxxxxxxxxxxxxxxxx
> > > > > > Subject: RE: OAM Proposals - a ping by any other name
> > > > > >
> > > > > >
> > > > > > Bob,
> > > > > >
> > > > > > If I were a service provider, network implementer, I could
> > > > > > use OAMiF to
> > > > > > provide end to end packet network support for Ethernet over MPLS as
> > > >a
> > > > > > replacement for Frame Relay. An enterprise customer can do
> > > > > > remote element
> > > > > > management over an Ethernet over SONET (X.86) leased circuit
> > > >"Private
> > > > > > Line", because the EoS X.86 protocol with transport any
> > > > > > Ethernet frames
> > > > > > that the enterprise system sends out without evaluating them,
> > > > > > including the
> > > > > > OAM MAC Control frames. A MPLS implementation that is properly
> > > >done,
> > > > > > should do the same thing and treat the Ethernet frames the
> > > > > > same that X.86
> > > > > > does. This will allow enterprise customers to better manage
> > > > > > their high
> > > > > > bandwidth Ethernet Private Line and Ethernet WAN Packet networks.
> > > > > >
> > > > > > Thank you,
> > > > > > Roy Bynum
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Strategic Marketing
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com