RE: HDLC frames delivered over PWs

"Henry Brankin" <[email protected]>
Newsgroups gmane.ietf.l2tpext
Organization Virtual Access Ireland Limited
Message-ID <000701c6d6b7$2603a490$6564a8c0@HENRYSTECRA8200>
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 protected]] 
Sent: 12 September 2006 18:01
To: Carlos Pignataro
Cc: [email protected]
Subject: Re: [L2tpext] HDLC frames delivered over PWs


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

Carlos Pignataro escribió:
> Hello Javi,
>
> Please see inline.
>
> On 9/7/2006 6:40 AM, Javi allegedly said the following:
>   
>> 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).
>>     
>
> 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.


_______________________________________________
L2tpext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/l2tpext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.