[c-nsp] Design question for 7206VXR Port Adapters

Nick Voth nvoth at estreet.com
Sun Jan 30 15:21:12 EST 2011


Thanks Michael. If I could break the DS3 down with another piece of
equipment I could use the PA-A3-8T1IMA to deal with each T1 individually.
The trick is we only touch fiber and all of the telco capacity comes to us
as OC3 or OC12 level and then the telco breaks it out to DS3s for us.

I'll have to ponder this a bit more. Thanks for the input.

-Nick Voth


> From: Michael Sokolov <msokolov at ivan.Harhan.ORG>
> Date: Sun, 30 Jan 2011 18:39:36 GMT
> To: <cisco-nsp at puck.nether.net>, <nvoth at estreet.com>
> Subject: Re: [c-nsp] Design question for 7206VXR Port Adapters
> 
> Nick Voth <nvoth at estreet.com> wrote:
> 
>> I'm trying to figure out how to provide native ATM encapsulation via
>> individual T1's that aggregate on my end on a channelized DS3 on a 7206VXR.
>> The far end locations are multiple Adtran DSLAMs that only supports native
>> ATM encapsulation on their T1/IMA interfaces.
> 
> OK, I remember the earlier thread about this.
> 
>> I have done this before on the PA-A3-T3 or PA-A3-OC3SMI. In that case, I
>> just bring the individual T1 circuits in from the Telco via another VCI on
>> that larger interface.
> 
> That was fundamentally different in that you only had one ATM interface
> globally (i.e., only one ATM engine needed to exist in the hardware),
> and each individual T1 was a PVC on that ATM interface, which is trivial
> because all classic ATM gear supports lots and lots of PVCs on a single
> ATM interface, that's the whole point of ATM.
> 
> What you are trying to do now is fundamentally different: each of your
> T1s, be it a physical DS1 4-wire interface or a multiplex in a DS3, is
> now its own independent bona fide ATM interface, hence whatever hardware
> platform you end up using has to have as many ATM interface engines in
> it as the number of your T1s.
> 
> I have no idea if Cisco ever made anything like this - can someone else
> on this list (someone from Cisco maybe) clue us in on this?
> 
>> For this current application, I will be getting a channelized DS3, (not
>> ATM), from my telco, (XO Communications), and then the individual DS1's will
>> all have different end point locations. Those DS1s will need to pass native
>> ATM end to end instead of PPP.
> 
> Yup, makes total sense.
> 
>> There's also no way to bring the circuits to me as individual T1's for use
>> on an 8 port ATM card. They have to come in on a DS3 because of our telco
>> facilities.
> 
> One possible solution would be for you to acquire your own piece of
> telco hardware that breaks a DS3 into DS1s, a la M13, and install it in
> your own rack under your control right next to your router, then deal
> with the individual T1s.
> 
> You've mentioned some "8 port ATM card".  What is it?  Does Cisco have a
> module that provides 8 metallic DS1 interfaces and treats each as DS1/ATM?
> 
>> I currently use the PA-MC-T3 for all of our serial T1's, but that card
>> doesn't support native ATM encapsulation apparently.
> 
> Yes, that makes total sense: HDLC and ATM call for very different
> hardware, and making a single piece of hw that supports both is a royal
> pita.  (Speaking as someone who actually designs and builds his own hw
> of this sort; see www.harhan.com - sorry about the shameless plug.)  If
> one is building a port adapter for a single DS1, one could perhaps put
> up with the pain and build one that can do both HDLC and ATM, but I
> highly doubt that anyone would do that for a high-density module that
> terminates a whole DS3-load of DS1s: it would be built for either HDLC
> or ATM, not both.
> 
>> Is there a port adapter that can do that or do I need to be looking at a
>> different ATM switch on my end?
> 
> I have no idea if Cisco or anyone else has ever built a single piece of
> hw that does everything you need.  If not, you may have to settle for a
> multi-piece solution consisting of a discrete M13 to break the DS3 up
> into DS1s, then other gear to terminate DS1/ATM pipes individually.
> 
> HTH,
> MS





More information about the cisco-nsp mailing list