| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 871.1 | Re: pvc vpi=0 issue | QUABBI::"[email protected]" | Hal Murray | Fri Mar 14 1997 20:32 | 7 |
| I don't know about the software or the 351.
The hardware in the 750 and 350 doesn't support non zero VPIs.
[posted by Notes-News gateway]
|
| 871.2 | Meteor VPI support (HW) | NPSS::GLASER | Steve Glaser DTN 226-7212 LKG1-2/W6 (G17) | Sat Mar 15 1997 10:28 | 20 |
| The 351 hardware can support a limited number of non-zero vpis.
You still get only 1K virtual circuits. You get to configure the chip
to make some of the "VC" bits get taken from the vp field in the ATM
header.
In other words, for a 1K VC 351, you can have something like
1K VC's on vpi 0
or 512 VC'2 on vpi 0 and 1
or 256 VC's on vpi 0, 1, 2 and 3
or 128 VC's on vpi 0, 1, 2, 3, 4, 5, 6 and 7
(similar for 256 and 4K VC modes of the newer 4K VC capable chip, you
get 0..3 bits of VPI when the rest being VCI)
Software support for this is a different story. I'm not up on what the
various drivers plan on doing.
Steveg
|
| 871.3 | Re: pvc vpi=0 issue | KAMPUS::BRANDNER | That's noot eentiiirly aaacuuraate ... | Mon Mar 17 1997 04:11 | 37 |
|
>Do I tell our customers to *always* use vpi=0 in their atm configuration?
YES, as of today (see below).
>Will pvc's ever work, otherwise?
NO, as of today (see below).
Actually the ATM subsystem for DU 4.0x does only support VPI=0.
This is because the ATMW 350/750 only supported VPI=0 and the
GS/ATM only supported VPI=0.
I think this will change for the GS/ATM in the future (VPI=0 only
support was a major showstopper for several bids here in Europe).
As with the ATMW 351 there will be VPI>0 support of the Adapter
it's very likely that the ATM subsystem will support the VPI>0
in the future too. But don't know about schedules.
Another issue here is FLOWmaster flow control. FLOWmaster uses the
VPI field for the credits. Thus you can not use a VCC with VPI>0
together with FLOWmaster.
There's a cure for this with QFC (Quantum Flow Control), but don't
know about the plans.
BTW: normally VPI>0 is used between switches to aggregate some VCCs.
Thus the switches would only have to look into the VPI
field to find the associated outbound link and VPI.
VPI=0 is usually used at the end systems to their directly
connected switch (UNI3.0|3.1 only describes signalling
for VPI=0).
VPI>0 support in an end system would make it possible to
directly connect the end system to a public ATM. At least
here in Germany you have to terminate|initiate a VP
to connect to the public ATM.
|
| 871.4 | thanks! | CSC32::N_HENDERSON | Nancy (Henderson) Flavell, CSC | Mon Mar 17 1997 10:07 | 5 |
| Thank you, all, for the very specific, helpful, if not somewhat
disappointing information.
Nancy
|
| 871.5 | our VP answer is quite positive for some customers | NPSS::WATERS | I need an egg-laying woolmilkpig. | Mon Mar 17 1997 10:22 | 8 |
| >Do I tell our customers to *always* use vpi=0 in their atm configuration?
>Will pvc's ever work, otherwise?
Depending on the customer's direction, you may want to tell them that
Digital's ATM switch has the most powerful VP termination support to date.
A VPC can forward VCCs to D.UNIX by terminating the VPC at the WAN access
link of GIGAswitch/ATM, then have the VCCs switched through to the host.
--gw
|
| 871.6 | | NPSS::NEWTON | Thomas Newton | Mon Mar 17 1997 11:42 | 11 |
|
>> I think this will change for the GS/ATM in the future (VPI=0 only
>> support was a major showstopper for several bids here in Europe).
We are working on Virtual Path Termination support now, for Version 2.5. You
will be able to configure a Version 2.0 line card so that it supports either:
o Four ATM ports, with each port restricted to VPI 0.
o One ATM port, supporting four VPIs (VPI 0 and up to three Virtual Path
Terminations).
|
| 871.7 | All the hooks should be there | SMURF::GREBUS | DTN 381-1426 - Digital Unix | Mon Mar 17 1997 13:01 | 13 |
| The core of the Digital UNIX ATM subsystem include support for non-zero
VPIs. But since the supported adapters (350 and 750) only allowed VPI 0,
this feature has never been qualified.
I don't know if the current version of the ATMworks 351 driver supports
non-zero VPIs. If it does, then I would expect everything else related
to PVC's to work. At some point we need to test this, but there aren't
any resources available to do so right now.
/gary
|
| 871.8 | Re: our VP answer is quite positive for some customers | KAMPUS::BRANDNER | That's noot eentiiirly aaacuuraate ... | Mon Mar 17 1997 13:18 | 6 |
|
Greg,
thank you for the clarification. Didn't know that it's already out.
Rudi
|
| 871.9 | short re-cap of Gsw/ATM VP termination features | NPSS::WATERS | I need an egg-laying woolmilkpig. | Mon Mar 17 1997 13:43 | 20 |
| >> Digital's ATM switch has the most powerful VP termination support to date.
>
>What do you mean with "most powerful VP termination support to date"?
>What more does it do than FORE switches do?
For now, we offer three VP terminations plus VPI zero on a WAN access
link of GIGAswitch/ATM. The hardware allows for nine VP terminations,
but current software treats each VPC as a virtual link, and software
thinks one line card connects at most four ATM links.
What we do that's unique is to provide three CBR/VBR VP-level traffic
shapers. So 3 of the eventual 9 VP terminations have the unusual ability
to shape bursty best-effort VCs so perfectly than WAN congestion losses
are eliminated. Each VP shaper multiplexes the contained VCs with
exceptional fairness and high traffic isolation. So if one VC carries
excessive UDP traffic, for example, it will have minimal effect on other
VCs sharing the VP. We have better traffic isolation features than FORE,
and much better than FORE's competitors.
Hope that helps. --gw
|
| 871.10 | Re .9 | KAMPUS::BRANDNER | That's noot eentiiirly aaacuuraate ... | Mon Mar 17 1997 13:55 | 6 |
|
Greg,
That's great news. Thanks for the information
Rudi
|