Subject: RE: L2TPHC

From: "Daniel Feldman" <[email-masked]>
Date: Thu, 21 Jun 2001 09:41:07 +0200

Dear Andy,
thanks for the response. I think that there are some people at 3GPP
(myself included) who think about L2TPHC as a reality. We had no idea
you are thinking about dropping it. In fact, TCRTP
(draft-ietf-avt-tcrtp-02.txt) is based on L2TPHC, and it is one of the
possibilities being considered by the RAN3 of 3GPP for IP transport on
the UMTS Radio Access Network.
Take a look at this excerpt from the "IP Transport in UTRAN Work Task
Technical Report" (
ftp://ftp.3GPP.org/tsg_ran/WG3_Iu/TSGR3_21/Docs/R3011439_25933-101.zip
<ftp://ftp.3GPP.org/tsg_ran/WG3_Iu/TSGR3_21/Docs/R3011439_25933-101.zip>
):

"
6.2.3.3 PPP Multiplexed Frame Option Over L2TP Tunnel (TCRTP)
        In cases where a routed WAN interface is required, one may still
use PPPmux, but tunnel it via L2TP. This protocol is called Tunnelled
Compressed RTP (TCRTP).
        L2TP tunnels should be used to tunnel the cUDP payloads end to
end. This is a natural choice since cUDP payloads are PPP payloads, and
L2TP allows tunnelled transport of PPP payloads. L2TP includes methods
for tunnelling messages used in PPP session establishment such as NCP.
This allows the procedures of RFC 2509 to be used for negotiating the
use of cUDP within a tunnel and to negotiate compression/decompression
parameters to be used for the cUDP flow.
        A companion draft describes a method of compressing L2TP tunnel
headers from 36 bytes (including the IP/UDP/L2TP headers) to 21 bytes.
L2TPHC packets include an IP header, using the L2TPHC IP protocol id.
The UDP header is omitted, and the L2TPHC header is reduced to 1 byte.
The added overhead is now 21 bytes of the IP header.
        Enhancements to CRTP are not needed for cUDP header compression.
        A more bandwidth efficient way to send TCRTP over a PPP link is
to compress the L2TP IP header with cUDP (this is referred to as
cTCRTP).
"
        This is part of the study area. Afterwards, cTCRTP is proposed
as a tool to provide what is called End-to-End quality of service, when
PPPmux needs to be used to reduce bandwidth (and improve QoS) and we
want to ensure the PPPmux session goes till the RNC (Base Station
Controller) through a Routed Network. See this other excerpt:

"
6.3.7 UTRAN End-to-End QoS Approach
        The end-to-end approach provides QoS differentiation for the
UTRAN traffic flows inside the UTRAN NEs. User plane protocol proposals
like CIP and LIPE rely on this principle. But also the PPPmux based
proposal can provide an e2e approach by tunnelling the PPP protocol via
L2TP (TCRTP). The queuing and scheduling is performed inside the NEs
under control of the UTRAN equipment manufacturer. In the IP backbone
only one QoS class is needed for UTRAN traffic, which could be the
expedited forwarding (EF) class of Diffserv.
        The QoS differentiation is simpler because the quality classes
are well known inside the NEs and the complex management function to
distribute the QoS parameter in the IP network can be avoided.
        However, for the implementation dependent O&M traffic the head
of line blocking problem still exists. In case the edge router provides
on data link layer only one QoS class, IP fragmentation at the O&M
centre could be configured to a reasonable IP packet size. If the edge
router provides at least two QoS classes (ML-PPP) the best effort O&M
traffic could easily be distinguished from the tunnel carrying the other
UTRAN traffic.
"

    Someone may implement it after all. In fact, my company is working
on it.

    Warm regards,

        Daniel Feldman.

-----Original Message-----
From: Andy Valencia [ mailto:[email-masked] <mailto:[email-masked]>
]
Sent: Wednesday, June 20, 2001 4:07 PM
To: Daniel Feldman
Cc: [email-masked]
Subject: Re: L2TPHC

>        Does anyone know what is the current status of L2TPHC?

Funny you should ask...

I thought it was past last call, but just a day or so ago the WG chair
sent
me a note, telling me that he wanted to pull the IP protocol number and
use
it for something else, and that I should re-edit the draft so the
protocol
number was TBD, and then go back to IANA and try, try again.

So my question to the WG is that, given that there's no implementation,
and
given that it's not important enough to hold onto its IP protocol
number,
why shouldn't we just bury it?  It's not like the IETF has a terrible
shortage of protocols.

OTOH, it wouldn't take much effort to edit the draft, send E-mail to
IANA,
and so forth and so on.  So if the WG would like to see it meander
onward,
I'll oblige.

Andy Valencia
[email-masked]

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 21 Jun 2001 00:18:33 -0700

I sent an implementation poll to the l2tp list a couple of weeks ago and didn't
hear a word back.

There has been some confusion as to what the IP protocol 115 was intended for in
the beginning, and what it is being used for now. So, I asked Andy if we could
make it TBA until the RFC moves forward and then let IANA decide. Here is some
more background to that decision.

The earlier version of L2TPHC actually included signalling of the IP protocol
number in call setup. Protocol 115 was obtained by Bernard Aboba a long time ago
for L2TP, not for L2TPHC. I believe it was I who actually made the suggestion to
Andy to use 115 for L2TPHC as we decided to run L2TP over UDP and felt
signalling the ID at startup was an unncessary complication. Perhaps that was
unwise.

Now, it seems that a number of people want to run L2TP (not HC) native over IP
as well, which is easy to understand as there is a protocol ID that seems
clearly designated for such in IANA's records. Hence, my query to the list to
see if people had begun to build implementations around it so that I could
better assess how to handle the contention. At a minimum, the description in the
IANA allocation would have to be changed so as not to be confusing. At a
maximum, we would move L2TPHC to TBA, and decide what best to do when it
actually advances to RFC, which is the typical procedure. The fact that we had
an ID lying around in the first place is a bit of a fluke.

I'm not sure why this confusion over the protocol ID made Andy wonder if his
work was worth being published. Perhaps the silence to my poll to the list was a
factor. Or that, again, he was being asked to edit the spec for the final time.
Obviously, we know now that there is more than just passing interest, and I have
no intention of letting the specification flounder any further if this is so.
This was actually my attempt at trying to resolve what I feel to be the last
remaining issue holding things up in my mind.

- Mark