| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 129.1 | addressing and security for CUG in bridges | DELNI::GOLDSTEIN | Resident curmudgeon | Fri Aug 31 1990 13:20 | 32 |
| My personal opinion is that it wouldn't be impossible, but wouldn't be
particularly trivial either.
The key to a public network service is security. FDDI presumes private
physical media, so everybody's traffic can pass everybody else.
Obviously that's not okay in a public network.
A normal 802.1 bridge follows that rule; it would rather let a packet
pass to a place where it didn't need to be than block a packet from
getting where it might need to be.
In a public offering, the bridge function would have to be redefined.
It would be restrictive: Unless it _knew_ that the destination address
was in a given place, it would have to prevent traffic from going
there. The easiest way to do this is to pre-program the bridges with
the valid addresses. That's how the telephone network operates, after
all; phone numbers are administered by the network. A customer may be
given a block of addresses (they don't have to be onesie-twosie), but
the telco must know a priori who gets what traffic.
The normal 48-bit MAC address scheme allocates on the basis of
manufacturer, not customer. This is fine for private LANs but not for
public nets. Note thought that IEEE 802.6 is defining a Metropolitan
Area Network which allows 60-bit addresses, where the address is in the
format of a telephone (ISDN) number, and is software-assigned from a
range allocated via the telephone company.
FDDI doesn't want 60-bit addresses so you might have to use
locally-assigned (not ROM-based) MAC addresses, or administer every
single MAC address into the bridge. Neither would be especially
difficult, but the capability is probably not in our present products.
fred
|
| 129.2 | | KONING::KONING | NI1D @FN42eq | Fri Aug 31 1990 14:25 | 9 |
| A few more points: for this notion to work at all, the backbone would have
to be completely controlled by the PTT, and customers would go via a bridge
only. As soon as customers are permitted direct (MAC level) access to the
ring, you're dead...
The answers are identical for FDDI-II (apart from the fact that FDDI exists
and FDDI-II doesn't yet).
paul
|
| 129.3 | Most likely pilot for determining market, not for determining applicability of technology | CVG::PETTENGILL | mulp | Mon Sep 03 1990 21:06 | 16 |
| I'm surprised that this would be proposed by a German PTT since they seem to
want to control data flows to a greater degree than any other country. Perhaps
their interest is primarily in the area of understanding the problems of
handling fiber and managing high speed data network, without having any
intention of providing this as a long term tariffed product offering.
A recent issue of SigComm has a number if papers from people at Belcor that
address the issues if high speed public nets. I don't remember their comments
on `security', but as far as what makes sense, they argued rather strongly
against using FDDI, or FDDI on SONET, based on cost and scalability. They
point out what is obvious to anyone in the telco industry, point to point
links don't make sense (FDDI is point to point, but in a circle), when for
many reasons everything must got to central locations. Instead, you have
more flexibility by providing (packet) switched connections. I beleive
that Belcor is suggesting deployment of early stuff in 92-93 (seems unlikely
to me, but what do I know).
|
| 129.4 | Warning QPSX switches | IJSAPL::KWAAK | Dick van der Kwaak @ UTO | Wed Sep 12 1990 06:11 | 8 |
| Be aware that both Alcatel SEL and Siemens market QPSX switches.
These switches can interlink SONET, FDDI, Ethernet, etc.
Alcatel resently solt their MSS (QPSX switch product name) to the
Dutch PTT. The MSS switch will be the core of a public pilot
commencing next year.
Dick
|