Re: HDLC frames delivered over PWs

Hi Henry,

On 9/12/2006 6:02 PM, Henry Brankin allegedly said the following:
> Javi
> 
> (Carlos - hope you don't mind me getting my oar in)

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

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

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.

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

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