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