We assume that the primary mechanism for intercepting
messages is the use of the RAO.  The RAO contains a 16 bit
value field, within which 35 values have currently been
assigned by IANA.  It is open how to assign values for use
by GIMPS messages to optimise protocol processing, i.e.  to
minimise the amount of slow-path processing that nodes have
to carry out for messages they are not actually interested
in the content of.

There are two basic reasons why a GIMPS node might wish to
ignore a message:

1) because it is for a signaling application that the node
does not process;

2) because even though the signaling application is present
on the node, the interface on which the message arrives is
only processing signaling messages at the aggregate level
and not for individual flows (compare [15]).

Conversely, note that a node might wish to process a number
of different signaling applications, either because it was
genuinely multifunctional or because it processed several
versions of the same application.  (Note from Appendix C.1
that different versions are distinguished by different NSLP
identifiers.)

Some or all of this information could be encoded in the RAO
value field, which would then allow messages to be filtered
on the fast path.  There is a tradeoff between two
approaches here, whose evaluation depends on whether the
processing node is specialised or general purpose:

Fine-Grained: The signaling application (including specific
version) and aggregation level are directly identified in
the RAO value.  A specialised node which handles only a
single NSLP can efficiently ignore all other messages; a
general purpose node may have to match the RAO value in a
message against a long list of possible values.

Coarse-Grained: IANA allocates RAO values for 'popular'
applications or groups of applications (such as 'All QoS
Signaling Applications').  This speeds up the processing in
a general purpose node, but a specialised node may have to
carry out further processing on the GIMPS common header to
identify the precise messages it needs to consider.

These considerations imply that the RAO value should not be
tied directly to the NSLP id, but should be selected for the
application on broader considerations of likely deployment
scenarios.  Note that the exact NSLP is given in the GIMPS
common header, and some implementations may still be able to
process it on the fast path. The semantics of the node
dropping out of the signaling path are the same however the
filtering is done.

There is a special consideration in the case of the
aggregation level.  In this case, whether a message should
be processed depends on the network region it is in
(specifically, the link it is on). There are then two basic
possibilities:

1) All routers have essentially the same algorithm for which
messages they process, i.e.  all messages at aggregation
level 0. However, messages have their aggregation level
incremented on entry to an aggregation region and
decremented on exit.

2) Router interfaces are configured to process messages only
above a certain aggregation level and ignore all others. 
The aggregation level of a message is never changed;
signaling messages for end to end flows have level 0, but
signaling messages for aggregates are generated with a
higher level.

The first technique requires aggregating/deaggregating
routers to be configured with which of their interfaces lie
at which aggregation level, and also requires consistent
message rewriting at these boundaries.  The second technique
eliminates the rewriting, but requires interior routers to
be configured also.  It is not clear what the right
trade-off between these options is.