Re: [EFM] RE: OAM Proposals - a ping by any other name
Jean-Lou,
There are four data transmission services defined in the international
standards. Two of the services defined have the service provider
functionality inside the encoded bit stream (PCS encoding is the 802.3
equivalent.) with the customer frames/packets. Two of the services defined
have the service provider functionality outside of the encoded bit stream
that contain the customer frames/packets.
The two services that include the service provider functionality inside the
data link encoding are Frame Relay and Packet. Frame Relay has a specific
frame format protocol definition that is different from 802.3. Packet
services can include everything from IP, SNA, HDLC, SDLC, Bisync, etc.
The two services that do not have service provider functionality inside the
data link (PCS) encoding are leased circuit (Also called Private Line.) and
switched circuit. In the UK, they are so serious about the service
provider functionality being outside the encoded revenue data bit stream
that they implement separate copper/fiber facilities to carry the OAM. In
North America, the service providers use a separate and different encoding
to segregate the encoded revenue data bit stream facilities from the
service provider OAM facilities.
The currently accepted baseline for OAM has the service provider
functionality inside the revenue data bit stream encoding. Since 802.3ah
is not defining a new form of Frame Relay, it will have settle on Packet
services. This is all that I have been trying to get everyone to understand.
Thank you,
Roy Bynum
At 10:48 AM 5/1/2002 -0400, jeanlou.dupont@xxxxxxxxxxx wrote:
>Thanks for the reply.
>
>I think I understand better your position and acknowledge the discrepancies
>between the two perceptions at play here.
>
>I guess I come in from the following angle:
>- EFM is defining new stuff at two layers:
> - layer 1 (Phy)
> - layer 2 (Data Link)
>- Anything that has value must be managed or else it doesn't carry value.
>Value is managed. Hence, each layer must be managed.
>- Each layer provides its own unique set of functions to contribute value.
>- Each layer thus should contain management overhead to ensure
>manageability.
>- Each layer is allowed its own form of management overhead.
>- Each layer should have its management overhead separate from other
>layers.
>
>I still believe that layer 1 management functions should stick at layer 1.
>Much cleaner model. As far as the service is concerned, if it is a layer 2
>based service, let it be managed using layer 2 semantics.
>
>I guess this model upsets folks who like using packets as "jack of all
>trades"...
>
>thanks again and regards,
>jld.
>
>
>
>
>
>Roy Bynum <rabynum@xxxxxxxxxxxxxx> on 05/01/2002 10:04:02 AM
>
>To: jeanlou.dupont@xxxxxxxxxxx
>cc: rtaborek@xxxxxxxxxxxxx
>Subject: Re: [EFM] RE: OAM Proposals - a ping by any other name
>
>Jean-Lou,
>
>The simple premise that from a data transport services standards
>definition, the encoding of the transmitted data is part of the data link
>layer, not the physical layer breaks every one of your arguments.
>
>The fact that IEEE looks at the encoding as a physical layer function while
>transmission services look at it as a data link function creates a
>distinction. If P802.3ah is trying to define a subscription network OAM
>function that meets current data transmission services standards then it
>has to recognize that distinction in order to recognize what and what is
>not part of the "customer payload bandwidth". (The ironic thing is that
>"customer payload bandwidth" is a marketing term, not part of the data
>transmission services standards.)
>
>I am simply trying to get people to recognize where the different forms of
>OAM proposals fall within the international data transmission services
>standards.
>
>Thank you,
>Roy Bynum
>
>At 09:34 AM 5/1/2002 -0400, jeanlou.dupont@xxxxxxxxxxx wrote:
>
> >Roy;
> >
> >I have been monitoring this mailing list for quite some time now. I have
> >seen also some of your interventions on other mailing lists (probably
> >MPLS). I think you are a very pragmatic and reasonable man. But, as far as
> >this thread is concerned, I fail to understand your logic.
> >
> >Goal for EFM: devise a carrier grade layer 1 for Ethernet.
> >
> >Facts:
> >- Ethernet is defined with a physical layer (layer 1 in the OSI reference
> >model);
> >- OSI Layer 1 entities contain overhead for OAM purposes;
> >- Ethernet, as defined by IEEE, doesn't contain much OAM like the one
>found
> >in carrier grade transport layer 1 (SONET/SDH, PDH)
> >- IPG, Preamble & SFD overheads are bagages carried by Ethernet from the
> >old days of CSMA/CD for coax multiple access; these are somewhat moot in
> >current technology context but we have to live with it.
> >- IPG and Preamble & SFD are always present and the customer can do
>nothing
> >about it.
> >- Ethernet over SONET/SDH (using LAPS and one mode of GFP) does not
> >transport IPG, Preamble & SFD.
> >
> >Q1: Why can't EFM use this very convenient overhead to convey layer 1 OAM
> >functions?
> >Unless there are plans to get rid of IPG, Preamble & SFD to gain the much
> >necessary BW for additional customer payload BW...
> >
> >Q2: Why go to the trouble of entering functions in the payload data-path
> >for OAM frames thus removing customer BW?
> >
> >Q3: Is it because you feel more comfortable going with overhead in frame
>in
> >case EFM "forgets" to put something in? Overhead in frame gives you
> >additional bandwidth to play with in this case?
> >There aren't tons of OAM functions required to manage a layer 1.
> >
> >Q4: Is it because you feel the management of layer 1 entities and the
> >management of the service should be part of the same overhead?
> >With Frame Relay for example (I guess you refer to this as a packet
> >service), FR is transported over T1. The physical entities are managed at
> >layer 1 in the T1 overhead. The FR packet service is managed through LMI.
> >Different layer, different management functions, different overhead in the
> >bit stream.
> >
> >
> >
> >A "change of heart" on a subject doesn't take away a man's value (I am not
> >too sure how to translate from french this statement, sorry. I hope you
>get
> >the general idea though).
> >
> >best regards,
> >Jean-Lou Dupont
> >
> >
> >
> >
> >
> >Roy Bynum <rabynum@xxxxxxxxxxxxxx>@majordomo.ieee.org on 05/01/2002
> >06:56:59 AM
> >
> >Sent by: owner-stds-802-3-efm@majordomo.ieee.org
> >
> >
> >To: rtaborek@xxxxxxxxxxxxx
> >cc: stds-802-3-efm@ieee.org
> >
> >Subject: 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
> > > > > > >
> > > > > > >