The IP Over NBMA (ION) Archive

[TG6124 <tg6124@topmail1.sbc.com>]

-----Original Message-----
From:	Xing Chen [SMTP:xchen@techmail.gdc.com]
Sent:	Wednesday, April 23, 1997 2:19 PM
To:	jed@llnl.gov; manfredi@arl.bna.boeing.com
Cc:	rxk@3com.com; ion@nexen.com
Subject:	Re: RBOCs Reaching Limits, DSLAM, xDSL, ATM, and IP

> From owner-ion@nexen.com  Tue Apr 22 15:15:22 1997
> Date: Tue, 22 Apr 1997 18:07:17 -0400
> From: Albert Manfredi <manfredi@arl.bna.boeing.com>
> Reply-To: manfredi@arl.bna.boeing.com
> Organization: Boeing North American
> X-Mailer: Mozilla 3.01 (Win16; I)
> MIME-Version: 1.0
> To: jed@llnl.gov
> CC: rajeev kochhar <rxk@3com.com>, ion@nexen.com
> Subject: Re: RBOCs Reaching Limits, DSLAM, xDSL, ATM, and IP
> Illegal-Object: Syntax error in References: value found on gate6.gdc.com:
> 	References:	<md5:1D4A7549CB1DFB5AC2AC6E478994CF42>
> 			    ^-illegal end of message identification
> Content-Transfer-Encoding: 7bit
> Sender: owner-ion@nexen.com
> X-Info: [Un]Subscribe to ion-request@nexen.com, submissions to ion@nexen.com
> X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/
> X-Info: FTP archive at ftp://ftp.nexen.com/pub/ion/
> 
> jed@llnl.gov wrote:
> 
> > A useful document I found on:
> > 
> > Digital Subscriber Line Access Multiplexer (DSLAM)
> > 
> > is:
> > 
> > http://www.adsl.com/adsl/private/snag_wt.html#5.2
> > 
> > in the ADSL Service Network Architecture Group (SNAG)
> > documentation.
> > 
> > The figure that is at that anchored URL shows a variety
> > of local loop transport technologies bringing data
> > into the DSLAM, and then the data going out through
> > an ATM switch (or visa versa naturally).  I am a bit
> > surprised by this use of ATM.  Can somebody explain
> > to me what ATM adds to this mix?
> > 
> > In the approach I discussed before coming out of the
> > DSLAM (or something like it) would be a connection to
> > an IP router for feeding upstream and a POTS connection
> > into the existing POTS switched network.  What is wrong
> > with that picture?
> 
> Let's say the xDSL user dials the number (telephone number) of his
> favorite ISP. That call has to go through to that ISP, in spite of the
> fact that the xDSL-coded data bypasses the phone switches. So how do you
> reach the ISP?
> 
> Perhaps, if you have ATM to use the ISP, the answer is straightforward.
> Otherwise, unless the RBOC forces the subscribers to use only certain
> ISPs, how do you keep that signaling information (I mean dialing info)?
> 

The xDSL user doesn't use "dial-up" access to the network.
If you are using ATM over ADSL, the solution is straightforward
as you and Wenjing mentioned.

However, if ATM is not used on the loop side, for example IP over
PPP over HDSL, currently service provisioning is needed to
establish the connection from a user to a selected ISP.
It will be nice that a mechanism or a procedure is defined in order
for the user to "signal" the NAP indicating which ISP to be
connected to. Any suggestions?

Regards,
---------
Xing Chen
General DataComm, Inc.
Park Road Extension             Tel: 203-758-1811
PO Box 1299                     Fax: 203-755-0896
Middlebury, CT 06762-1299       Email: xchen@gdc.com




I'm not sure what you mean when you say dial-up access to the network is not used. Would this not prevent future use of high-speed data networks for carrying public user-to-public user switched low quality of service traffic? This would certainly require the use of an E.164 (or other public addressing scheme) of some kind to establish the SVC. Isn't the assumption that dial-up access will not be used rather limiting on the future use of ATM?

Tim Gorman