Subject: RE: Do we want a new L2TP Header?

From: "Chen, David" <[email-masked]>
Date: Tue, 22 May 2001 14:50:34 -0400

How does this relate to the L2tp header?

The QoS enforcement seems only to do with the media (UDP, ATM...)
For IP as the media, DS seems make sense to differentiate
different tunnel/session's traffic characteristic between LAC and LNS.

How about other media?

--- David

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 12:16 PM
To: Chen, David
Cc: 'Umesh Sirsiwal'; [email-masked]
Subject: Re: Do we want a new L2TP Header?

Yes, via draft-ietf-l2tpext-ds-03.txt, L2TP signalling may be used to
identify a DSCP for a session. As for flows within that session, you may
identify these and apply them to your policy however you wish. One
popular feature is to "reflect" the inner DSCP to the outer header. You
could also classify traffic based on ports or your favorite traffic
classification algorithm and apply this to your outer IP header. This
policing/enforcing is really a vendor-specific implementation issue. 

- Mark

"Chen, David" wrote:
> 
> To make IP QoS works, it has two major functions.
> One is setup/modify/teardown negotiation;
> the other is policing/enforcing.
> 
> This darft seems only provide the first phase.
> It seems rely on the L2tp over UDP to modify
> outer IP header's DS to perform the policing/enforcing.
> 
> --- David
> 
> -----Original Message-----
> From: Umesh Sirsiwal [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 11:02 AM
> To: W. Mark Townsley; [email-masked]
> Subject: RE: Do we want a new L2TP Header?
> 
> I will agree that a fixed header would make microcoded
> engines lot easier to implement and will improve overall
> performance.
> 
> When we are at it... I have another question with respect
> to L2TP. That involves ineraction of L2TP with
> draft-ietf-l2tpext-ds-03.txt.
> This draft addresses issue with respect to DS based differentiation
> between different tunnels which means differentiation
> between different subscribers. In a QoS enabled world
> it is essential to differentiate between differnt types
> of traffic from the same subscriber. That can be used
> for VoIP, video delivery, etc.
> 
> I know it is somewhat confusing with respect to layering
> violations. However, I do not know where else to address
> this issue. L2TP provides L2 tunneling, and should also
> address issues with respect to differentiation of different
> types of traffic in a tunnel.
> 
> Comments?
> 
> -Umesh
> 
> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 3:00 PM
> To: [email-masked]
> Subject: Do we want a new L2TP Header?
> 
> L2TP currently has two classes of headers. (1) Those defined in RFC2661,
> and (2) those defined in draft-ietf-l2tpext-l2tphc-03.txt. Within each
> class, we have more than one header we have to recognize, based on the
> bits set in the beginning of the header or signaling that occurred at
> session establishment (particularly for the case of l2tphc).
> 
> Even in light of this complexity, we enjoy exceptional interoperability
> among so many independent implementations that I lost count a long time
> ago. Also, like many protocols, the variability defined in the original
> specification has begun to converge into a more static subset of fields
> that we most often see in L2TP deployments today. Rather than letting
> nature continue to take its course for better or worse and require all
> new implementations to continue to include code for what are
> increasingly rare expectations, I would like to get a sense of the group
> as to whether we should entertain definition of a new, fixed, header
> with L2TP. Many of you have approached me offline about this, so I
> thought that bringing the idea to the list would be appropriate.
> 
> An easy transition to a new header would be aided by the signaling that
> we all support. We would simply advertise support for the new header at
> tunnel and session establishment, much like we do for l2tphc. The hope
> would be that, one day, all implementations would converge on this
> header and that our hardware, ASICs, etc. only have to support this
> rather than than the various headers we have today that are identified
> on a per-packet basis.
> 
> In the past, I have rejected a major change like this, citing that any
> improvement in the header would not be worth disrupting our existing
> interoperable codebases. However, with the open-heart surgery that is
> ongoing in RFC2661 to separate the L2TP tunneling plane from PPP and
> more and more people pushing L2TP processing down into microcode and
> ASICs (essentially requiring a rewrite of our data paths anyway), I
> wonder now is the time to go ahead and apply what we have learned over
> the past 5 years with hope of paving a way for the next 5 years.
> 
> I have a set of ideas that have culminated over the past couple of years
> that I would be happy to post to the list to initiate discussion, but
> only if there is interest and consensus that definition of a new header
> for L2TP is a Good Thing to do.
> 
> Comments appreciated,
> 
> - Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 22 May 2001 11:59:22 -0700

> How does this relate to the L2tp header?

Doesn't really, but threads get off track sometimes :-)