ters include peak rates, average rates, maximal
burst size, etc. Possibly, equivalent measures
could be applied, like the effective bandwidth.
- Explicit path specification attribute. An ex-
 plicit path assignment for a traffic trunk is
 a path that is specified through “operator”
 action (e.g. management procedures). Such a
 path can be completely or partially specified.
 Path preference rules may be associated with
 explicit paths, telling whether the explicit
 path is “mandatory” (has to be followed) or
 “optional” (other paths could be selected in
 case sufficient resources are not available on
 the preferred path).
- Resource class affinity attribute. This attribute
 can be used to specify which resource types
 that can be explicitly included or excluded
 from the path through which the traffic trunk
 is routed. If no affinity attribute is given a
 “don’t care” condition is assumed. Routing
 traffic trunks onto resources have to take these
 attributes into account, matching the require-
 ments.
- Adaptivity attribute. As network state and
 traffic state change over time, more optimal
 routes of traffic trunks could appear. Setting
 this attribute tells whether or not the route can
 be re-optimised for the traffic trunk. However,
 appropriate thresholds should be given avoid-
 ing too frequent changes of routing.
- Load distribution attribute. In case several
 traffic trunks are used between the pair of
 nodes, the load distribution attribute can tell
 whether or not the load (traffic trunk) can be
 distributed on these trunks. In general the
 packet order should be maintained, implying
 that packets belonging to the same traffic flow
 are transferred on the same traffic trunk.
- Priority attribute. This attribute gives the rela-
 tive importance of the traffic trunk. The value
 can be used to determine the order in which
 trunks are assigned to paths under establish-
 ment and failure situations. Priorities will also
 be used together with pre-emption.
- Pre-emption attribute. The value of this
 attribute tells whether or not a traffic trunk can
 preempt another traffic trunk, and whether or
 not another traffic trunk can preempt a spe-
 cific traffic trunk. This will assist to ensure
 that high priority traffic trunks are routed
 through even though the capacity is not suffi-
 cient to handle all traffic trunks.
- Resilience attribute. The resilience attribute
 gives the behaviour of a traffic trunk when
 faults occur along the path followed by a traf-
fic trunk. In case of fault the traffic trunk
could be rerouted or not depending on the
value of this attribute. For rerouting, the
constraints given (e.g. by affinity) could be
observed or not.
- Policing attribute. The value of this attribute
 tells which actions to take when the traffic on
 the trunk is non-compliant (excessive traffic).
 Examples of actions are packet dropping (rate
 limiting), packet tagging and packet shaping.
In addition to attributes related to traffic trunks,
some attributes are also related to resources (fre-
quently thought of as the links). These attributes
are ([RFC2702]):
- Maximum allocation multiplier attribute. The
 value of this attribute tells what proportion of
 the link and buffer capacity that is available.
 Then “over-allocation” could be achieved (as
 well as “under-allocation”).
- Resource class attributes. The attributes
 express the resource type (e.g. thought of as
 colours). These are matched with the traffic
 trunk affinity attribute when finding paths
 onto which the traffic trunks are routed.
Basic operations on traffic trunks are
([RFC2702]):
- Establish a traffic trunk;
- Activate a traffic trunk, to start forwarding
 packets;
- Deactivate a traffic trunk;
- Modify attributes for a traffic trunk;
- Reroute a traffic trunk;
- Remove a traffic trunk.
In addition to these basic operations, a few more,
like policing and shaping could also be defined.
A traffic trunk is defined as unidirectional. As a
bidirectional transfer capability is commonly
asked for, two traffic trunks having the same end
points but passing packets in opposite directions
can be defined. In case these are always handled
as a unit, it is called a bidirectional traffic trunk
(they are established as an atomic operation and
one may not exist without the other). If a trunk is
routed through a different physical path than the
corresponding trunk in the opposite direction,
the bidirectional traffic trunk is called topologi-
cal asymmetric. Otherwise, it is called topologi-
cal symmetric.
MPLS is an essential component for carrying
out Traffic Engineering in IP-based networks.
A simple argument is its inherent feature to cir-
cumvent the “ordinary” IP packet handling in