Re: HDLC frames delivered over PWs

>So, I understand, the solution for using HDLCPWs in my scenerio would be
>developing an extension to the RFC 4349 and submitting an I-D?

If what you want/need is not covered under current drafts or RFCs,
then yes, it would need an extension. In that case, I encourage you
to submit an I-D with your ideas, including the reliable delivery
mechanism that you will probably need.


>... delay must not be upper 50 ms.
>Are XYZ able to guarantee this requirement over any IP network?

There is absolutely no way for anyone to guarantee any given type
of delay, loss rate, bandwidth or anything like that over an
arbitrary IP network. You can only do that over a well engineered
network.


If you are planning to deploy L2TP tunnels to carry generic HDLC
traffic (like X.25) over an arbitrary IP network, I'll say you have
a problem in the making.

Given your requirements, you may want to investigate designing an
extension that includes the LAPB processing for the local X.25 loop
at the NSP on the local LCCE. That way, RRs, RNRs, etc will not need
to go across the tunnel and the timers for your local terminals will
be unaffected. Basically, the NSP would become a "relay" of sorts.

You still have the problem of delivering the I-frames to the remote
LCCE reliably and in order. For that, this new fangled NSPs will need
to implement some sort of reliable mechanism to deliver the I-frames
and whatever other information may be needed (eg, XID contents, etc).
This reliability and resequencing is not be provided by L2TP as is.

At this point, you are looking at implementing something akin to LAPB
to deliver this information. Any of the following alternatives could
provide the required reordering and reliable delivery: RFC1663,
RFC1151, Q.921, V.42 LAPM, etc. or you could use a much simpler ack
based system.

Hope this helps,
-Ignacio