Author: Rüdiger Geib
Operational BB stability
Scope
Operational BB stability is desireable right from the start. This chapter
specifies the behaviour of BB's during unexpected events. The specification
and implementation of these specifications should prevent a QBone BB from
ending in an undefined status for single reservations, interfaces or as
a whole system.
Introduction
Experience with operational communication networks shows that the first
thing to happen during the introduction of new systems and services often
is the unexpected event. It's a question of philosophy as to what's worse: a
system maintaining senseless state information or a system simply
quitting. Both reactions will in the end result in non-availability of
the service to be provided. To keep networks operational, defining the behaviour
of a system when dealing with unexpected events proved to be of great importance.
The remainder of this chapter deals with the specification of the behaviour
of a QBone BB during unexpected events.
An unexpected event for a QBone BB could be an unknown message (plan
for the future!), an unexpected message, a message containing an unknown,
an unexpected or a senseless parameter. Other unexpected events consist
of local or remote BB breakdowns or loss of communication. Finally, all
precautions will not prevent a BB from keeping wrong state information.
A mechanism how to adjust a BB data-base is required. Other unexpected events
as "route not supported (reaction RAA release), reactions on route
changes (Cancel) or loop detection (either TTL field or counter for identical
messages & discard after threshold) should be considered.
Unexpected and unknown messages
As a general measure, the receiption of an unknown or an unexpected message
should be logged together with the message.
Unknown Message
During the evolution of the QBone inter BB communication new messages may
be required.
An intermediate BB should ignore unknown inter BB messages and forward
them. It may set an Unknown_Message_Type tag.
A destination BB must discard an unknown message without further notice.
Unexpected Message
The behaviour of a BB on the receipton of an unexpected message may vary
depending on the message and the location of the BB. This may simplify
to track down protocol errors or DOS attacks. Whether or not such a log
file saves all or just the recent events is left to each individual implementation.
Note that during the following I expect that instead of RAA "reservation
0" only RAA "release" messages are used to release a reservation.
RAA without prior RAR
A BB must ignore and discard this message. Please note that this also
holds if a reservation is established and a "RAA release" is received without
an earlier "RAR reserve total 0". Should the latter situation occur, a
data-base synchronization may be initiated with the BB sending the unexpected
"RAA release".
Cancel without prior RAR
An intermediate BB should ignore and forward this Cancel message. Origin
and destination BBs must ignore and discard this message. A Cancel ACK
is returned to the sender.
Cancel ACK without prior Cancel
A BB must ignore and discard this message. A data-base synchronization
with the sending BB may be triggered.
Cancel for an RAR without prior RAA
Stop processing of and reset state for the RAR. Forward Cancel
as appropriate. Respond Cancel ACK to the sender.
E2E RAR without prior Core Tunnel set up
The destination BB ignores and discards this message. It returns a
RAA with flags set to RAR_Rejected and No_Core_Tunnel_Set_Up. A reason
code TLV may be added indicating No_Core_Tunnel_Set_Up again.
Unexpected and unknown parameters and parameter values
Unknown Parameters
During the evolution of the QBone inter BB communication new parameters
may be required.
If a message containing an unknown parameter can be processed if the
unknown parameter is ignored, a BB should do so. An intermediate BB should
continue to forward the message containing the unknown parameter. It should
set an Unknown_Parameter_Type tag followed by a TLV containing the name
of the unknown parameter. A destination BB should ignore the unknown parameter
and react if it was not present. If this reaction includes a response message,
an Unknown_Parameters_Received tag should be set followed by a TLV containing
the name of the unknown parameter.
Please note that here a whole new parameter is meant, not an individual
parameter value. For the reaction on an unknown parameter value, see below.
Unexpected Parameters
Any known parameter which is not expected in a message is ignored. Otherwise,
the BB reacts on or forwards the message as if the unexpected parameter
was not present.
Unknown Parameter Value
During the evolution of the QBone inter BB communication new parameter
values may be required. This also holds if coding space prior reserved
for extensions starts to be used.
If a message containing unknown parameter values can be processed if
the unknown parameter values are ignored, a BB should do so. An intermediate
BB should continue to forward the message containing the unknown parameter
value. A destination BB should ignore the unknown parameter value and react
as if it was not present.
Unexpected Parameter Values
In general, an unexpected parameter value should be logged together with
the message containing this value. This may simplify to track down protocol
errors or DOS attacks. Whether or not such a log file saves all or just
the recent events is left to each individual implementation.
Unreasonable Service Parameterization Object in RAR
Return RAA with the RAR accepted flag set to "Release".
Unreasonable Service Parameterization Object in RAA
Send a Cancel message to both directions (origin and destination).
Add a reason TLV stating "unreasonable RAA SPO values".
REM: Does somebody have a better idea? I don't think, that "ignore"
is useful here.
RAR with known RAR ID and a new GSID information
Doesn't have to be pathological. FFS.
RAR with known RAR ID and a new Ingress Router ID
Send a Cancel to the BB's administrating the existing and the new RAR.
Add a reason TLV stating "Route / reservation data base mismatch".
Messages with non-valid authentication
Discard and ignore. May trigger operator contact with adjecent BB's
administrating the relevant reservation / RAR ID.
Cancel containing only unknown RAR IDs
Discard and ignore. Return Cancel ACK.
Cancel ACK with unknown Cancel ID
Discard and ignore.