RE: [L2tpext] HDLC frames delivered over PWs

["Y Prasad" <[e-mail]>]

Hi Javi,

I think x.25 type of control traffic is sensitive to sequence numbers
(Ns/NR). So selectively avoiding certain control pkts over pw may not
work.
I guess the options are

   - Tune timeouts and re-tries as per the link delays. 
   - Terminate x.25 on PEs and use pw only for data traffic.

May be I've not understood the issue. Sorry in that case.

Regards
Prasad

-----Original Message-----
From: Javi [mailto:[e-mail]] 
Sent: Wednesday, September 13, 2006 4:04 PM
To: [e-mail]; 'Carlos Pignataro'; Ignacio Goyret;
Javi
Cc: [e-mail]
Subject: Re: [L2tpext] HDLC frames delivered over PWs

Hello Carlos, Henry and Ignacio,

Thanks for your comments,

Please see inline


==(Henry)

*> If the network performance is very poor then there is a danger of
> timeouts on these links* but, again, that is not usually the case in a
> modern network. *In most cases end to end delay can be measured in a
few
> 10's or possibly a few 100's of milliseconds*.

In my scenario, I haven't guarantees about network performance. So, a
danger of
timeouts is quite possible.

==(Henry)
> _You might have to adjust timers if you are using a poor network, or
> if you are traversing continents_.

Terminals have usually setup a value for the L2 timers. If you need
"tweaking though" them, it would have to be done in all the terminals,
which doesn't seem rasonable. And, generally, L2 timers negotiation
(based on frames XID frames) is not implemented

== (Carlos)

*> If flow-control packets (RR, RNR, Rej) are not sent over the PW
> then this specific PW extension needs to take care of local
flow-control*
> for example (see the discussion in rfc1613-XOT- section 6.2).
_Interested
> people can define this specific PW Type by submitting an I-D_.

*> There are usually situations where different types of optimizations
are
> needed/desired*, _and this WG should explore them_. Like (I think) you
> imply, the first step is to qualify and somewhat quantify the actual
> problem.
 
== (Ignacio Goyret)
/_*/_*> if there is a need for an application that would benefit from
eliminating
> some type of traffic, then, interested people (eg, Javi) should
develop
> an extension to the already present transparent mode of operation to
> negotiate filtering out RRs, etc.*_/*_/

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?

==(Ignacio Goyret)

> _However, note that L2TP does not guarantee data delivery so
eliminating
> non-I frames requires that you implement some sort of reliable data
> delivery between the LCCEs. There is no such thing in L2TP today_.

Would it be possible to propose an L2TPv3 extension, or would it need
a particular solution with an specific protocol end-to-end ?


== (Henry)

*> It seems you want to emulate various ISDN services*. 

Yes, I'm trying to emulate most of ISDN services over an IP network,
including circuit, X.25 and Frame-Relay modes.

== (Henry)

> You seem concerned that *if a frame-based protocol such as X.25 is
used
> then you will have timeouts*.

Yes. To emulate X.25 mode over IP I must avoid timer problems.


== (Henry)
_> I honestly think you should try ignoring this_. You mention NGN IP
below,
> and I think you are probably using a fairly good network. If you *send
> raw frames end to end* then life will *be* a lot *simpler* for you.
_If you
> try to get involved in Layer 2 then there will be a lots of
provisioning_
> etc.

As I mention above, I haven't guarantees about network performance. So,
problems
with timers is quite possible. 

== (Henry)
*> What are you going to do if the ISDN call is carrying streamed data,
not
> HDLC-like frames? This is a much bigger problem. We have some TDMoIP
> technology to do this*. It recovers the network clock so that frame
> slippage can be avoided. _If_ course this _needs_ a good network, with
_> jitter levels typically below 50ms_.

> I assume that if the call is a voice call then you will use a voice
> codec with echo cancellation etc.

We carry common voice call over RTP/RTCP. However, we have to resolve
problems
with TSSI and RDTD services. In RDTD, _differential delay_ must not be
upper 50 ms.
Are TDMoIP able to guarantee this requirement over any IP network?


== (Henry)
> On the D-channel you can use ISDN User Adaptation Layer RFC4233-IUA-
to
> forward D-channel packets to a Media Gateway Controller that would
> handle them. Are you using RFC4233?

We have raised different proposals to support ISDN services over IP 
networks.

Certainly, we use IUA/SCTP (or TCP) to forward Q.931 from SG to MGC, and

H.248 to manage SG.

For voice calls, we use RTP/RTCP, although we have to solve problems 
with some services like
RDTD and TSSI, which have too strict delay requerements.

To transport X.25 frames (X.25 ISDN mode) we have to decide between 
several options (we need
an IP network, so that MPLS solutions are not considered):
- XOT (delivering over IP only PLP packets)
- Defining an modification for IUA, adapted to LAPB (insteed of Q.921)
- LAPB frames over GRE
- And HDLCPWs over L2TPv3, for LAPB frames
(options like "ISO/IEC 8881 + draft-ietf-l2tpext-pwe3-ethernet"  have 
beed ruled out
because they are not efficient)


To transport FR frames, we have less options (Q.933 over IP is not
defined):
- Defining an modification for IUA, adapted to LAPF (insteed of Q.921)
- LAPF frames over GRE
- And FRPWs over L2TPv3, for LAPF frames


I'm open to any suggestions.


_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext

_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext