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.