Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/iplpdn/pppext-iplpdn-minutes-93jul.txt

Text File | 1993-09-10 | 9KB | 257 lines

CURRENT_MEETING_REPORT_

Reported by Fred Baker/ACC and George Clapp/Ameritech

Minutes of the joint session of IPLPDN and PPPEXT Working Groups


RFC 1356 X.25

RFC 1356 will be recommended as a Draft Standard.  There have been six
to seven implementations with no interoperability problems.

RFC 1294 has already been recommended for advancement to Draft Standard.


Protocol Discrimination

A PPP NLPID has been requested by the PPPEXT Working Group for use in
NLPID-encapsulated protocols.  The request has unfortunately gotten lost
in the mail.  Bill Simpson will resend the request to Lyman Chapin, who
has agreed to make it happen.  There is a separate issue with the ISDN
Lower Layer Compatibility Information Element; George Clapp will pursue
obtaining a value indicating PPP.


   o IP/Circuit Switched Service
     The question was seriously discussed whether we in fact need a
     default way to send IP over circuit switched services such as ISDN
     B channel.  It was observed that the question is malformed; we do
     not need a default way to send IP over a V.35 or V.11 interface,
     for example.  We need a way to speak to a peer system at the data
     link layer, which might be a Frame Relay or X.25 switch, or a peer
     host or router.
     We already have standards for PPP, Frame Relay, and X.25.  In
     different contexts, we are willing to run any of the three
     standards.
     This approach is recommended for circuit switched services:

      -  Systems must implement PPP, on the assumption that circuit
         switched communications are generally [host or router] to [host
         or router].

      -  Systems may implement other protocols such as Frame Relay or
         X.25

     The implication here is not that all calls will be initiated with
     PPP signaling and encapsulation, but that PPP signaling and
     encapsulation will be a universally implemented option.

                                   1





Multi-link Protocol



The header will be changed to one of the following:


            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |M|P|0|0| Sequence Number     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o M - More - 1 if a non-terminal fragment, 0 if the last fragment
   o P - Phase - has the same value on each fragment of a message,
     inverts from message to message
   o 0 - Reserved, must be zero
   o Sequence Number - 0 to 4095 fragment sequence number


            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |F|L|0|0| Sequence Number     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   o F - First - 1 if first fragment in a message
   o L - Last - 1 if last fragment in a message
   o 0 - Reserved, must be zero
   o Sequence Number - 0 to 4095 fragment sequence number


Including a link in the multi-link group is done by authenticating
inclusion in the multi-link group and negotiation of the Fragmentation
Protocol Control Protocol (FPCP).

Removing a link from the multi-link group is done by terminating the
FPCP on that link.

In the worst case, receiver recovery from a sequence error (fragment
loss) is done by sending an FPCP Configure Request in the OPEN state on
all links; in most cases, one of the following two conditions is
sufficient to detect and step past the loss of a sequenced fragment:


  1. Receipt of a frame on each link with a successor to the omitted
     sequence number.

  2. Expiration of an implementation-specific receipt timer; this should
     be long enough to handle the relevant timing issues.


There is a separate LCP negotiation, authentication step, and set of
Control Protocol negotiations for each link in a multi-link group.

                                   2





Several other options were considered, including the use of the RFC 1294
fragmentation header, which was agreed to in the March meeting; RFC 1294
provides the same essential features as this but requires four octets,
and additionally provides only compatibility with RFC 1294.


PPP on Frame Relay

We need to have an Applicability Statement for PPP over Frame Relay, in
view of the existence of RFC 1294.  The default encapsulation is as
described in the minutes of the March IETF. Various edits were
recommended, which will be included in an updated draft, including
collapsing of Keith Sklower's parameter negotiation document (with
attribution as author) into this document.

LQM should not be used on a Frame Relay DLCI.


PPP on X.25

We need to have an Applicability Statement for PPP over X.25 in view of
RFCs 877 and 1356.  Various edits were recommended, which will be
included in an updated draft.  Primary attention should be given to
reducing the size of the X.25 frame.

LQM should not be used in this environment.

The PPP NLPID SHOULD be placed in the call user data rather than being
carried in each frame.


PPP/ISDN

Bill Simpson presented his paper on PPP over ISDN.

PPP must have the same default MRU (and any other defaults) on ISDN as
in other environments.  Keith Sklower will publish his IPLPDN document,
``Determination of Encapsulation of Multi-Protocol Datagrams in Circuit
Switched Environment,'' and Bill indicates that he would like to copy
some of the technical material from it into this document.  It was
decided that he would reference Keith's document.


Parameter Negotiation

Keith and Bill will merge their documents.  This document should be
separate from the PPP over foo documents, as it is desired to be placed
on the standards track, and the PPP over foo documents may not be placed
on that track.

                                   3





Attendees


George Abe               [e-mail]
Nick Alfano              [e-mail]
Bernt Allonen            [e-mail]
Frederik Andersen        [e-mail]
Arun Arunkumar           [e-mail]
Cynthia Bagwell          [e-mail]
Fred Baker               [e-mail]
Per Bilse                [e-mail]
Carsten Bormann          [e-mail]
Rich Bowen               [e-mail]
Robert Braden            [e-mail]
Caralyn Brown            [e-mail]
Steve Buchko             [e-mail]
Les Clyne                [e-mail]
Thomas Cordetti          [e-mail]
Geert Jan de Groot       [e-mail]
Marty Del Vecchio        [e-mail]
Bob Downs                [e-mail]
Ian Duncan               [e-mail]
Toerless Eckert          [e-mail]
Kjeld Borch Egevang      [e-mail]
Ed Ellesson              [e-mail]
Shoji Fukutomi           [e-mail]
Eugene Geer              [e-mail]
David Ginsburg           [e-mail]
Marcel Graf              [e-mail]
Chris Gunner             [e-mail]
Joel Halpern             [e-mail]
Jari Hamalainen          [e-mail]
Patrick Hanel            [e-mail]
Ken Hayward              [e-mail]
Gerd Holzhauer           [e-mail]
John Hopkins             [e-mail]
Chris Howard             [e-mail]
David Jacobson           [e-mail]
Philip Jones             [e-mail]
Frank Kastenholz         [e-mail]
Rajeev Kochhar           [e-mail]
Dave Langley             [e-mail]
Eliot Lear               [e-mail]
Paolo Malara             [e-mail]
Andrew Malis             [e-mail]
Shehzad Merchant         [e-mail]
Gerry Meyer              [e-mail]
William Miskovetz        [e-mail]
Keith Mitchell           [e-mail]
Daniel Myers             [e-mail]
Drew Perkins             [e-mail]
David Piscitello         [e-mail]
Lars Poulsen             [e-mail]
Dave Rand                [e-mail]

                                   4





Juergen Rauschenbach     [e-mail]
Tony Richards            [e-mail]
Benny Rodrig             [e-mail]
Miguel Sanz              [e-mail]
Henk Sennema             [e-mail]
Keith Sklower            [e-mail]
Timon Sloane             [e-mail]
Kenneth Smith            [e-mail]
Henk Steenman            [e-mail]
Richard Sweatt           [e-mail]
Antoine Trannoy          [e-mail]
Hisao Uose               [e-mail]
Rene van der Hauw        [e-mail]
Willem van der Scheun    [e-mail]
Ruediger Volk            [e-mail]
Scott Wasson             [e-mail]
Kirk Williams            [e-mail]
Rachel Willmer           [e-mail]
Sam Wilson               [e-mail]
Paul Zawada              [e-mail]



                                   5