Subject: Comments on draft-ietf-pppext-aal5-03.txt

From: "Ian Puleston" <[email-masked]>
Date: Wed, 17 Dec 1997 10:47:09 -0800

Here are some comments on the draft:

1. There is no mention of the type of ATM call to make. Must it be UBR, or
could it be nrt-VBR or ABR where supported (I'm not advocating anything
other than UBR - just pointing out that the RFC doesn't bar them) ?

2. Following discussions at the ADSL Forum, the document should probably say
that endpoints MUST implement Peak Cell Rate for transmission on UBR
connections.

A question here for any ATM experts around - is there also a case for
requiring the use of the EFCI (flow control) bit for the same reason ?

3. Sections 5 and 6 are inconsistently formatted:
- If Figure 2 was laid out like Figure 3, it would be more obvious how the
two are related.
- Figure 2 shows padding, Figure 3 doesn't (could imply that padding can be
stripped from an LLC encapsulated frame).
- Section 5 says that the PPP fields are specified in [1], but Section 6.
explicitly specifies those same fields.

4. In section 8. the paragraph on multi-point connections seems to have been
inserted in the middle of a discussion on encapsulation techniques.

5. The technique of detecting multi-point connections by looking for
multiple LCP responses with the same identifier from different framing
addresses seems to be flawed. Firstly there is no concept of a "framing
address" to differentiate different senders. Secondly, RFC1661 states: "For
retransmissions, the Identifier MAY remain unchanged". Therefore timing
problems on a point-to-point VC could lead to multiple responses with the
same identifier, which are normally silently discarded.

Note also that point-to-multipoint and multipoint-to-point VCs are
uni-directional so there would be no LCP responses.

Rather than trying to get PPP to detect a multipoint connection, would it
not be better to simply specify elsewhere that the ATM VC MUST be
point-to-point.

6. The 2nd paragraph of section 8 specifies the difference between
LLC-encapsulated and VC-muxed LCP frames, but needs to go farther. Can we
rely on checking the 1st octet to be FE or C0 to detect the encapsulation
technique, and if it is wrong what do we do? (discard the frame ?).

7. Also on Section 8. This section talks about a frame arriving in an
"alternate but equivalent data encapsulation". It is not obvious what this
means. Is it a frame with an LLC header when VC-muxing is in use and
vice-versa ? If it is something else then the recovery procedures mentioned
in the 1st paragraph are missing.

If that assumption is correct, then the prescribed technique for handling
the change in encapsulation technique (to re-enter link establishment phase)
probably won't do much good since the encapsulation technique is not
negotiated by LCP. Probably, such wrongly-encapsulated frames should just be
silently discarded.

---

From: "David Allan" <[email-masked]>
Date: Thu, 18 Dec 1997 09:34:39 -0500

Ian:

Re your points 1 and 2. These are really ATM transport issues and
orthogonal to the payload protocol spec. I don't think we need to
address them in this I-D. 

As for section 8, a review of my PPPEXT archive does not see a
discussion of the problem space so I'm going to make a few guesses and
hope someone straightens me out. 

If this is loss of session over a PVC then I'll admit I'd like to see a
more reliable technique for detection and recovery than hoping for an
encap configuration change ;-). It is reasonable to assume that if there
is an unexpected change in encap, then the link has been down and
re-establish procedures are required, but this really looks like a
problem with synchronizing provisioning/configuration. If I read section
4 points 1 and 2 correctly, an end point is not provisioned to receive
arbitrary encapsulation, it is either provisioned (PVC) or negotiated
(SVC) to a single style of encap and your statement that unexpected
encap should be silently discarded seems correct: receiving an
unexpected encapsulation is an error. It is certainly much simpler to
implement silent discard than the heuristic approach suggested, and this
would translate to simpler implementations AND more scalable
terminations. I would suggest that one (or some small number in a row)
of invalid PDUs (not the negotiated encap but otherwise well formed)
will result in pushing the link back to link establish state (or call
cleared for SVC) combined with silent discard of invalid PDUs on the
assumption that the correctly negotiated session has been lost (or under
abuse) and the rest is noise.

Cheers
Dave

>----------
>From: 	Ian Puleston[SMTP:[email-masked]]
>Sent: 	Wednesday, December 17, 1997 1:47 PM
>To: 	ietf-ppp
>Subject: 	Comments on draft-ietf-pppext-aal5-03.txt
>

---

From: [email-masked] (garage!gmg)
Date: Fri, 19 Dec 1997 13:46:58 -0500

Hi Ian,

Thank you for your comments. Attached below are my responses, which will
be applied to the -v04 text.

	George Gross

[snip E-mail header]
.
.
.
> other than UBR - just pointing out that the RFC doesn't bar them) ?

AAL5 traffic contract parameters are outside the scope of this document,
which only deals with the PPP encapsulation technique.

> that endpoints MUST implement Peak Cell Rate for transmission on UBR

Section 3, the phrase that begins:

	 "...does not impose any restrictions regarding transmission rate."

will be modified to say:

	"...does not impose any restrictions regarding transmission rate
	or the underlying ATM layer traffic descriptor parameters."

The Internet Draft can not get embroiled in specifying what is an appropriate
ATM traffic contract, as that depends on what is required by the application.

> explicitly specifies those same fields.

I have changed figure 3 to include the AAL5 (or FUNI) trailer information.

> inserted in the middle of a discussion on encapsulation techniques.

This paragraph has been deleted.
> not be better to simply specify elsewhere that the ATM VC MUST be

Section 3 third sentence already requires a point-to-point connection.

> negotiated by LCP. Probably, such wrongly-encapsulated frames should just be

This section of the document was weak, and it has been re-written to be more
explicit. These changes have been discussed among several of the co-authors.
Here is the revised text for the last two paragraphs in section 8:

Once PPP has entered the Network-layer Protocol phase, and
successfully negotiated a particular NCP for a PPP Protocol, if a
frame arrives using an alternate but equivalent data encapsulation
as defined in [4], then the PPP Link MUST:
.in +0.5i
.sp
For a SVC, immediately clear the call with cause value 111,
"protocol error, unspecified".
.sp
For a PVC: tear down the active NCPs,
re-enter the Link Establishment state,
silently drop all received packets except LCP Configure-Requests,
and send a new LCP Configure-Request using the peer's encapsulation technique.
If the local end point does not support remote peer's encapsulation
technique, then it MUST generate an error message and enter Termination state.
.sp
.in -0.5i
These policies prevent "black-holes" that occur when the peer loses state.
An implementation which requires PPP link configuration, and other
PPP negotiated features (such as authentication), MAY enter
Termination state when configuration fails.