Sign in with
Sign up | Sign in
Your question

Ethernet over T1 (Ethernet over WAN...)

Last response: in Networking
Share
October 17, 2004 5:15:10 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

When we can run PPP over T1, then why cant we have Ethernet frames
transmitted over T1.

Once we have a PPP packet we would be transmitting it in DS0 channels
- we can perhaps use the same logic to transmit ethernet frames.

Comments ?

Thanks
Steve

More about : ethernet ethernet wan

Anonymous
October 17, 2004 1:58:38 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark <steven_mark_99@yahoo.com> wrote:
> When we can run PPP over T1, then why cant we have Ethernet frames
> transmitted over T1.

> Once we have a PPP packet we would be transmitting it in DS0 channels
> - we can perhaps use the same logic to transmit ethernet frames.

> Comments ?

I would suggest stripping off link headers and encapsulate the network layer
in the link layer used for your T1. There is seldom any point in
transmitting linklayers since they are used only as "containers on the
local media" and has no significance outside the site or LAN.

ppp-over ethernet is a hack that does add an authentification step unavailable
in ethernet, besides that it does not add much more then wasted bits

> Thanks
> Steve

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Anonymous
October 17, 2004 10:54:39 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:
>
> When we can run PPP over T1, then why cant we have Ethernet frames
> transmitted over T1.
>
> Once we have a PPP packet we would be transmitting it in DS0 channels
> - we can perhaps use the same logic to transmit ethernet frames.
>
> Comments ?
>
> Thanks
> Steve

Look up the function of "bridges" in the LAN environment. Nobody
sells them as such any more. Most if not all routers can be
configured for "bridging only". An old example of an
Ethernet-to-T1 Remote Bridge device would be the Retix 4800
series.

BTW, why are you channelizing your PPP into DS0's ?? Why not look
at the T-1 as a single 1.536Mb pipe ??

--reed
Related resources
October 18, 2004 12:39:20 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

phn@icke-reklam.ipsec.nu wrote in message news:<cktfoe$hq7$2@nyheter.ipsec.se>...
> Mark <steven_mark_99@yahoo.com> wrote:
> > When we can run PPP over T1, then why cant we have Ethernet frames
> > transmitted over T1.
>
> > Once we have a PPP packet we would be transmitting it in DS0 channels
> > - we can perhaps use the same logic to transmit ethernet frames.
>
> > Comments ?
>
> I would suggest stripping off link headers and encapsulate the network layer
> in the link layer used for your T1. There is seldom any point in

See thats what my question is - Why cant we use "ethernet" link layer
header on T1.

> transmitting linklayers since they are used only as "containers on the
> local media" and has no significance outside the site or LAN.

They *do* make a sense. I will give an example - Assume that a company
has offices in Chicago, Denver and New York. It runs Ethernet on its
LAN. Now, assume that there is a lot of interoffice transaction.
Wouldnt it be good to consider all these physically separate LANs as
one virtual one (TLS or VPLS). This would have the following benefits:

o At customer premises you dont need to have the *costly* router
function to
strip ethernet and put another L2 header. You can get away with
having just
an ethernet switch.

o The QoS/VLAN information remains *intact* across ISPs network.

o You basically get an L2 VPN inexpensively.

>
> ppp-over ethernet is a hack that does add an authentification step unavailable
> in ethernet, besides that it does not add much more then wasted bits

My point is why do we even need PPP. Why cant we just transmit the
ethernet packet on T1 line *as-is*.

Thanks
Steve

>
> > Thanks
> > Steve
October 18, 2004 12:42:47 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Reed <reedh@rmi.net> wrote in message news:<4172BFDC.861EB535@rmi.net>...
> Mark wrote:
> >
> > When we can run PPP over T1, then why cant we have Ethernet frames
> > transmitted over T1.
> >
> > Once we have a PPP packet we would be transmitting it in DS0 channels
> > - we can perhaps use the same logic to transmit ethernet frames.
> >
> > Comments ?
> >
> > Thanks
> > Steve
>
> Look up the function of "bridges" in the LAN environment. Nobody
> sells them as such any more. Most if not all routers can be
> configured for "bridging only". An old example of an
> Ethernet-to-T1 Remote Bridge device would be the Retix 4800
> series.

Precisely, I am looking for a ethernet-to-T1 bridge. In one of my
previous replies to this thread, I have mentioned the benefits of
doing that.

>
> BTW, why are you channelizing your PPP into DS0's ?? Why not look
> at the T-1 as a single 1.536Mb pipe ??

What if you want to channel your voice calls on some DS0's.

Thanks for your response
Steve

>
> --reed
October 18, 2004 1:07:40 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Mark" <steven_mark_99@yahoo.com> wrote in message
news:c8e879a1.0410171939.4c7cceff@posting.google.com...
> phn@icke-reklam.ipsec.nu wrote in message
news:<cktfoe$hq7$2@nyheter.ipsec.se>...
> > Mark <steven_mark_99@yahoo.com> wrote:
> > > When we can run PPP over T1, then why cant we have Ethernet frames
> > > transmitted over T1.
> >
> > > Once we have a PPP packet we would be transmitting it in DS0 channels
> > > - we can perhaps use the same logic to transmit ethernet frames.
> >
> > > Comments ?
> >
> > I would suggest stripping off link headers and encapsulate the network
layer
> > in the link layer used for your T1. There is seldom any point in
>
> See thats what my question is - Why cant we use "ethernet" link layer
> header on T1.

you could - but the underlying HDLC processing used by PPP is built into
most chips that drive a serial link.

Also - ethernet has some overheads that "waste" bandwidth on a serial link -
using PPP replaces 2 * 6 byte MAC headers with 2 to 4 bytes of PPP
encapsulation - after not much need for source and destination world wide
unique addresses when all you have is the 2 end points on the serial
link....

PPP negotiation means that routers have a much clearer idea of the
operational state of a link than you would get with the "fire and forget"
methods of Ethernet - which assume the reliability of a LAN.
>
> > transmitting linklayers since they are used only as "containers on the
> > local media" and has no significance outside the site or LAN.
>
> They *do* make a sense. I will give an example - Assume that a company
> has offices in Chicago, Denver and New York. It runs Ethernet on its
> LAN. Now, assume that there is a lot of interoffice transaction.
> Wouldnt it be good to consider all these physically separate LANs as
> one virtual one (TLS or VPLS).

i used to build big bridged WANs using Vitalink / DEC gear - they were
always a pain to build and use. As soon as routing became mainstream the
vast majority of bridged WANs moved to routing to improve their networks.

The flip side to your WAN scenario is that the serial links have to carry
all the layer 2 maintenance traffic which normally occurs within a single
subnet - ARP traffic, NetBIOS name broadcasts, any multicasts from spanning
tree and so on. On a 100+ user site this can amount to 10s of packets / sec,
eating into your T1 capacity.

Routing insulates the link from some of that overhead.

there are serious scaling issues to pure layer 2 environments - the largest
i have heard of that actually worked was around 20k MAC addresses, but LANs
with 1000s of devices are difficult to maintain because a single problem can
wipe out so many users. routing is used within large sites to provide some
isolation between subnets

if your WAN uses the "invisible" serial link ineffectively - i.e. all your
users in 1 site use an internet feed remotely, or find the wrong active
directory server to pull policies from - then your T1 link may be saturated
with traffic that could be handled locally.

Routing makes some of the WAN network topology visible to user devices - so
that WAN usage can be better optimised (i am not saying that it will be - i
spend some of my day job hunting such issues).

> This would have the following benefits:
>
> o At customer premises you dont need to have the *costly* router
> function to
> strip ethernet and put another L2 header. You can get away with
> having just
> an ethernet switch.

Routing is not all that "costly" in the sense you use - after all SOHO NAT
routers cost $100 or so, and handle a broadband connection. "enterprise"
gear cost a lot more - but there users pay for better reliability,
flexibility and support (whether they get it in all cases is an ongoing
argument)

Look at the cost of your hypothetical serial links (in the $1000s / month)
and the cost of a typical enterprise T1 capable router (say a cisco 2610 -
$3k or so with serial interfaces etc). Anything that gets 10 to 20% more out
of that T1 capacity pays for itself quickly.

FWIW i agree with some of your arguments - if Ethernet packets can cross the
WAN link then you may choose to only route at 1 end, or not route at all
(this is a common design tradeoff where Ethernet is used as a WAN or MAN
connection, although cutting down on routing makes error isolation more
difficult and complicates the LAN design) - but there are tradeoffs, and
routed WANs are easier to build, maintain and manage.
>
> o The QoS/VLAN information remains *intact* across ISPs network.

QoS argument is a reasonable idea - but most QoS these days seems to be
implemented in IP as Diffserv (or done as a local decision within a router
queue), and Diffserv can cross a routed network end to end.

Layer 2 QoS might be preserved across an ISP network, but the whole point of
QoS is that each device across a path responds to QoS - and current ISPs
mainly ignore IP QoS because it doesnt make sense for them to allow some
user traffic to queue jump in front of others unless they can charge for
that priviledge.

if you want to look at some telco technologies that give layer 2 WANs, try
hunting info on Ethernet over MPLS - a good intro will explain some issues
that also impact on your Ethernet over a WAN suggestion.

Global VLANs are not necessarily a good thing - there are "only" 4000 unique
VLAN numbers in 802.1Q, and some kit puts more severe restrictions on
numbers used, so it can be easy to run out of VLANs if they have to be
globally unique.

and anyway - i use VLANs to limit where layer 2 traffic can go, not let it
spread to anywhere on a network.....
>
> o You basically get an L2 VPN inexpensively.
>
but i dont want that - spanning tree across a WAN means i cant load balance
on resilient links.

do you really want to send NetBIOS packets with their fixed sub second
timeouts across a WAN where latency means you might end up sending 20 to 30%
of the packets twice or more?
> >
> > ppp-over ethernet is a hack that does add an authentification step
unavailable
> > in ethernet, besides that it does not add much more then wasted bits
>
> My point is why do we even need PPP. Why cant we just transmit the
> ethernet packet on T1 line *as-is*.

PPP is more optimised to a serial link constraints, where the cost of
bandwidth is different to a LAN environment.

PPP handles point to point systems more effectively.

PPP understands negotiating useful WAN functions such as link
authentication, compression and fragmentation which arent normally an issue
with Ethernet.
>
> Thanks
> Steve
>
> >
> > > Thanks
> > > Steve
--
Regards

Stephen Hope - return address needs fewer xxs
Anonymous
October 18, 2004 6:24:20 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark <steven_mark_99@yahoo.com> wrote:
> phn@icke-reklam.ipsec.nu wrote in message news:<cktfoe$hq7$2@nyheter.ipsec.se>...
>> Mark <steven_mark_99@yahoo.com> wrote:
>> > When we can run PPP over T1, then why cant we have Ethernet frames
>> > transmitted over T1.
>>
>> > Once we have a PPP packet we would be transmitting it in DS0 channels
>> > - we can perhaps use the same logic to transmit ethernet frames.
>>
>> > Comments ?
>>
>> I would suggest stripping off link headers and encapsulate the network layer
>> in the link layer used for your T1. There is seldom any point in

> See thats what my question is - Why cant we use "ethernet" link layer
> header on T1.

I read the header. And i don't think you understand the issue.

>> transmitting linklayers since they are used only as "containers on the
>> local media" and has no significance outside the site or LAN.

> They *do* make a sense. I will give an example - Assume that a company
> has offices in Chicago, Denver and New York. It runs Ethernet on its
> LAN. Now, assume that there is a lot of interoffice transaction.
> Wouldnt it be good to consider all these physically separate LANs as
> one virtual one (TLS or VPLS). This would have the following benefits:

> o At customer premises you dont need to have the *costly* router
> function to
> strip ethernet and put another L2 header. You can get away with
> having just
> an ethernet switch.
>
> o The QoS/VLAN information remains *intact* across ISPs network.

> o You basically get an L2 VPN inexpensively.

Moot arguments, in fact no arguments at all.

As anyone that has been administrating WAN-links can tell you, route where
you canm bridge when you must.



>>
>> ppp-over ethernet is a hack that does add an authentification step unavailable
>> in ethernet, besides that it does not add much more then wasted bits

> My point is why do we even need PPP. Why cant we just transmit the
> ethernet packet on T1 line *as-is*.

My point, Why not transfer the ip-packets and ONLY the ip packets without
extra overhead ??

As extra bonus you will get a reliable network where broadcasts storms ( you are
running windows ??) won't propagate across a continent and a predictable
network where some degree of control over datastreams are possible.

Network effectivness won't come for free however, it will cost both
networking gear and a designer with a clue.

> Thanks
> Steve

>>
>> > Thanks
>> > Steve

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Anonymous
October 18, 2004 6:59:46 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:
> When we can run PPP over T1, then why cant we have Ethernet frames
> transmitted over T1.
>
> Once we have a PPP packet we would be transmitting it in DS0 channels
> - we can perhaps use the same logic to transmit ethernet frames.
>
> Comments ?
>
> Thanks
> Steve

do a google for "RAD TINY BRIDGE"

(works only if the T1 is not broken up into DS0's and only if it is pt
to pt - can't use with frame relay, ect)

I have one that I needed for an odd config - cute little box. Has a v.35
on 1 side (plug into your T1 csu) and an rj45 on other side (plug into
ethernet). Simple to set up - basically plug and go.

But not a good idea, IMO. I firmly believe in "route where you can,
bridge where you must" - makes the network MUCH more manageble.
Anonymous
October 18, 2004 9:45:06 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark <steven_mark_99@yahoo.com> wrote:

> My point is why do we even need PPP. Why cant we just transmit the
> ethernet packet on T1 line *as-is*.

You're thinking about this backwards. What you're missing is that
Ethernet is not designed for global coverage. It's a LAN scheme. As
such, it is inadequate for use as a WAN frame. Simple example: the
addresses used in Ethernet are merely numbers. They give no clue as to
the location of the hosts. Therefore, they are inefficient for sending
frames around the world (or even between offices that are geographically
separate). You would need an exhaustive list of every MAC address in the
world to route packets globally using nothing but Ethernet frames. This
list would have to be installed in every router.

In order to move packets around the world efficiently, you need a
network layer protocol such as IP, and routing protocols to go with it.

So the way to make this work is to encapsulate the *meaningful*
information, i.e. the IP packets, directly inside the frame structure
used by your WAN link. That's what PPP does. And more, it also can be
used to dynamically assign IP addresses to the local hosts. And you toss
out the irrelevant overhead, which is the Ethernet overhead that
happened to be used in the originating local network.

To put this another way, if we did as you suggest, toss out PPP and just
send the Ethernet frame intact over a WAN, then how would the WAN know
where to route that frame?

Answer: it would only know if the WAN were set up as statically
configured tunnels, or dedicated links, between point A and point B.
Well, what's so clever about that? Can you imagine how complicated the
administration of the global infrastructure would be if every WAN link
were a statically configured, dedicated link?

And can you imagine how inefficient it would be to see ARP broadcasts
going to all hosts attached to this huge Ethernet?

I remember a few years ago, when some folk thought it imperative to send
FDDI frames intact over SONET. As if the FDDI frames had some intrinsic
value that had to be protected at all cost. Never mind the issue of
sending tokens (potentially) all over the world, creating ridiculously
big ring nets. This is the same sort of thing. It makes no sense to make
a big deal about the Ethernet frame, outside the confines of a *local*
area network. What counts is the IP packet.

If you want to build a protocol of your own directly over Ethernet,
that's fine too. But now you're going to be limited in how far the
frames can travel, unless you go to the trouble of reinventing the wheel
and creating another network layer protocol. Still, in specific
circumstances, it might make sense to create such a home-grown protocol,
as long as you're aware of its limitations.

Bert
Anonymous
October 18, 2004 9:49:52 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark <steven_mark_99@yahoo.com> wrote:

> My point is why do we even need PPP. Why cant we just transmit the
> ethernet packet on T1 line *as-is*.

You're thinking about this backwards. What you're missing is that
Ethernet is not designed for global coverage. It's a LAN scheme. As
such, it is inadequate for use as a WAN frame. Simple example: the
addresses used in Ethernet are merely numbers. They give no clue as to
the location of the hosts. Therefore, they are inefficient for sending
frames around the world (or even between offices that are geographically
separate). You would need an exhaustive list of every MAC address in the
world to route packets globally using nothing but Ethernet frames. This
list would have to be installed in every router.

In order to move packets around the world efficiently, you need a
network layer protocol such as IP, and routing protocols to go with it.

So the way to make this work is to encapsulate the *meaningful*
information, i.e. the IP packets, directly inside the frame structure
used by your WAN link. That's what PPP does. And more, it also can be
used to dynamically assign IP addresses to the local hosts. And you toss
out the irrelevant overhead, which is the Ethernet overhead that
happened to be used in the originating local network.

To put this another way, if we did as you suggest, toss out PPP and just
send the Ethernet frame intact over a WAN, then how would the WAN know
where to route that frame?

Answer: it would only know if the WAN were set up as statically
configured tunnels, or dedicated links, between point A and point B.
Well, what's so clever about that? Can you imagine how complicated the
administration of the global infrastructure would be if every WAN link
were a statically configured, dedicated link?

And can you imagine how inefficient it would be to see ARP broadcasts
going to all hosts attached to this huge Ethernet?

I remember a few years ago, when some folk thought it imperative to send
FDDI frames intact over SONET. As if the FDDI frames had some intrinsic
value that had to be protected at all cost. Never mind the issue of
sending tokens (potentially) all over the world, creating ridiculously
big ring nets. This is the same sort of thing. It makes no sense to make
a big deal about the Ethernet frame, outside the confines of a *local*
area network. What counts is the IP packet.

If you want to build a protocol of your own directly over Ethernet,
that's fine too. But now you're going to be limited in how far the
frames can travel, unless you go to the trouble of reinventing the wheel
and creating another network layer protocol. Still, in specific
circumstances, it might make sense to create such a home-grown protocol,
as long as you're aware of its limitations.

Bert
October 19, 2004 4:05:31 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"stephen" <stephen_hope.xx@ntlxworld.com> wrote in message news:<wJLcd.128$1l6.49@newsfe1-gui.ntli.net>...
> "Mark" <steven_mark_99@yahoo.com> wrote in message
> news:c8e879a1.0410171939.4c7cceff@posting.google.com...
> > phn@icke-reklam.ipsec.nu wrote in message
> news:<cktfoe$hq7$2@nyheter.ipsec.se>...
> > > Mark <steven_mark_99@yahoo.com> wrote:
> > > > When we can run PPP over T1, then why cant we have Ethernet frames
> > > > transmitted over T1.
>
> > > > Once we have a PPP packet we would be transmitting it in DS0 channels
> > > > - we can perhaps use the same logic to transmit ethernet frames.
>
> > > > Comments ?
> > >
> > > I would suggest stripping off link headers and encapsulate the network
> layer
> > > in the link layer used for your T1. There is seldom any point in
> >
> > See thats what my question is - Why cant we use "ethernet" link layer
> > header on T1.
>

First let me thank you for such a detailed and informative reply!

> you could - but the underlying HDLC processing used by PPP is built into
> most chips that drive a serial link.

Hmmm...

>
> Also - ethernet has some overheads that "waste" bandwidth on a serial link -
> using PPP replaces 2 * 6 byte MAC headers with 2 to 4 bytes of PPP
> encapsulation - after not much need for source and destination world wide
> unique addresses when all you have is the 2 end points on the serial
> link....

Understood.

>
> PPP negotiation means that routers have a much clearer idea of the
> operational state of a link than you would get with the "fire and forget"
> methods of Ethernet - which assume the reliability of a LAN.
> >
> > > transmitting linklayers since they are used only as "containers on the
> > > local media" and has no significance outside the site or LAN.
> >
> > They *do* make a sense. I will give an example - Assume that a company
> > has offices in Chicago, Denver and New York. It runs Ethernet on its
> > LAN. Now, assume that there is a lot of interoffice transaction.
> > Wouldnt it be good to consider all these physically separate LANs as
> > one virtual one (TLS or VPLS).
>
> i used to build big bridged WANs using Vitalink / DEC gear - they were
> always a pain to build and use. As soon as routing became mainstream the
> vast majority of bridged WANs moved to routing to improve their networks.

I havent worked with real-life networks as such so I really didnt know
the paradigm - "route when you can, bridge when you must". Now, when I
think more about it, it does make sense to use routing in WAN.

>
> The flip side to your WAN scenario is that the serial links have to carry
> all the layer 2 maintenance traffic which normally occurs within a single
> subnet - ARP traffic, NetBIOS name broadcasts, any multicasts from spanning
> tree and so on. On a 100+ user site this can amount to 10s of packets / sec,
> eating into your T1 capacity.

Makes sense.

>
> Routing insulates the link from some of that overhead.
>
> there are serious scaling issues to pure layer 2 environments - the largest
> i have heard of that actually worked was around 20k MAC addresses, but LANs
> with 1000s of devices are difficult to maintain because a single problem can
> wipe out so many users. routing is used within large sites to provide some
> isolation between subnets
>
> if your WAN uses the "invisible" serial link ineffectively - i.e. all your
> users in 1 site use an internet feed remotely, or find the wrong active
> directory server to pull policies from - then your T1 link may be saturated
> with traffic that could be handled locally.

Here, you must be referring to the headaches in allowing LAN to expand
beyond its physical boundaries.

>
> Routing makes some of the WAN network topology visible to user devices - so
> that WAN usage can be better optimised (i am not saying that it will be - i
> spend some of my day job hunting such issues).
>
> > This would have the following benefits:
> >
> > o At customer premises you dont need to have the *costly* router
> > function to
> > strip ethernet and put another L2 header. You can get away with
> > having just
> > an ethernet switch.
>
> Routing is not all that "costly" in the sense you use - after all SOHO NAT
> routers cost $100 or so, and handle a broadband connection. "enterprise"
> gear cost a lot more - but there users pay for better reliability,
> flexibility and support (whether they get it in all cases is an ongoing
> argument)

Frankly speaking, I didnt really buy the costly argument myself when I
read it in "Ethernet over SONET" white paper from PMC-Sierra dated
Feb, 2002

"Often, the inter-working function must terminate the Ethernet and map
the underlying IP traffic into a new Layer 2 (L2). Alternatively, the
Ethernet is encapsulated within another L2 technology. Both of these
techniques introduce additional complexity and cost into the WAN
interface".

Slapping a different L2 header may not be as complex after all.

>
> Look at the cost of your hypothetical serial links (in the $1000s / month)
> and the cost of a typical enterprise T1 capable router (say a cisco 2610 -
> $3k or so with serial interfaces etc). Anything that gets 10 to 20% more out
> of that T1 capacity pays for itself quickly.
>
> FWIW i agree with some of your arguments - if Ethernet packets can cross the
> WAN link then you may choose to only route at 1 end, or not route at all
> (this is a common design tradeoff where Ethernet is used as a WAN or MAN
> connection, although cutting down on routing makes error isolation more
> difficult and complicates the LAN design) - but there are tradeoffs, and
> routed WANs are easier to build, maintain and manage.

I understand your point...


> >
> > o The QoS/VLAN information remains *intact* across ISPs network.
>
> QoS argument is a reasonable idea - but most QoS these days seems to be
> implemented in IP as Diffserv (or done as a local decision within a router
> queue), and Diffserv can cross a routed network end to end.
>
> Layer 2 QoS might be preserved across an ISP network, but the whole point of
> QoS is that each device across a path responds to QoS - and current ISPs
> mainly ignore IP QoS because it doesnt make sense for them to allow some
> user traffic to queue jump in front of others unless they can charge for
> that priviledge.

Well, I agree with you again here. Even with Ethernet L2 QoS
(802.11p), preserving it would make sense if the provider transport
network cam honour those bits i.e. have its MPLS QoS bits derive from
Ethernet QoS.

>
> if you want to look at some telco technologies that give layer 2 WANs, try
> hunting info on Ethernet over MPLS - a good intro will explain some issues
> that also impact on your Ethernet over a WAN suggestion.

Sure.

>
> Global VLANs are not necessarily a good thing - there are "only" 4000 unique
> VLAN numbers in 802.1Q, and some kit puts more severe restrictions on
> numbers used, so it can be easy to run out of VLANs if they have to be
> globally unique.
>
> and anyway - i use VLANs to limit where layer 2 traffic can go, not let it
> spread to anywhere on a network.....

I like this argument.

> >
> > o You basically get an L2 VPN inexpensively.
> >
> but i dont want that - spanning tree across a WAN means i cant load balance
> on resilient links.

In a VPLS scenario, we would need to run to spanning tree protocol on
L2 switches (as you indicate). Although it has the disadvantage of
having long convergence time, and non-utilization of redundant link,
it may be a *cheaper* option - in terms of cost (of
service/equipment).

>
> do you really want to send NetBIOS packets with their fixed sub second
> timeouts across a WAN where latency means you might end up sending 20 to 30%
> of the packets twice or more?
> > >
> > > ppp-over ethernet is a hack that does add an authentification step
> unavailable
> > > in ethernet, besides that it does not add much more then wasted bits
> >
> > My point is why do we even need PPP. Why cant we just transmit the
> > ethernet packet on T1 line *as-is*.
>
> PPP is more optimised to a serial link constraints, where the cost of
> bandwidth is different to a LAN environment.
>
> PPP handles point to point systems more effectively.
>
> PPP understands negotiating useful WAN functions such as link
> authentication, compression and fragmentation which arent normally an issue
> with Ethernet.

Very well.

thanks again for an edifying response, ;-)
Steve



> >
> > Thanks
> > Steve
> >
> > >
> > > > Thanks
> > > > Steve
October 19, 2004 4:08:27 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"T. Sean Weintz" <strap@hanh-ct.org> wrote in message news:<10n84l3b7jqc813@news.supernews.com>...
> Mark wrote:
> > When we can run PPP over T1, then why cant we have Ethernet frames
> > transmitted over T1.
> >
> > Once we have a PPP packet we would be transmitting it in DS0 channels
> > - we can perhaps use the same logic to transmit ethernet frames.
> >
> > Comments ?
> >
> > Thanks
> > Steve
>
> do a google for "RAD TINY BRIDGE"

Thanks for pointing this out!
Steve

>
> (works only if the T1 is not broken up into DS0's and only if it is pt
> to pt - can't use with frame relay, ect)
>
> I have one that I needed for an odd config - cute little box. Has a v.35
> on 1 side (plug into your T1 csu) and an rj45 on other side (plug into
> ethernet). Simple to set up - basically plug and go.
>
> But not a good idea, IMO. I firmly believe in "route where you can,
> bridge where you must" - makes the network MUCH more manageble.
October 19, 2004 4:18:54 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Albert Manfredi" <albert.e.manfredi@nospam.com> wrote in message news:<I5sK73.8vM@news.boeing.com>...
> Mark <steven_mark_99@yahoo.com> wrote:
>
> > My point is why do we even need PPP. Why cant we just transmit the
> > ethernet packet on T1 line *as-is*.
>
> You're thinking about this backwards. What you're missing is that
> Ethernet is not designed for global coverage. It's a LAN scheme. As

By Ethernet on WAN, I mean it would be either used as in VPLS/TLS
scenario (for enterprises) or just as an access technology for the
end-customer (where ethernet frame from users network travels on WAN
link to the PE router of ISP where its ethernet header is stripped and
the IP packet is routed).

> such, it is inadequate for use as a WAN frame. Simple example: the
> addresses used in Ethernet are merely numbers. They give no clue as to
> the location of the hosts. Therefore, they are inefficient for sending
> frames around the world (or even between offices that are geographically
> separate). You would need an exhaustive list of every MAC address in the
> world to route packets globally using nothing but Ethernet frames. This
> list would have to be installed in every router.
>
> In order to move packets around the world efficiently, you need a
> network layer protocol such as IP, and routing protocols to go with it.
>
> So the way to make this work is to encapsulate the *meaningful*
> information, i.e. the IP packets, directly inside the frame structure
> used by your WAN link. That's what PPP does. And more, it also can be
> used to dynamically assign IP addresses to the local hosts. And you toss
> out the irrelevant overhead, which is the Ethernet overhead that
> happened to be used in the originating local network.

Understand the argument about overhead and managing the Point-to-Point
link parameters (managing link-layer and network-layer besides
authentication).

>
> To put this another way, if we did as you suggest, toss out PPP and just
> send the Ethernet frame intact over a WAN, then how would the WAN know
> where to route that frame?

As I mentioned earlier, WAN router would do L2 switching (basically
sending L2 frame across its network encapsulated as an MPLS packet) or
the router would strip ethernet header and perform routing.

>
> Answer: it would only know if the WAN were set up as statically
> configured tunnels, or dedicated links, between point A and point B.
> Well, what's so clever about that? Can you imagine how complicated the
> administration of the global infrastructure would be if every WAN link
> were a statically configured, dedicated link?

Well, for VPLS case, the WAN router would perform MAC learning etc.
(so no static config) and there is no need to have a dedicated channel
in provider cloud for this traffic.

>
> And can you imagine how inefficient it would be to see ARP broadcasts
> going to all hosts attached to this huge Ethernet?

Agreed, but over a period of time ARP flood is going to decrease.

>
> I remember a few years ago, when some folk thought it imperative to send
> FDDI frames intact over SONET. As if the FDDI frames had some intrinsic
> value that had to be protected at all cost. Never mind the issue of
> sending tokens (potentially) all over the world, creating ridiculously
> big ring nets. This is the same sort of thing. It makes no sense to make
> a big deal about the Ethernet frame, outside the confines of a *local*
> area network. What counts is the IP packet.

Well, tell it to VPLS/TLS folks ;-) I kinda dont buy VPLS/TLS argument
too much.
Not sure how many active deployments are out there for it.

>
> If you want to build a protocol of your own directly over Ethernet,
> that's fine too. But now you're going to be limited in how far the
> frames can travel, unless you go to the trouble of reinventing the wheel
> and creating another network layer protocol. Still, in specific
> circumstances, it might make sense to create such a home-grown protocol,
> as long as you're aware of its limitations.

I didnt have any such intention ;-)

Anyways, thanks for your response!
Steve


>
> Bert
Anonymous
October 25, 2004 12:58:56 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

It's a bit late in the thread and much has already been said. Parts
were really interesting, thanks guys. There is, however, a bit I think
I can say something about.

On 2004-10-18, Mark <steven_mark_99@yahoo.com> wrote:
[snip]
>
> They *do* make a sense. I will give an example - Assume that a company
> has offices in Chicago, Denver and New York. It runs Ethernet on its
> LAN. Now, assume that there is a lot of interoffice transaction.
> Wouldnt it be good to consider all these physically separate LANs as
> one virtual one (TLS or VPLS). This would have the following benefits:

You forget to list the negatives, such as making those lans one big
fat broadcast domain. No, switches won't help there. Yes, your offices
all run machines that like to broadcast. Lots. And all that broadcast
traffic _has_ to go over the T1. It might mean a broadcast storm for
every single desktop that crashes or gets switched on, for both sides
of the network. What is the cost of that in wasted bandwidth? Nevermind
that DHCP also will be bridged over the T1, latencies increase, whatnot.
You Really Do Not Want To Go There.


> o At customer premises you dont need to have the *costly* router
> function to
> strip ethernet and put another L2 header. You can get away with
> having just
> an ethernet switch.

The router function is not so costly if you look at all the other costs.
You still need people to manage the network. Somethimes things just
break. Then you will want to find out what went wrong or at least what
to do to make it work again, and do so *quickly*. You cannot do everything
with a switch. If your operations people are even just 10% quicker in
fixing things with a router than with a switch, the router may be well
worth the extra cost. I'll leave the actual math to you, as it is
complex and has too many factors off-topic to this group.


> My point is why do we even need PPP. Why cant we just transmit the
> ethernet packet on T1 line *as-is*.

Someone else already answered this. You could, but you don't really
want to: it doesn't make much sense. Money isn't everything there is to
managing networks. To give just one other: Making it work, and making
it work well. How reliable do you want your network to be? Then you
might as well use technology that has explicitly been designed to do
the task, and not something else that was designed for something else
entirely. To pull another counterexample back into this: Even PPPoE
doesn't *replace* ethernet, it takes ethernet and adds something to it
that wasn't there before. *Replacing* ppp with ethernet frames loses
things that are useful on a point-to-point link and adds things to it
that don't make sense on the medium. Since T1s are rather limited, even
compared to 10Mbit ethernet, those few extra bytes are now dead weight
that may prove to be expensive.

What exactly you lose and what exactly you (don't) gain is an interesting
question that is unfortunately better suited to a networking course.
You could try and read _Computer Networks_ by Tanenbaum for an overview
of the issues involved.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
Anonymous
November 7, 2004 5:31:21 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:

> When we can run PPP over T1, then why cant we have Ethernet frames
> transmitted over T1.
>
> Once we have a PPP packet we would be transmitting it in DS0 channels
> - we can perhaps use the same logic to transmit ethernet frames.

While it's certainly possible, using GRE, to carry ethernet frames over any
IP system, there's rarely a need to carry the extra overhead of the
ethernet frame, which is only required on the local lan. PPP by itself, is
capable of carrying various networking protocals (not just IP), so there's
really no need for carrying ethernet frames.
Anonymous
November 7, 2004 5:34:13 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:

> Hmmm...Well you do routing on the customer premises to see if the
> packet is meant for locally connected network or is meant for uplink
> connection to ISP. If meant for uplink connection, the router could
> send the same ethernet packet it received on T1 line (assuming
> router has CSU capability). Now the ISP router receives an ethernet
> packet on its T1 line - it either strips the ethernet header and
> routes the packet on appropriate outgoing interface or (if router
> supports VPLS or TLS) doesnt strip the ethernet packet and sends it
> across its L2VPN provider cloud.
>
> Does this make sense....
>

Given that the purpose is to move data, not just ethernet frames, no it
doesn't. There are many methods available, to move network data over a
telecom link, that are better suited to the task, than ethernet.
Anonymous
November 7, 2004 5:49:58 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:

> See thats what my question is - Why cant we use "ethernet" link layer
> header on T1.
>

Why bother? What's so magical about ehternet headers?

> They do make a sense. I will give an example - Assume that a company
> has offices in Chicago, Denver and New York. It runs Ethernet on its
> LAN. Now, assume that there is a lot of interoffice transaction.
> Wouldnt it be good to consider all these physically separate LANs as
> one virtual one (TLS or VPLS). This would have the following benefits:
>
>  o At customer premises you dont need to have the costly router
> function to
>    strip ethernet and put another L2 header. You can get away with
> having just
>    an ethernet switch.

The entire world is heading to IP, including the phone companies. What does
ethernet over T1 get you that can't be obtained by the various IP methods.
Anonymous
November 7, 2004 5:58:58 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Reed wrote:

> Look up the function of "bridges" in the LAN environment. Nobody
> sells them as such any more.

Switches can be considered as mutliport bridges.
Anonymous
November 7, 2004 6:02:14 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Mark wrote:

> Precisely, I am looking for a ethernet-to-T1 bridge. In one of my
> previous replies to this thread, I have mentioned the benefits of
> doing that.

Once upon a time, there were many protocols in use, which could not be
routed. Fortunately those protocols have either disappeared or been
modified to run over IP. A non-routable protocol is about the only valid
reason for doing what you want and they are pretty much history. The world
is moving to IP, so routing will be the norm.
!