[NSIS] message routing methods in GIMPS

["Hancock, Robert" <robert.hancock at roke.co.uk>]

Dear all,

The current GIMPS specification basically 
includes 2 modes:
*) Datagram (D) mode sends messages to upstream
or downstream signalling peers; the way it routes
messages to those peers is based on an object
in the message which is basically the flow 
n-tuple (the message goes the same route as the
n-tuple and rules are applied to make sure that
messages which are not following the route of the
n-tuple are discarded.)
*) Connection (C) mode sends messages to peers
which have been explicitly discovered by D mode
exchanges.

There are at least two scenarios where the concept
of D mode routing following the flow N-tuple is
possibly inadequate:
*) explicit routing of signalling
*) routing of 'edge discovery' messages in the
NATFW NSLP (see previous mail).

To be 'friendly' to this, I would propose to
restructure the D mode description into two parts:
1) A common part: handles exchanging peer addressing
information, negotiating C mode protocol selection,
cookie exchanges for DoS prevention, router alert/
interception handling.
2) A 'message routing method' specific part: handles
the decision about how to get the D mode message to
(or towards) the next hop, and how to validate its
correct routing there.

C mode would be unchanged. (C mode connections would
probably have to remember which D mode routing method
was used to set them up, but that is probably required
anyway and is missing in the current spec.) To add 
either of the other routing methods above, you would 
write a new part (2), but part (1) would be unchanged.
Conceptually, this would be like having a family of 
D modes.

Initially, I would like just to restructure the D mode
specification along these lines without adding any new
methods. There is no real complexity change in the 
protocol itself, it is nearly just an editorial change. 
(The main difference is that the object called 'Flow 
Routing Information' would be renamed 'Message Routing 
Information' and in the initial pure-path-coupled case 
would be able to contain just a "Flow Identifier" [in 
framework-speak]. Apart from anything else, this would
avoid giving the impression that we were doing explicit
routing of flows, which came up during the early review.)

We should discuss whether to add additional message
routing methods at the interim meeting. (In the meantime,
people could comment on whether they think this restructuring
is good or bad.)

Robert H.

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis