Re: [EFM] Of mice and modems
Howard,
you ask "So how can the demarcation point be a PHY device? These days, PHYs
are buried inside larger pieces of silicon. Can we really have a demarcation
point inside of a chip?"
We encountered the same problem in DSL and finally came to a solution by
defining "functional" interfaces instead physical interfaces. Functional
interfaces are not intended to provide interconnection between parts of a modem
(since a demarcation point is deeply inside of a chip, as you mentioned), but they
are important to provide interoperability between units on the two sides of the
link. For instance, functional interface describes the source of timing, whether
the timing should be octet ot bit, the data format (framing, FEC, scrambling), the
list of traffic flow control signals, whether MSB or LSB should be sent first in
serial implementation, etc. By my understanding, that is what we should do in EFM
as well. Our functional input is an Ethernet packet (data link level) at one side
of the PHY (or TC sublayer, if we refer to ATM world), and a physical interface
with the copper/fiber at the other side.
Vladimir
Howard Frazier wrote:
> >From whence came this definition of a demarc?
>
> A PHY device, in the context of 802.3, and the ISO reference model,
> has a media interface on the bottom (known as the Medium Dependent
> Interface, or MDI) and an interface to the data link layer (such as
> the MII) on top. In particular, PHY devices have only one MDI.
>
> PHY devices perform functions like signal conversion, pulse shaping,
> filtering, clock recovery, serial to parallel conversion, encoding/decoding,
> and in some cases, scrambling and Forward Error Correction. PHY devices
> are aware of packet boundaries, but not the packet contents.
>
> So how can the demarcation point be a PHY device? These days, PHYs are
> buried inside larger pieces of silicon. Can we really have a demarcation
> point inside of a chip?
>
> Okay, so maybe the model that some of us have in mind is the DSL modem,
> or DOCSIS modem, or a T1 DSU/CSU, or an ISDN terminal adapter. These
> two port devices have an interface to the access link (DSL, cable, T1,
> ISDN) on one side, and an interface to the customer's equipment
> (Ethernet, RS-422, V.35, etc) on the other side. For the sake of
> discussion, I think that it is confusing to call these devices "PHYs",
> or "demarcation points, or "demarc devices". For the sake of discussion,
> why don't we call these "modems".
>
> An EFM modem would be a two port device with an EFM port on one side (either
> opper, point to point fiber, or point to multipoint fiber), and an
> Ethernet|Fast Ethernet|Gigabit Ethernet port on the other side.
>
> You could put different levels of functionality in between the two ports.
> Some might try to build it as a layer 1 device and call it a modem or a media
> converter. Some might build it as a layer 2 device and call it a bridge.
> Some might build it as a layer 3 device and call it a router. Others might
> make it a whizbang, content-aware, caching, load balancing, encrypting,
> tunneling, firewalling, network address translating, who knows what else
> device, with VoIP and an MPEG decoder, and call it any number of catchy
> names like an Integrated Access Device, an IP Services device, or a
> Residential Gateway.
>
> It seems that the question we must deal with is whether or not we are
> going to write specifications for modems in 802.3ah. In my opinion, this
> is not what we are supposed to be doing. We're supposed to be writing
> specs for PHYs, plus minimal augmentation of the 802.3 MAC, plus far
> end OAM for subscriber access networks.
>
> Howard
>
> Bob Barrett wrote:
> >
> > Harry et al
> >
> > yup, all the IP 'stuff' is payload as far as the demarcation point is
> > concerned.
> >
> > The demarc is a PHY that carries packets at the end of the day. Some demarcs
> > may be buried inside a bigger system, however, the standard must also cater
> > for stand alone demarc devices. My expectation as a user would be that at
> > the demarc the bandwidth was the same capacity as my enterprise MAC and PHY
> > of the same spec.
> >
> > Would I miss 10k per second on a 1GE, I doubt it.
> >
> > Would my test gear pick it up on an end to end private circuit test, I don't
> > know, anyone on the reflector tried this?
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
> > > Sent: 27 September 2001 17:41
> > > To: 'fmenard@xxxxxxxxxxxxxxx'; 'Denton Gentry';
> > > bob.barrett@xxxxxxxxxxxxxxx
> > > Cc: 'stds-802-3-efm'
> > > Subject: RE: [EFM] 1 Gbps != 999.9 Mbps
> > >
> > >
> > > And how about the ICMP and IGMP traffic from the same CPE devices?
> > >
> > > Harry
> > >
> > > -----Original Message-----
> > > From: Francois Menard [mailto:fmenard@xxxxxxxxxxxxxxx]
> > > Sent: Thursday, September 27, 2001 6:05 AM
> > > To: 'Denton Gentry'; bob.barrett@xxxxxxxxxxxxxxx
> > > Cc: 'stds-802-3-efm'
> > > Subject: RE: [EFM] 1 Gbps != 999.9 Mbps
> > >
> > >
> > >
> > > Or for that matter, what about ARP traffic unsolicited from my CPE
> > > devices ?
> > >
> > > -=Francois=-
> > >
> > > -----Original Message-----
> > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of Denton
> > > Gentry
> > > Sent: September 26, 2001 3:12 PM
> > > To: bob.barrett@xxxxxxxxxxxxxxx
> > > Cc: stds-802-3-efm
> > > Subject: [EFM] 1 Gbps != 999.9 Mbps
> > >
> > >
> > >
> > > > Service providers have a desire to offer a full 1GE service and not
> > > > use any of it's bandwidth for OAM. The rule of conservation of
> > > > bandwidth means the OAM needs to go somewhere other then in the
> > > > bandwidth reserved for the 1GE payload. I take it as read that 100%
> > > > utilisation of a 1GE is unlikely, but that is not the point. The point
> > >
> > > > is that service providers want to offer 1GE service period, not a
> > > > 999.9Mbit service.
> > >
> > > Does the existence of the Mac Control PAUSE frame therefore make
> > > Ethernet unsuitable for service providers?
> > >
> > > Denton Gentry
> > > Dominet Systems