home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
iplpdn
/
pppext-iplpdn-minutes-93mar.txt
< prev
Wrap
Text File
|
1993-05-04
|
5KB
|
140 lines
CURRENT_MEETING_REPORT_
Reported by Fred Baker/ACC
Minutes of the joint sessions of IPLPDN and PPPEXT Working Groups
The two Working Groups met in joint session to discuss protocol
specifications common to both. Since the objectives and requirements of
the two Working Groups differ in some key respects, there was
considerable difference of opinion at the outset. The Chairs wish to
congratulate the various parties in the discussions on the level of
personal restraint and professionalism displayed during the discussions.
Would that there were even more of both.
Two subjects were discussed: how to share load among a set of parallel
links to increase apparent bandwidth and potentially reduce latency
between two sites, and how the IPLPDN Group might best avail itself of
the facilities found in PPP negotiation.
Load Sharing
Two proposals for load sharing were outlined. Fred Baker briefly
reminded the Group of his previous proposal to use ISO Multilink
Procedures as described in ISO 7776 and ISO 7428. Keith Sklower
discussed his proposal to use the existing RFC1294 segmentation
encapsulation to achieve traffic ordering in much the same way that
multilink does, and provide the option of data fragmentation and
reassembly.
The consensus of the Group preferred Keith's approach, but recommended
that two currently unused bits be assigned the purposes of the ISO
Multilink Protocol's RESET and RESET ACKNOWLEDGE flags to facilitate
synchronization of links when bringing them into and out of service.
Concerns were raised about the size of the resequencing buffer, most
especially when the link speeds are mismatched. Joel Halpern and Craig
Fox will provide input to Keith concerning a solution to this that they
worked out; Keith will appropriately edit his proposal for further
discussion on the IPLPDN mailing list.
PPP Parameter Negotiation for Frame Relay
The consensus we reached is encapsulated in the following points.
o By default, Frame Relay services will conform to RFC1294. This
implies that if two systems attempt to communicate, one using
RFC1294 and the other using PPP services, the system desiring PPP
services will use RFC1294 instead.
o There may be a requirement to negotiate services in both PVC and
SVC environments.
1
o Negotiation uses PPP negotiation frames encapsulated in a manner
conforming to RFC1294.
o The system receiving a PPP negotiation frame may choose to ignore
and discard it, either because the system is old or because it is
configured to do so. Once both systems have decided to negotiate,
the full PPP negotiation FSM takes effect.
o There may be LCP Configuration Options to modify the encapsulation
on a virtual circuit.
o We jointly agree to specify this.
o The PPP encapsulations of choice are:
First choice:
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Field | NLPID (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PID |
Second choice:
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Field | PAD (00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLPID=80 | OUI = 00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI = 00-00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Packet Type TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PID |
Use of the first encapsulation is subject to assignment of an NLPID
value by X3S3. Bill Simpson reports that Lyman Chapin feels has
assigned a block of NLPID values to the IAB for IETF purposes.
o By default, data which has an existing RFC1294 encapsulation should
be encapsulated as in RFC1294, unless the two systems agree, using
LCP negotiation, to use the above encapsulation for data. Data
which has no defined RFC1294 encapsulation but has a PPP
encapsulation must use the above for data regardless of the outcome
of that negotiation. Data which has no defined PPP encapsulation
2
but has an RFC1294 encapsulation must use the latter regardless of
the outcome of the negotiation.
o Because it is specified in the PPP FSM, all data flow stops during
LCP negotiation. Data streams having PPP NCPs do not restart until
their PPP NCP has reached the OPEN state. Data Streams not having
PPP NCPs may restart upon the LCP reaching the open state. As in
PPP, subsequent renegotiation of an NCP affects only its data.
Keith Sklower and Bill Simpson have agreed to merge their efforts and
their current proposals to implement this consensus. The output will be
discussed on the IPLPDN list.
IPLPDN and PPPEXT expect to have two joint meetings at the Amsterdam
IETF.
3