Subject: L2TPHC changes

From: Andy Valencia <[email-masked]>
Date: Wed, 31 May 2000 17:00:54 -0700

From review comments on L2TPHC, a couple of slightly-more-than-trivial
changes appear to be appropriate for the draft.  They won't be hard to put
in, but Mark Townsley suggested I post them to the list first.

1. Session ID's rather than Tunnel ID's

Originally, L2TPHC was designed to permit a single session in a single
tunnel.  Early review input resulted in consensus that more than one session
should be supported.  Since multiple tunnels was a superset of everything
which could be done with multiple sessions, I put in the ability for more
than one tunnel, while keeping the requirement of a single session within
the tunnel.

Now that the dust has settled on L2TP, it seems like I should've done it the
other way around--one (and only one) tunnel, with sessions within.  The key
points Mark brought up are that (1) this saves you a number of messages, (2)
you don't have to do authentication, and (3) (this is the key one!) the flow
control mechanisms for control messages work a lot better when you're
dealing with numerous messages under a single tunnel.  Remember, flow
control is per tunnel, so if you bring up thousands of tunnels quickly,
you'll basically have no flow control to help you out.

(This is a problem latent in L2TP, too.  But since it's also latent in TCP,
I'm just not going to worry about it until we see specific problems.)

2. IP protocol number is implicit

The AVP for enabling L2TPHC indicated the IP protocol number.  I did this
primarily because I was having trouble getting an official protocol number.
A timely event got us this protocol number, so Mark thought it would be
tidier to keep it out of the way (we were mostly thinking about "things
which would make the IESG nervous).  So now the AVP does not have a Value
indicating the assigned protocol number.  The IP protocol number to use is
(implicitly) 115.

In tandem with the previous point (session versus tunnel ID's) this really
nails down the fact that you can not have distinct SA's (QOS associations,
or whatever) for different L2TP flows.  My own desire in the original L2TP
was to accomodate such associations this by permitting distinct UDP ports.
A similar desire in L2TPHC would have been to leave open the possibility of
using more than one IP protocol number (some sort of dynamic allocation
scheme, I guess).  Neither of these, in practice, looks like a viable avenue
given the current state of affairs.  If we want distinct associations, we
now require L2TP-specific knowledge in each protocol which wanted to
maintain such associations.  This is because there's no IP-generic way to
make distinct sessions within L2TP visible.

3. 16 bits of Session ID's

The ATM folks have argued (strongly) that they would like to L2TPHC on an
access concentrator in a mandatory tunneling environment.  I fiddled the
text around to accomodate this possibility a bit better--no big deal.

However, there is a need for more than 8 bits of sessions in such an
environment.  So I'm also planning on adding a second bit in the packet
header so the header can specify 0, 1, or 2 bytes of session ID.  This will,
of course, be required to match what was specified in the
L2TPHC-Assigned-Session-ID (previously known as L2TPHC-Assigned-Tunnel-ID,
and--of course--now exchanged during session establishment).

OK.  Break out your flame throwers... I'm ready. :->

BTW, I have departed Cisco, so make sure you direct mail to my current
[email-masked].

Regards,
Andy Valencia