[comp.archives] [list.iplpdn] minutes of the IPLPDN meeting in St. Louis

clapp@uunet.uu.net (George Clapp) (04/02/91)

Archive-name: internet/public-datanets/malis-frame-relay-intro/1991-03-26
Archive: ccv1.bbn.com:/pub/ietf-frame-relay-intro.ps [128.89.4.29]
Original-posting-by: meritec!clapp@uunet.uu.net (George Clapp)
Original-subject: minutes of the IPLPDN meeting in St. Louis
Reposted-by: emv@msen.com (Edward Vielmetti, MSEN)

The following are the minutes of the IPLPDN meeting.  Please let me
know if you have any questions.

George Clapp
phone: 708-806-8318
fax:   708-806-8292
email: meritec!clapp@uunet.uu.net

*************************************************************************

CURRENT MEETING REPORT

Reported by George Clapp / Ameritech

OPENING REMARKS

This was the second meeting of the IP over Large Public Data Networks
Working Group and the following was the agenda of the meeting:

Wednesday, March 13, 1991
     AM
          o Tutorial on Frame Relay (FR) by Andy Malis
          o Discussion of encapsulation and protocol multiplexing over FR
     PM
          o Tutorial on ISDN (Wayne Heinmiller and Jim Loehndorf)
          o Discussion of encapsulation and protocol multiplexing over ISDN

Thursday, March 14, 1991
     AM
          o Joint meeting with the BGP Working Group to discuss the use
            of BGP for routing and address resolution (Paul Tsuchiya)
          o Continued discussion of encapsulation and protocol multiplexing

WEDNESDAY MORNING, MARCH 13, 1991

FRAME RELAY TUTORIAL

Due to airplane troubles, Andy Malis had been able in time to present
his tutorial on Frame Relay during the plenary the previous evening,
so he kindly presented his talk during the first half of Wednesday
morning.  (Andy also presented this tutorial during the Friday morning
plenary, and a copy of his presentation is included in the proceedings
for that session.  A postscript version is online for anonymous ftp at
"pub/ietf-frame-relay-intro.ps" on ccv1.bbn.com)  The presentation
was an excellent preparation for the discussion of encapsulation
and protocol multiplexing.

ENCAPSULATION AND PROTOCOL MULTIPLEXING FOR FRAME RELAY

After the tutorial Caralyn Brown presented the following
encapsulation and protocol multiplexing scheme for Frame Relay.  The
proposal is documented in the draft "Multiprotocol Interconnect over
Frame Relay Networks", which is available online on ccv1.bbn.com
for anonymous ftp as "pub/multiprotocol.txt".  (A copy of the viewgraphs
of Caralyn's presentation accompanies these minutes.)

                          +--------------------+
                          |  LAPD flag (0x7E)  |
                          +--------------------+
                          |        DLCI        |
                          +--------------------+
                          |        DLCI...     |
                          +--------------------+
                          |  Format Identifier |
                          +--------------------+
                          |FCSP| Origin_Media  |
                          +--------------------+
                          |        ...         |
                          +--------------------+
                          |        Info        |
                          +--------------------+
                          |        ...         |
                          +--------------------+
                          |  Frame Ck Sequence |
                          +--------------------+
                          |  Frame Ck Sequence |
                          +--------------------+
                          |  LAPD flag (0x7E)  |
                          +--------------------+

FCSP: Frame Check Sequence Preservation

The Format Identifier indicates whether 802.2 & SNAP or a bridged MAC
frame follows, and the Origin_Media indicates the type of the bridged
MAC frame.  If a routed packet is being carried, then the Origin_Media
value is set to zero and the 802.2 LLC Type 1 and SNAP headers follow.
The Ethertype of the SNAP header is used to indicate the type of the
routed packet.  This proposal was modified by Charles Carvalho,
who proposed that the 802.2/SNAP headers be eliminated by carrying both
the bridged MAC frame type and the Ethertype values within a combined
Format Identifier/Origin_Media field.  There was qualified acceptance
of this approach before the group broke for lunch.

WEDNESDAY AFTERNOON, MARCH 13, 1991

ISDN TUTORIAL AND PROPOSAL

Following lunch, Wayne Heinmiller with Jim Loehndorf presented
an overview tutorial on ISDN (a copy of the presentation accompanies
these minutes).  The presentation led into a talk by Dory Leifer
of proposed encapsulation, protocol multiplexing, and fragmentation
schemes for circuit and LAPD ISDN.  The proposal is documented in
the draft "A Subnetwork Control Protocol for ISDN Circuit-Switching",
which is available online on terminator.cc.umich.edu as "~ftp/isdn"
for anonymous ftp.  Further discussion was deferred until the next
morning.

THURSDAY MORNING, MARCH 14, 1991

JOINT MEETING WITH BGP WORKING GROUP

Paul Tsuchiya led a joint meeting of the IPLPDN and BGP Working Groups.
(A copy of his slides accompany the minutes.)  Paul proposed alternative
mechanisms to support a simple and effective way for routers to obtain
routing and address resolution information from BGP servers.  He also
proposed an extension to BGP in which both the next hop IP address and
the hardware, or SubNetwork Point of Attachment (SNPA), address would
be given to the requesting router.

Members of the BGP group were concerned with potential conflicts
between policies of the Autonomous Systems that might be traversed
by a packet.  This discussion remained unresolved and Paul volunteered
to work towards a solution in time for the next meeting.

ENCAPSULATION AND PROTOCOL MULTIPLEXING

After the break, IPLPDN met separately from the BGP Working Group
and Caralyn Brown presented the modified proposal for encapsulation
and protocol multiplexing over Frame Relay.  (A copy of the viewgraph
of the proposal accompanies the minutes.)  

                          +--------------------+
                          |  LAPD flag (0x7E)  |
                          +--------------------+
                          |        DLCI        |
                          +--------------------+
                          |        DLCI...     |
                          +--------------------+
                          |  Format ID 1       |
                          +--------------------+
                          |  Format ID 2       |
                          +--------------------+
                          |        ...         |
                          +--------------------+
                          |        Info        |
                          +--------------------+
                          |        ...         |
                          +--------------------+
                          |  Frame Ck Sequence |
                          +--------------------+
                          |  Frame Ck Sequence |
                          +--------------------+
                          |  LAPD flag (0x7E)  |
                          +--------------------+

If the value of the Format Identifier is less than 1024 decimal (0x0400)
then the field is used to encode the MAC type and the code points are
identical to those in internet-draft "Point to Point Protocol Extensions
for Bridging".  This is shown below.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0 | 0 | 0 | 0 | 0 | 0 | F | Z |          MAC TYPE             |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

The F bit is used to indicate the presence of the MAC Frame Check
Sequence, and the Z bit is used to indicate zero compression.

If the value of the Format Identifier is 1024 decimal (0x0400)
then the 802.2 LLC header follows the Format Identifier field,
as shown below.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |              DSAP             |             SSAP              |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |            Control            |
     +---+---+---+---+---+---+---+---+

If the value of the Format Identifier is greater than 1024 decimal
(0x0400) then the encoded Format Identifier is equivalent to the
Digital-Intel-Xerox (DIX) Ethertype, as shown below.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |               Digital-Intel-Xerox (DIX) Ethertype             |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Caralyn continued with a discusion of mechanisms for address resolution
and proposed that ARP be used to discover the DLCI associated
with an IP address.  She also proposed an extension to ARP named
Inverse ARP to discover the IP address associated with a DLCI.
This latter proposal is documented in the draft "Inverse Address Resolution
Protocol", which is available online by anonymous ftp on ccv1.bbn.com
as "pub/inarp.txt".

After some discussion and modifications, all of these proposals appeared
to be acceptable to the group.

IP OVER ISDN

Dory Leifer continued with a discussion of the following issues:

  o  Fragmentation - do we need it considering the access network
     may impose small max frames?
     Resolution: further study

  o  End-to-end link state for switched access, i.e., XID frames?
     Resolution: no

  o  ACK mode support or at least include CONTROL field for Q.921
     compatibility?
     Resolution: the group accepted the CONTROL field with a pad
                 in the encapsulation scheme.  The revised scheme
                 is shown below.

                               +-----------+
                               |   flag    |
                   +-----------+-----------+
                   |   DLCI    |  DLCI..   |
                   +-----------+-----------+
                   |  Control  |    PAD    |
                   +-----------+-----------+
                   | Format ID | Format ID |
                   +-----------+-----------+
                   |   info..  |   ...     |
                   +-----------+-----------+
                   |    ...    |   ...     |
                   +-----------+-----------+
                   |    CRC    |    CRC    |
                   +-----------+-----------+
                   |   flag    |
                   +-----------+

  o  Discovery protocol of Max frame size?
     No resolution

  o  code point for in-connection management protocol?
     No resolution

At this point, time ran out and the group adjourned until the next meeting
in Atlanta, GA, in July 1991.