Subject: [L2tpext] HDLC frames delivered over PWs

From: Javi <[email-masked]>
Date: Mon, 04 Sep 2006 10:37:55 +0200

One question related to transport of HDLC (or LAPB) frames over L2TPv3
(+PWE3):

What HDLC frames are delivered over PWs?, only frames I (Information),
also RR and RNR, or all frames. It is a very important efficiency
factor. For instance, RR frames are continuously send, it would consume
too bandwidth in IP network.

Javi Muñoz

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

---

From: Javi <[email-masked]>
Date: Mon, 04 Sep 2006 10:25:55 +0200

Javi Muñoz

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 06 Sep 2006 21:37:04 -0400

Hello Javi,

All frames (think of it as a pseudo-wire); you can refer to RFC4349,
first paragraph of Section 4.1 and first bullet of Section 5:

http://tools.ietf.org/html/rfc4349#section-4.1

   The HDLCPW Type over L2TP is
   intended to operate in an "interface to interface" or "port to port"
   fashion, passing all HDLC data and control PDUs over the PW.  The
   HDLC PDU is stripped of flags and trailing FCS, bit/byte unstuffing
   is performed, and the remaining data, including the address, control,
   and protocol fields, is transported over the PW.

http://tools.ietf.org/html/rfc4349#section-5

      o HDLC data and control fields are transported transparently (see
        Section 4.1).  The specific negotiations and signaling of the
        protocol being transported are performed between Remote Systems
        transparently, and the LCCE does not participate in them.

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Javi <[email-masked]>
Date: Thu, 07 Sep 2006 12:40:13 +0200

Hello Carlos,

Thanks, I agree with you.

Howerver, my question tried to evaluate the efficiency of the method. If 
PWs deliver all HDLC frames, it means all RR/RNR frames (which are 
continuously transmitted)

So, HDLCPW would use too much resources in the IP network. Is it 
neccesary?. Perhaps, delivering only "I" frames may be enough if we use 
polling in LCCEs (so that, they answer to RR/RNR frames).

Thanks,

Javier Muñoz

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 08 Sep 2006 15:12:07 -0400

Hello Javi,

Please see inline.

> polling in LCCEs (so that, they answer to RR/RNR frames).

The HDLCPW encapsulation does not inspect a frame incoming on the AC
beyond HDLC flags and FCS, to maximize transparency.

This for instance allows what's described in the rfc:

   Since all packets are passed in a largely transparent manner over the
   HDLCPW, any protocol that has HDLC-like framing may utilize the
   HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay
   transport), X.25 (LAPB), etc.  In such cases, the negotiations and
   signaling of the specific protocols transported over the HDLCPW take
   place between the Remote Systems.
...
   In addition
   to the transport of HDLC frames, a natural application of HDLCPWs
   allows for the transport of any protocol using an HDLC-like framing.
...
      o HDLC data and control fields are transported transparently (see
        Section 4.1).  The specific negotiations and signaling of the

This is in turn in line with the PWE3 Architecture in rfc3935.

Thanks,

--Carlos.

---

From: Javi <[email-masked]>
Date: Tue, 12 Sep 2006 19:01:08 +0200

Hello Carlos,

Thanks again.

Thinking your explanation, I understand all HDLC frames are delivered 
over HDLCPWs in order to maximize transparency, so that they any 
protocol that has HDLC-like framing may utilize the HDLCPW mode, 
including PPP, Frame-Relay ("port to port" Frame-Relay  transport), X.25 
(LAPB), etc. This is an advantage, but delivering all frames (including 
RR, RNR, ...) is less efficient for the bandwidth.

On the other hand, in FRPW is necessary to inspect a frame incoming on 
the AC.

So, if you need a solution for a particular scenerio (i.e. LAPB over 
IP), would it be better (more efficient) to define an specific PW for 
this particular protocol that has HDLC-like framing?. For instance, a 
LAPB PW which only deliveres over PWs the necessary frames (usually, I 
frames).

---

From: "Henry Brankin" <[email-masked]>
Date: Tue, 12 Sep 2006 23:02:32 +0100

Javi

(Carlos - hope you don't mind me getting my oar in)

The overhead of RR frames in, for example, a LAPB link is very small in
the overall scheme of things. This additional overhead would only matter
when bandwidth is at a very high premium, and these days that it not
usual.

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. You might have to adjust
timers if you are using a poor network, or if you are traversing
continents.

I do not believe the IETF should be involved in solving problems
associated with very poor quality networks, or networks where bandwidth
is at a high premium - a reasonable level of quality and level of
bandwidth availability should be assumed. If it is the case that you are
running on a very poor quality network then you might have to consider a
proprietary solution.

I know that doesn't help - but it's my view.

Best regards
Henry Brankin

-----Original Message-----
From: Javi [mailto:[email-masked]] 
Sent: 12 September 2006 18:01
To: Carlos Pignataro
Cc: [email-masked]
Subject: Re: [L2tpext] HDLC frames delivered over PWs

Hello Carlos,

Thanks again.

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 12 Sep 2006 15:21:35 -0700

>bandwidth availability should be assumed.

This is most certainly not the case.

The IETF has been designing and deploying protocols on networks that
had very little bandwidth for a very, very long time.

As a WG, we must take into consideration cases where the network is
of low quality and/or with low bandwidth. In fact, we must take into
account details such as congestion and means to avoid it.

>If it is the case that you are

Actually, my suggestion would be a bit different: 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.

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.

Cheers,
-Ignacio

---

From: "Henry Brankin" <[email-masked]>
Date: Tue, 12 Sep 2006 23:26:39 +0100

Ignacio

OK, fair enough. I always saw l2tpv3 as needing a decent network.

I'll watch with interest.

Best regards
Henry

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]] 
Sent: 12 September 2006 23:22
To: [email-masked]
Cc: 'Javi'; [email-masked]
Subject: RE: [L2tpext] HDLC frames delivered over PWs

Cheers,
-Ignacio

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 12 Sep 2006 15:43:30 -0700

>I always saw l2tpv3 as needing a decent network.

There is some truth in your statement.

All versions of L2TP assume a network with relatively low loss,
low latency and sufficient bandwidth. After all, L2TP is emulating
a layer 2 link. The more errors/loss on that link, the worse it will
work (if at all).

Note that the term "relatively" as used above is intentionally vague
because there may be applications where higher layers take care of
losses or latency issues. What may be low loss/latency for one
application may be too high for another.

Cheers,
-Ignacio

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 12 Sep 2006 21:26:38 -0400

Hello Javi,

Please see inline.

> On the other hand, in FRPW is necessary to inspect a frame incoming on 

Note that FRPWs operate at the DLCI level, taking care of end-to-end
characteristics like status by terminating local management and using
SLIs with Circuit Status AVP between LCCEs. The FR specification points
to the HDLC one to operate in a port-to-port fashion.

> LAPB PW which only deliveres over PWs the necessary frames (usually, I 

Yes, but 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 section 6.2). Interested
people can define this specific PW Type by submitting an I-D.

Thanks,

--Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 12 Sep 2006 21:29:44 -0400

Hi Henry,

> (Carlos - hope you don't mind me getting my oar in)

Not at all, thank you for jumping in and commenting.

> running on a very poor quality network then you might have to consider a

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.

Thanks,

--Carlos.

---

From: Javi <[email-masked]>
Date: Wed, 13 Sep 2006 12:34:24 +0200

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
 
== (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
> 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.

---

From: Ignacio Goyret <[email-masked]>
Date: Wed, 13 Sep 2006 13:28:19 -0700

>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

---

From: "Y Prasad" <[email-masked]>
Date: Fri, 15 Sep 2006 11:12:05 +0530

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:[email-masked]] 
Sent: Wednesday, September 13, 2006 4:04 PM
To: [email-masked]; 'Carlos Pignataro'; Ignacio Goyret;
Javi
Cc: [email-masked]

Please see inline

==(Henry)

> 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)

== (Carlos)

> people can define this specific PW Type by submitting an I-D_.

*> There are usually situations where different types of optimizations
are
> imply, the first step is to qualify and somewhat quantify the actual
 
== (Ignacio Goyret)
/_*/_*> if there is a need for an application that would benefit from
eliminating

==(Ignacio Goyret)

== (Henry)

== (Henry)

== (Henry)
_> I honestly think you should try ignoring this_. You mention NGN IP
below,
> try to get involved in Layer 2 then there will be a lots of
provisioning_

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

> 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)

H.248 to manage SG.

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

---

From: Javi <[email-masked]>
Date: Fri, 15 Sep 2006 12:12:26 +0200

Hi Prasad,

> (Ns/NR).
Ignacio mentioned this issue: "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."
> So selectively avoiding certain control pkts over pw may not
> work. I guess the options are
>
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. So, "tune timeouts"
is not a valid solution, I think.

>    - Terminate x.25 on PEs and use pw only for data traffic.
That is the option we have been suggested. This means only delivering 
Information (I) X.25 Frames, which would need would need an extension of 
RFC4349.

Javier Muñoz

---

From: Javi <[email-masked]>
Date: Fri, 15 Sep 2006 18:14:33 +0200

Hello Ignacio,

One comment,

> RFC1151, Q.921, V.42 LAPM, etc. or you could use a much simpler ack
An option may be delivering L2TPv3 over TCP??, although it is not 
considered in RFC3931

Thanks,

Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 18 Sep 2006 12:58:02 -0700

>An option may be delivering L2TPv3 over TCP??, although it is not 

Using TCP to deliver L2TP penalizes all the protocols that do not need
reliable delivery of data frames. This is very inefficient for most
protocols to be considered. Among other problems, it duplicates effort
since the control channel contains its own method for reliable delivery,
and it is not scalable when multiple data streams are tunneled together.
Bottom line, TCP is not an alternative.

A much better alternative is to develop a mechanism to deliver data
frames reliably to be used only for those few protocols that need it.
This way, the protocols that do not need reliable delivery (the great
majority) do not have to be penalized with the performance penalty of
retransmissions, packet reordering, etc, etc.

---

From: Javi <[email-masked]>
Date: Fri, 22 Sep 2006 10:33:05 +0200

I'd like to suggest a more philosophical than technical question,

Nowadays, many relevant business consider protocols such as X.25, FR or 
even ISDN are obsolete and dead.

In that case, which is the justification for defining new RFCs such as 
RFC 4349 and RFC4591 related to these old protocols?

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 22 Sep 2006 11:13:20 -0400

Javi,

> RFC 4349 and RFC4591 related to these old protocols?

Because it's in L2tpext's Charter.

http://www.ietf.org/html.charters/l2tpext-charter.html
	II. L2TP Interaction with PWE3 for Pseudo-Wire Transport:
	In addition to tunneling PPP, L2TPEXT will develop protocol
	extensions necessary for the tunneling of specific
	"pseudo-wires" as defined in the PWE3 WG.

http://www.ietf.org/html.charters/pwe3-charter.html
	Specify the following PW types:
	Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH
	and Fibre Channel.
	...
	The PWE3 WG will do this in its entirety for MPLS PSNs, and the
	L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs.

Thanks,

--Carlos.

---

From: Javi <[email-masked]>
Date: Fri, 22 Sep 2006 17:39:43 +0200

Hello Carlos,

> Javi,
>
> Many relevant business consider protocols such as X.25, FR or 
I agree but it must have a practical justification, I think. Or is it 
only an theoretical analysis?. Which would be the useful purposes of 
these RFCs nowadays?

Thanks,

Javi

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 22 Sep 2006 12:13:53 -0400

Hello Javi,

Please see inline.

On 9/22/2006 11:39 AM, Javi allegedly said the following:
> I agree but it must have a practical justification, I think. 

Yes, deploying those technologies.

> Or is it 

You can find useful purposes in the first paragraph of pwe3's charter:

	Network transport service providers and their users are
	seeking to rationalize their networks by migrating their
	existing services and platforms onto IP or MPLS enabled
	IP packet switched networks (PSN). This migration requires
	communications services that can emulate the essential
	properties of traditional communications links over a PSN.

Thanks,

--Carlos.