Re: [EFM] RE: OAM Proposals - a ping by any other name
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
> > > > >
> > > > >