Subject: Re: Class Extensions for PPP over AAL2 to Proposed Standard

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Nov 2001 14:29:51 -0500

Karl Fox <[email-masked]> writes:

> The PPPEXT Working Group recommends that Class Extensions for PPP over AAL2 
> (draft-ietf-pppext-ppp-over-aal2-class-00.txt) be advanced to Proposed 
> Standard.

Question: using the techniques described in this document, isn't it
possible that packets can be reordered while traversing the link? Does
this have implications for PPP when it is running over such a mode?
The document doesn't say anything about this. Should it?

Also,

> weighted fair CID scheduler. Implementations of PPP over AAL2 real time 
> transport extensions SHOULD implement AAL2 CPS CID schedulers the meet the 

s/the/that/ ?

> requirements of multi-class real time applications. 

Finally, the document doesn't seem to have a security considerations
section.

Thomas

---

From: Bruce A Thompson <[email-masked]>
Date: Thu, 08 Nov 2001 12:12:45 -0800

>The document doesn't say anything about this. Should it?

There is only one point in the hierarchy between PPP and the ATM transmission layer where reordering can occur when the Class Extensions for PPP over AAL2 are implemented.

When an AAL2 capable node implements the Class Extensions for PPP over AAL2 there will be reordering between classes / AAL2 CIDs at the I.363.2 CPS layer. This reordering is the same as the what occurs at the MLPPP Multi-link layer as the result of an implementation of RFC 2686 (The Multi-Class Extension to Multi-Link PPP). I could not find anything in RFC 2686 that talked about the implications of reordering between classes of packets belonging to the same PPP session. Draft-ietf-pppext-ppp-over-aal2-class-00.txt is an example of the queues-of-fragments approach of reducing latency referred to in RFC 2689 (Integrated Services over Low-bitrate Links). I think it's understood that when a queues-of-fragments approach is used to reduce latency for high priority packets in a PPP session, reordering will occur between classes.

Reordering can not occur within an AAL2 CID at the I.363.2 layer. The I.363.2 specification does not allow reordering of AAL2 payloads within a CID. Reordering also can not occur between cells of a VC at the ATM transmission layer (I.361). Again, the I.361 specification does not allow reordering of ATM cells within a virtual circuit.

>> transport extensions SHOULD implement AAL2 CPS CID schedulers the meet the 

Yes. We'll change it.

>Finally, the document doesn't seem to have a security considerations

We'll add this.

        Bruce T

>Thomas

Bruce Thompson
Cisco Systems
email: [email-masked]
office: (408)527-0446
home office: (408)868-0112
San Jose, CA