As it turns out, we are not the first to tackle the problem of connecting
an ATM service like DSL which expects a native ATM terminal to a traditional
HDLC leased line terminal which doesn't know and doesn't want to know
anything about ATM.
Frame Relay Forum spec FRF.8 titled Frame Relay/ATM PVC Service
Interworking Implementation Agreement
addresses just this need,
and this spec is widely accepted in the industry.
FRF.8 specifies the functional requirements for an entity called the Interworking Function (IWF). On one side the IWF connects to a classic FR terminal (either directly or through an FR network) which doesn't know or want to know anything about ATM, and on the other side it connects to an ATM service which expects a native ATM terminal and offers no helping hand to non-ATM implementations. The IWF thus performs full protocol conversion to keep both sides happy and blissfully unaware of any interworking.
FRF.8 is also remarkable in that it explicitly takes the relevant IETF
RFCs into account. It thus does away with the traditional
separation of church and state
between the worlds of ITU/PTT
telecommunications and Internet.
FRF.8 does not merely transfer the payload between AAL5 CPCS-PDUs
and Q.922 frames — that would leave the FR terminal bewildered
at the RFC 1483 packet format put out by the ATM side.
Instead FRF.8 is smart enough to convert between RFC 1483 and
RFC 1490 on the fly!
Fortunately though, this RFC awareness is still implemented in a stateless
packet-by-packet manner and does not require the IWF to have any knowledge
of IP addresses, routing or other high level stuff.
(PPPoA is also automagically converted into PPPoFR by the same mechanism,
and again the conversion is stateless and does not require the IWF to
intervene in any LCP option negotiation.)
FRF.8 is already implemented by some DSLAMs (those that care enough about the user to not inflict ATM on him), and it seems to be just the right thing for us to implement in our OSDCU when connecting to ATM-flavored SDSL lines.
An alternative to FRF.8 is the ATM Forum's FUNI specification, which
stands for Frame-based User-to-Network Interface
.
It is the ATM Forum's standard for carrying AAL5 CPCS-PDUs on physical
interfaces which have HDLC frames instead of ATM cells.
The conversion between native ATM and FUNI is very straightforward
and doesn't need to be as aware of various RFC encapsulations as an FRF.8
IWF.
This is one advantage that FUNI has over FRF.8.
On the other hand, FUNI is at a disadvantage compared to FRF.8 in that with FUNI the HDLC terminal needs to be ATM-aware. With FUNI the HDLC terminal connects to ATM almost directly and gets to deal with RFC 1483 and similar encapsulations; only the cell-based physical layer requirement is removed.
A more serious problem with FUNI however is that at least in this hacker's experience, FRF.8 seems to be adopted and implemented much more widely. Nokia DSLAMs (used by Covad) implement FRF.8 on IDSL and T1 lines and FRF.8 also seems to be the way by which Copper Mountain DSLAMs provide classic encapsulations on routed circuits even when using the dominant ATM backhaul. But I have yet to see an implementation of FUNI in the real world with my own eyes! (I wouldn't go as far as calling it a completely unimplemented specification, as it appears that the ADSL Forum has used it in the early days of DSL before ADSL/DMT took over the world, it's just that I haven't seen an implementation with my own eyes in the world I live in.)
I'm thus a little hesitant to implement FUNI on the OSDCU or on my routers because I won't have anything to test it against other than another implementation also written by me which obviously doesn't count. So I think I'll just stick to FRF.8 for now.
FRF.5 specifies a much simpler interworking function (IWF) than FRF.8, but it has a much more specialized use: it converts between a Frame Relay interface on one side and an FR-over-ATM encapsulation on the other side. FRF.5 is thus just what you need if your ISP gives you an FR-over-ATM encapsulation, but is not of much use otherwise.