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
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
Group, Ron da Silva has asked to step down as chair as his current day job will not allow him to devote the time necessary to be a WG chair. Carlos has been running a lot of the operations of this group as Secretary, and he has agreed to move into the vacant seat left by Ron. Carlos and Ignacio will continue to chair the group until its milestones are completed (with Carlos recusing himself as chair for those documents he remains co-editor on). Thanks to Ron for his leadership over the past year and a half, and please welcome Carlos to his new post. - Mark
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. On 9/4/2006 4:37 AM, Javi allegedly said the following: > One question related to transport of HDLC (or LAPB) frames over L2TPv3 > (+PWE3): > > What HDLC frames are delivered over PWs?, only frames I (Information),(Continue reading)
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 Carlos Pignataro escribió: > 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.(Continue reading)
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base Author(s) : E. Caves, et al. Filename : draft-ietf-l2tpext-l2tpmib-base-02.txt Pages : 55 Date : 2006-9-7 This document describes a portion of the Management Information Base (MIB) to manage the Layer Two Tunneling Protocol, Version 3 (L2TPv3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tpmib-base-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-l2tpmib-base-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt(Continue reading)
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
(Continue reading)
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.
(Continue reading)
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:fjmc <at> us.es](Continue reading)
>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. 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 >running on a very poor quality network then you might have to consider a >proprietary solution. 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(Continue reading)
RSS Feed7 | |
|---|---|
1 | |
1 | |
1 | |
2 | |
5 | |
1 | |
1 | |
5 | |
25 | |
1 | |
15 | |
5 | |
5 | |
1 | |
5 | |
7 | |
1 | |
1 | |
4 | |
2 | |
3 | |
10 | |
1 | |
1 | |
3 | |
1 | |
1 | |
1 | |
3 | |
1 | |
5 | |
6 | |
11 | |
1 | |
5 | |
3 | |
2 | |
7 | |
5 | |
5 | |
25 | |
8 | |
4 | |
9 | |
5 | |
4 | |
4 | |
6 | |
6 | |
12 | |
5 | |
10 | |
27 | |
10 | |
12 | |
13 | |
20 | |
9 | |
3 | |
2 | |
1 | |
5 | |
14 | |
9 | |
28 | |
6 | |
5 | |
7 | |
1 | |
1 | |
4 | |
1 | |
11 | |
5 | |
7 | |
11 | |
11 | |
5 | |
11 | |
9 | |
9 | |
10 | |
7 | |
7 | |
9 | |
6 | |
56 | |
5 | |
4 | |
27 | |
33 | |
16 | |
33 | |
17 | |
1 |
