2.3.7 Point-to-Point Protocol Extensions (pppext)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99

Chair(s):

Karl Fox <karl@extant.net>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:ietf-ppp@merit.edu
To Subscribe: ietf-ppp-request@merit.edu
Archive: ftp://merit.edu/pub/ietf-ppp-archive

Description of Working Group:

Note: A separate list has been set up for L2TP discussions:

L2TP Discussions:l2tp@ipsec.org To Subscribe: l2tp-request@ipsec.org Archive: http://www.ipsec.org/email/l2tp/

The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The group will actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value.

The Layer 2 Tunneling Protocol (L2TP) is a brand-new protocol for tunneling PPP sessions over various network types. The group will actively advance the L2TP base protocol through the standards process and consider extensions to the base protocol.

Goals and Milestones:

Aug 99

  

Advance L2TP MIB to Proposed Standard

Aug 99

  

Advance SDL draft to Experimental

Aug 99

  

Advance AODI draft to Proposed Standard

Dec 99

  

Advance CHAP (RFC 1994) to Standard

Dec 99

  

Advance Multilink (RFC 1990) to Standard

Dec 99

  

Advance LQM (RFC 1989) to Standard

Dec 99

  

Advance IPCP (RFC 1332) to Draft Standard

Dec 99

  

Advance BCP (RFC 1638) to Draft Standard

Dec 99

  

Advance CCP (RFC 1962) to Draft Standard

Dec 99

  

Advance ECP (RFC 1968) to Draft Standard

Dec 99

  

Advance PPP over ISDN (RFC 1618) to Draft Standard

Mar 00

  

Advance L2TP to Draft Standard

Mar 00

  

Advance LCP MIB (RFC 1471) to Draft Standard

Mar 00

  

Advance CHAP MIB (RFC 1472) to Draft Standard

Mar 00

  

Advance IPCP MIB (RFC 1473) to Draft Standard

Mar 00

  

Advance BCP MIB (RFC 1474) to Draft Standard

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1332

PS

The PPP Internet Protocol Control Protocol (IPCP)

RFC1378

PS

The PPP AppleTalk Control Protocol (ATCP)

RFC1377

PS

The PPP OSI Network Layer Control Protocol (OSINLCP)

RFC1472

PS

The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol

RFC1473

PS

The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol

RFC1471

PS

The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol

RFC1474

PS

The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol

RFC1553

PS

Compressing IPX Headers Over WAN Media (CIPX)

RFC1552

PS

The PPP Internetwork Packet Exchange Control Protocol (IPXCP)

RFC1547

 

Requirements for an Internet Standard Point-to-Point Protocol

RFC1570

PS

PPP LCP Extensions

RFC1598

PS

PPP in X.25

RFC1618

PS

PPP over ISDN

RFC1638

PS

PPP Bridging Control Protocol (BCP)

RFC1663

PS

PPP Reliable Transmission

RFC1661

S

The Point-to-Point Protocol (PPP)

RFC1662

S

PPP in HDLC-like Framing

RFC1764

PS

The PPP XNS IDP Control Protocol (XNSCP)

RFC1763

PS

The PPP Banyan Vines Control Protocol (BVCP)

RFC1762

DS

The PPP DECnet Phase IV Control Protocol (DNCP)

RFC1968

PS

The PPP Encryption Control Protocol (ECP)

RFC1962

PS

The PPP Compression Control Protocol (CCP)

RFC1973

PS

PPP in Frame Relay

RFC1975

 

PPP Magnalink Variable Resource Compression

RFC1977

 

PPP BSD Compression Protocol

RFC1979

 

PPP Deflate Protocol

RFC1967

 

PPP LZS-DCP Compression Protocol (LZS-DCP)

RFC1974

 

PPP Stac LZS Compression Protocol

RFC1976

 

PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)

RFC1963

 

PPP Serial Data Transport Protocol (SDTP)

RFC1990

DS

The PPP Multilink Protocol (MP)

RFC1989

DS

PPP Link Quality Monitoring

RFC1978

 

PPP Predictor Compression Protocol

RFC1993

 

PPP Gandalf FZA Compression Protocol

RFC1994

DS

PPP Challenge Handshake Authentication Protocol (CHAP)

RFC2043

PS

The PPP SNA Control Protocol (SNACP)

RFC2097

PS

The PPP NetBIOS Frames Control Protocol (NBFCP)

RFC2118

 

Microsoft Point-To-Point Compression (MPPC) Protocol

RFC2125

PS

The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)

RFC2153

 

PPP Vendor Extensions

RFC2290

PS

Mobile-IPv4 Configuration Option for PPP IPCP

RFC2284

PS

PPP Extensible Authentication Protocol (EAP)

RFC2363

PS

PPP Over FUNI

RFC2364

PS

PPP over AAL5

RFC2419

PS

The PPP DES Encryption Protocol, Version 2 (DESE-bis)

RFC2420

PS

The PPP Triple-DES Encryption Protocol (3DESE)

RFC2433

 

Microsoft PPP CHAP Extensions

RFC2484

PS

PPP LCP Internationalization Configuration Option

RFC2509

PS

IP Header Compression over PPP

RFC2615

PS

PPP over SONET/SDH

Current Meeting Report

PPP Extensions Working Group Minutes

45th IETF-Oslo, Norway

Wednesday, July 14, 1999, 1530-1730

Chair: Karl Fox karl@extant.net
Reported by Matt Holdrege matt@ascend.com

Discussion of PPPEXT Standards Track Document Status
Karl Fox <karl@extant.net>

Karl explained the rules for moving documents along the standards track. Then we reviewed each protocol.

To PS
- L2TP
- L2TP MIB
- AODI

To DS
- IPCP
- BCP
- CCP
- ECP
- PPP over ISDN
- BACP
- LCP Internationalization
- LCP Extensions
- X.25
- Frame Relay
- AAL5
- Appletalk CP

To STD
- CHAP
- MP
- LQM

To HISTORIC
- DNCP
- SNA
- Reliable Mode
- XNS

First phase is taking L2TP MIB and AODI to proposed standard. Second phase is taking IPCP, IPXCP, BCP, VJ, CCP, ISDN, X.25 and BACP to Draft Standard. CHAP and MP and LQM to full standard.

SDP will be punted to the IPSEC working group.

Future Directions of L2TP
- draft-ietf-pppext-l2tp-16.txt
- Mark Townsley <townsley@cisco.com>

Draft 16 was approved as a proposed standard but is still in the editors queue. Clerical errors are still being accepted. The RFC number should be published in about a month.

For promotion to draft standard, we must prove multiple interoperable implementations. We can also identify items that might need to be changed or added.

It was noted that it is not in anyone's best interest that we rush to draft standard status. Realistically, if there are changes, it will take a year to complete testing before we move to draft standard.

Should we have a separate UDP port for control and data channels? It would require a new port registered with IANA. All sessions within a tunnel would use the same ports. Alternatively, we could use ADC which is more complex, but individual sessions within a tunnel may use different ports.

Flow control issues: Limiting number of packet in transit to help with statefull protocols.

Congestion Management BOF draft-balakrishnan-cm-00.txt may be useful for the L2TP control channel, but is not advisable for the data channel.

What to do if an AVP that is defined for one message is received in another? The same AVP may have a different meaning in two different messages. Thus the M-bit rules apply. If you want to do this, an extensions draft must be written and approved as if it were a brand new AVP.

PPP over Simple Data Link (SDL) using raw lightwave channels with ATM-like framing
- draft-ietf-pppext-sdl-pol-00.txt
- James Carlson <carlson@ironbridgenetworks.com>
- Enrique Hernandez-Valencia <enrique@lucent.com>
- Nevin Jones <nrjones@lucent.com>

Concerns were expressed about the CRC since it wasn't specified in the draft. It was explained that the existing SDL draft made it clear.

It was expressed that existing PPP over SONET was more efficient than SDL at the existing Internet packet size samples. Also that that SDL was addressing an error scenario that doesn't impact users.

Another concern was expressed about the lightwave transport and that this draft doesn't address it.

We could not determine the status of this document here and that discussion will move to the list.

Mobile PPP
draft-ietf-pppext-mppp-00.txt
M. Chuah <chuah@lucent.com>

This draft was presented last meeting, but its purpose wasn't explained well. The draft was changed in respect to L2TP flow control and is dependent on future changes to L2TP flow control.

L2TP works fine in a mobile network EXCEPT when moving from one Radio node to another. This draft adds a new AVP to L2TP to enable this function. This Mobile AVP is an option for LNS's that wish to support this feature.

If user auth is required by an operator upon handoff, this new draft supports it. This draft is also consistent with Mobile IP as used in wireless networks.

It was pointed out that ACCM should be in the SLI rather than the SRRQ. The author will consider that change.

L2TP MIB
- draft-ietf-pppext-l2tp-mib-04.txt
- Evan Caves <evan@acc.com>

The big change in this draft is about payload flow control being removed. There will be another draft to make a few minor corrections.

The IP tunnel MIB will be moving to proposed standard soon which is good since the L2TP MIB is an extension of this draft.

L2TP ATM Access Network Extensions
- draft-ietf-pppext-l2tp-atmext-01.txt
- Yves T'Joens <yves.tjoens@alcatel.be>

Draft 01 adds a few new extensions and will be updated now that L2TP has been approved and is stable.

Always On Dynamic ISDN (AODI)
- draft-ietf-pppext-aodi-01.txt
- Matt Holdrege <holdrege@lucent.com> [5 minutes]

Not many updates; mostly small issues. New draft went to the list. One comment: PPP over X.25 never included the D-channel consideration. Trying to move this forward quickly.

Providing QoS in Multilink PPP
- M. Chuah <chuah@lucent.com>
- Enrique Hernandez-Valencia <enrique@lucent.com>

MCML only specifies how to interleave packets on multiple links. But how to schedule interleaving events. Did not mention how to map PPP QoS to different links carrying traffic with varying characteristics.

PPP over Virtually Concatenated SONET/SDH Low and High Order Channels
- Nevin Jones <nrjones@lucent.com>

The draft will be submitted in the near future. The authors wish to communicate to the transport standards bodies that the IETF sees this as desirable so that they can see the need for adding support for combining lower and higher order channels in their specifications.

Irfan Ali fia225@email.mot.com presented draft-pazhyannur-avt-pppmux-00.txt

It was noted that AAL2 muxing went through the same issues and it found a lot of complexity. But this draft tries to avoid those problems with a very simple approach.

Karl Fox <karl@extant.net>
Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3

Slides

None received.