need for flow support in internetwork layer

[[e-mail] (Robert "Woody" Woodburn)]

This may be an aside, but I thought I'd comment anyway...

    I wonder if you are referring to my comments of a few weeks ago here.
    If so, I think we have to agree that transport layer information can be
    relied on if and only if sufficient such information is present in
    every message to associate it with the pre-negotiated flow - ie, no
    network layer fragmentation (read: MTU discovery is supported in the
    routers and used by the hosts). That has some implications for CLNP if
    IPv7 is a flavor of CLNP.

IDPR has had the same problem in its flows.  The existing gated implementation
ignores the problem, by only looking at addresses, not port numbers, although
the hooks are there to also use ports.  Fragmentation makes it impossible to
identify a particular session (which seems to be a reasonable granularity for
a flow), and because we were using encapsulation, fragmentation became more
of a problem.  (no, we didn't implement path discovery for a variety of
reasons...)  I believe I discuss some of these issues in RFC1241, which might 
be useful if you haven't read it.

    3)	given that we do, how do we negotiate them?

Do they have to be negotiated?  I made the flow ID 32 bits in 1241, but that
was to handle problems with ICMP.  Dave Mills didn't like this, but I was
thinking of hop-by-hop negotiation at the time.  Now I think that the benefits
of a short identifier are outweighed by the complexity of the ID negotiation.
And besides, if ICMP is going to be changed to return more of the header, the
need for short flow IDs goes away.  IDPR uses a 64bit flow ID, which is
assigned by a policy gateway.  the first part of the ID is the unique gateway
identifier, and the other 32 bits are a locally assigned number.  Would
assignment of globally unique identifiers to flows be out of the question?

When Dave and I bounced this back and forth, he convinced me that dynamic
generation of a truly globally unique ID was a very hard problem.  Generation
of a 64bit "ticket-to-ride" could be done through "ticket servers" who own a
portion of the space, but there could be a lot of overhead there.  Going one
step further to something more like IDPR, if a fixed length part is globally
assigned, then what happens when things get bigger than we ever thought they
would in another decade?

    4)	given that we do, how do we identify traffic as relating to them?

	There are two obvious approaches: a flow identifier and a
	combination of information that would be matched by a fast path
	matcher.

IDPR uses a combination.  It matches on header information to assign the
packet to a flow and encapsulate it.  Subsequent gateways only look at
the flow ID.

wood y