ST and Connection IP Working Group Chairperson: Claudio Topolcic/BBN CURRENT MEETING REPORT Reported by Steve Casner, Allison Mankin and Claudio Topolcic ATTENDEES 1. Casner, Steve/casner@isi.edu 2. Clark, David/ddc@lcs.mit.edu 3. Fedor, Mark/fedor@nisc.nyser.net 4. Fox, Richard/rfox@suntan.tandem.com 5. Mankin, Allison/mankin@gateway.mitre.org 6. Mazraani, Tony/tonym@flora.wustl.edu 7. Park, Philippe/ppark@bbn.com 8. Parulkar, Guru/guru@flora.wustl.edu 9. Ramakrishnan, KK/rama@erlang.dec.com 10. Su, Zaw-Sing/zsu@sri.com 11. Toplocic, Claudio/topolcic@bbn.com 12. Wood, C. Philip/cpw@lanl.gov 13. Zhang, Lixia/lixia@lcs.mit.edu MINUTES The working group held three meetings. The meeting held during the day of Tuesday 25 July covered the high level and long term issues of connection oriented internet protocols. A second meeting was held on 26 July and covered a number of short term issues that need to be discussed to finalize the ST specification. Since all such issues hadn't been addressed, we held a third meeting during the morning of 27 July. Connection_oriented_internet_protocol_meeting_of_25_July_1989____ Three presentations were made. Lixia Zhang described the Flow Protocol (FP). Guru Parulkar gave a high level description of McHIP and Tony Mazraani described the McHIP protocol in more detail. These interactive presentations took the bulk of the day. Their content is not described here because they are better described in other documents. The suggestion that the working group adopt McHIP as its protocol led to a discussion about the future of McHIP, ST and the working group. Adopting a specific protocol would provide direction and structure. It would help keep the working group from endless debating. It would cause us to look at practical tradeoffs, etc. If a protocol is to be selected, then what should it be? The three choices appear to be McHIP, FP, and ST-2. It is somewhat easier to consider the relation between McHIP and ST-2. It would be optimal for both to evolve to a single protocol. This is reasonable since they are very similar. A significant difference is that ST-2 uses simplex connections to support conferences and McHIP uses omniplex connections. Another issue is that ST-2 is a very short term effort that will be operational in approximately six months, whereas McHIP is being developed in a somewhat longer schedule. McHIP is harder to compare with FP. They seem to be addressing different issues. Guru felt that FP is more a network protocol than an internet protocol because it does not fully address the use of pure connectionless networks. Claudio felt that McHIP addresses a number of protocol issues, while FP provides a resource management algorithm. Claudio felt that we could reasonably implement a version of McHIP that incorporates an FP style resource management scheme. Since time was running short, we decided to review our earlier ideas about the kinds of applications we wanted to support and the implications they have on the protocol. We decided to do this my E-mail. Phil will redistribute his messages entitled "Connection Oriented Protocol" and "Application Characterization" and Claudio will redistribute the minutes of the October 88 meeting. We will all read the first three sections of Guru's paper "The Next Generation of Internetworking". We will continue this discussion by E-mail. Phil and Guru will be in charge of writing a resulting paper. ST_protocol_specification_meeting_of_26_July_1989___ We went over the decisions we had made at the previous meeting and made a number of new decisions. Reviewing the agreements from the evening meeting on ST at Cocoa Beach in April: 3 o IP encapsulation: adopt Steve Casner's description. o Using IP-like headers: tabled for now; this can be retrofitted later. o Interface to next higher protocol: it is OK to make changes as long as there is a good reason for them. o We will need to write more documents than this one. o Control messages: it is OK to define new ones if they have different functions from the old ones. o ST.DG: eliminated. o Source route option: it can be an option in the connect message. For multipoint this might be too hard, but one could at least do incremental connections with a source route option on each. o Security: use SDNS. 4 New decisions to be made: o Aggregation: we just get rid of it. o Routing: the routing protocol is separate, just as for IP. o Next protocol field: should this just be part of the Extension field (EXT= PROTOCOL & PORT)? But should ST carry only the IP address and protocol field, as does IP, and let the higher-level protocol carry the port number, as does TCP? This assumes that the "open" message of the higher-level protocol is carried in the ST connect message. Then, in multipoint the ST header must have a list of addresses and NVP must have a list of ports. We have not answered how the elements of these two lists are associated nor decided this issue yet. o Keep PTP, or have a flag for automatic establishment of a reverse connection? Really, there should be three flags: 1. "Don't assign a group address, I promise not to have more than 2 parties in the connection." 2. "Do reverse HID assignment because there are only 2 parties now." 3. "Allocate bandwidth for the reverse path, i.e., automatically set up two connections at once. For multipoint, set up N-1 individual reverse connections." Would have to carry two flowspecs in the connect. An issue is that multiple connection names must be assigned. If the source does them all, then the connection name could wind up corresponding to (having the IP address of) a host that's no longer in the connection: Step 1. Host A opens a multipoint connection to hosts B and C with the reverse bit on. This creates connections named A1(A -> B,C), A2(B -> A), and A3 (C -> A). Step 2. Host C incrementally adds to connection A3 a path to host D, so we have A3 that connects C->A,D. Step 3. Host A drops out, leaving A3 as a connection from C to D (but the connection name includes A). Is this a killer? "A detail for the RFC writer to work out." o HID negotiation: Claudio will write up a reasonable one from his proposals for review, and we will use the static assignment subset implementation in practice. o Robustness measures: We need more link-state information exchange to 5 determine if ST connectivity is still established. That is, we must be able to tell if ST state was lost at the next agent. If there's a temporary net outage but no state loss, then just try a network repair (reallocate stream in WBnet). If a link goes down long enough to declare it dead, then back up hop by hop to do a pruned, depth-first search for alternate connection paths. The pruning is based on whatever routing information is available, so paths that are known to be insufficient are not tried. We will use Claudio's BREAK proposal for repairing the connection. ST_protocol_specification_meeting_of_27_July_1989___ Continuing the previous day's discussion: Robustness-level timeouts to keep track of agents going down: Exchange of keepalive control packets is per ST agent pair, which means per IP address pair. This only goes on if there is a connection up. An implementation may choose not to timeout if data is flowing but keepalives don't come in (fall behind). May want to have a separate timeout for each connection that is determined by the application: the connection is not flushed immediately upon declaring the link down, but only when the timeout expires after that (timeout may be zero). Applications should/may have their own data-dependent timeout, and then disconnect on failure.