Cheers,
Ras
No, you aren't right. Frame-Relay is a layer-2 protocol. As such,
it'll interfer with those other layer-2 protocols.
You'd have to do some sort of tunneling of frame-relay over IP or ATM,
although you probably won't have enough access to the ATM side of things.
What are you trying to acomplish though? I can't imgine the scenario
you'd want to even do such a thing.
Hi,
We are setting up a FR hub-spoke system for our branch and main
offices. The telco company offered us a "G.SHDSL to FrameRelay"
solution.
Main Office ---[FR]---> {FR Cloud} ------G.SHDSL Connection---->Branch
Office1
|
|-----------G.SHDSL
Connection---->Branch Office2
Maybe they will use {FR Cloud} -> {G.SHDSL Cloud} switch in their
internal networks..I am not sure on that. If they suggested this , they
should know what they are doing.But this is a weird solution for me
too, thus I wanted to ask..
Ras
>Main Office ---[FR]---> {FR Cloud} ------G.SHDSL Connection---->Branch
>Office1
> |
> |-----------G.SHDSL
>Connection---->Branch Office2
>Maybe they will use {FR Cloud} -> {G.SHDSL Cloud} switch in their
>internal networks..I am not sure on that. If they suggested this , they
>should know what they are doing.But this is a weird solution for me
>too, thus I wanted to ask..
So, they must be using some sort of big WAN switch in there. The
G.SHDSL will come into the telco as ATM PVCs off their DSLAM, they'll
take those ATM PVC's in their big WAN switch, convert them to
Frame-Relay PVC's and feed them back out to you as Frame-Relay in the
main office after its switched through their frame/cell-relay cloud.
The main-office only talks Frame-Relay. The branch offices only speak
G.SHDSL (ie. ATM), and the big WAN switch in the middle of telcoland
handles everything transparently.