[c-nsp] Inverse multiplexing DS3s to larger interfaces?

[Matthew Crocker]

Tom,

  Find out if you can get 'EC1' from your carrier.  an EC1 is the 
electrical version of an STS1, It is a DS-3 with the SONET wrapper,  51 
mbps.  If you can get EC1, then you can plug them into a ONS 15454 and 
*** I THINK *** map the STS1s into an OC-12c into your router.  The 
issue with muxing the DS-3s outside the router is you lose the per 
circuit statistics and if one drops or has errors it will be a bitch to 
find.  You would need 2 15454s, one on each end.  Plug all the EC1s 
together and link the DCC channels.  I think you can take an OC-12c 
into an ONS and map the STS1s over different 'rings'  each DS-3 pair 
would be a ring to the ONS.   You might not be able to do it with the 
CTC but you should be able to map everything with TL1 commands.
You'll have to make sure the carrier tunnels the DCC bits through their 
network so you don't see their SONET internals.

It is an ugly  'solution' but it might work,  again, any DS-3 goes down 
and the OC-12c is worthless.  Can you get dark fiber or a lambda from 
the carrier?  Get a 2.5 Ghz wave and run OC-48 over it

-Matt

On Feb 23, 2005, at 5:33 PM, Thomas D.Simes wrote:

>
> Thanks for the detailed reply Hyun, I agree 100% with your analysis and
> order of preference from a technical standpoint.  The question of
> whether the carriers will give us OC-X is more of a regulatory question
> unfortunately and we are doing all we can to pursue that path.
>
>
> On Wed, 23 Feb 2005 15:25:00 -0600
> Hyunseog Ryu <r.hyunseog at ieee.org> wrote:
>
>> If you want to avoid to hit maximum-path 8 limitation,
>> you have to increase the pipe size, and reduce the number of circuit
>> from the router viewpoint.
>> Ideal solution is to replace DS3s with higher bandwidth circuit such
>> as OC3, OC12 or GE.
>> But as you said, there is limitation from one of your provider, who
>> don't support more than DS3 pipe.
>>
>> In that case, I can think of a couple of ways.
>>
>> 1) Try to find another carrier who support OCx level circuit, or
>> pretending to do that.
>>
>> If you are lucky, you can find another provider, who can fill up OCx
>> requirement, and your headache may be gone.
>> Or you can use it to threaten current provider to support OCx circuit.
>> If they have multiple DS3s, I don't see the reason why they couldn't
>> support OCx circuit.
>> If they don't want to spend the money on OC3c cards, it's their
>> problem. In order to support multiple DS3s, they should already have
>> OCx support capability.
>>
>> I think this is best case for you, because you don't have to worry
>> about
>>    TDM Mux/demux between different speed, and routing may become
>>    simpler.
>>
>> 2) Find the vendor who have DS3s-to-OCx converters.
>>
>> Kentrox or Larscom, or others.
>> They may have some converters to map multiple DS3s to single OC3c or
>> OC12c. This may be cheaper solution, and you can buy OC3c or OC12c
>> interface for GSR, and keep DS3s circuits as-is.
>> Routing may become simpler, but if there is some difference in mapping
>>
>> speed from either side, there may be some issue.
>> For an example, if you have 2 DS3s, and you map 2 DS3s to 1 OC3c,
>> there is difference in capacity from both side.
>> Actual circuit side is 2 DS3s, which is 88.420Mbps.
>> Router side is 1 OC3c, which is 155Mbps.
>> So if the router send the traffic more than 88Mbps or there is some
>> problem with TDM multiplexing, there may be packet loss or packet
>> transmission delay.
>>
>> 3) If you want more sophiscated equipment, you can use Cisco ONS 15454
>> for 2) function.
>>
>> For the quality of transmission, and long-term management,
>> if I were you, I will try solution 1) with some scalability planned.
>> Maintain 2 carrier providers, but if they couldn't meet your
>> requirement, don't be afraid to ask for yourself to find another
>> provider to suit your needs.
>>
>> If they can sell x number of DS3s, there is no reason not to support
>> OCx for equivalent bandwidth. It may take a couple of months to
>> install fiber, but it's not a problem you can wait.
>>
>>
>> Hyun
>>
>>
>>
>> Thomas D.Simes wrote:
>>> We've currently got a pair of GSRs tied together with 7 DS3s from
>>> two different carriers and are load balancing via OSPF.  This
>>> method has worked pretty well, but the technique tops out at
>>> maximum-paths 8 on the GSR.
>>>
>>> I'm looking for a more scalable way to multiplex these DS3s into
>>> something larger and feed them into my GSRs to reduce the number of
>>> layer 3 paths between the two locations.
>>>
>>> Going to larger interfaces is currently not an option with one of
>>> the carriers, and we want to maintain dual carriers for redundancy
>>> if possible.  We're currently using the 6 Port Packet over DS3 cards
>>> and the interfaces don't support multilink PPP or multilink
>>> frame-relay.
>>>
>>> What have folks used that worked well for this application?
>>>
>>> The Cisco ONS 15454 using enhanced DS3 cards looks like it
>>> might be a possibility, but I don't have any experience with the
>>> platform.
>>>
>>> TIA!
>>>
>>
>>
>
>
> -- 
> Tom
>
> ======================================================================
>    "Z-80 system stack overflow.  Shut 'er down Scotty, the system's
>          sucking mud" - Error message on TRS 80 Model-16B
>
> Thomas D. Simes                                 simestd at netexpress.com
> ======================================================================
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>