Previous

Content

Next 

3.4.- Attributes of a TT  

Attributes of a TT are:
 
  1. Traffic parameter attributes.
     
  2. Generic Path selection and management attributes.
     
  3. Priority attribute.
     
  4. Preemption attribute.
     
  5. Resilience attribute.
     
  6. Policing atttribute.
Traffic parameter attributes
 
These attributes are used to capture the characteristics of the traffic stream, i.e., the FEC to be transported through the TT. Such characteristics include: peak rates, average rates, permisible burst size, etc. These parameters indicate the resource requeriments of the TT. They are useful for resource allocation and congestion avoidance through anticipatory policies.
 
Generic Path selection and management attributes
 
These attributes define the rules for selecting the route taken by a TT and the rules to maintain the paths that are already established. When there are no resources requeriments or restrictions associated with a TT, then a topology driven protocol can be used to select its path. When resource requeriments or restrictions exist, a constrained-based routing scheme should be used for path selection.
 
Path management concerns aspects related to the maintenance of paths traversed by TTs. It is desirable that infrastructure implementation can dynamically reconfigure itself, to adapt to some notion of change in "system state".
 
To guide the path selection and management process, a set of attributes are required. They are described as follows:
 
   

 
  1. Administratively specified explicit paths
     
      These are paths configured through operator actions. The paths can be complete or partial. They are complete when all required hops between endpoints are specified. They are partial when only a subset of intermediate hops are specified. In this case, the underlying protocols are required to complete the paths. When an administraticely specified explicit path is inconsistent or illogical, the underlying protocols should be able to detect such inconsistencies and provide appropriate feedback.

    An administratively specified explicit path can be "mandatory" or "non-mandatory".

    If one of these paths is configured with "mandatory" attribute, only that path must be used. If the path is topological infeasible, or available resources are inadequate, the path setup process fails; i.e., an alternate path cannot be used regardless of prevailing circumstance . When a mandatory path is succesfully instantiated it cannot be changed except through deletion and instantation of a new path.

    When a path is selected as "non-mandatory", the path should be used if feasible. Otherwise, an alternate path can be chosen by the underlying protocol.
         		  
  2. Resource Class Affinity atttributes
     
      These attributes define the class of resources that can be explicitly included or excluded from the path of a TT. These are specified as a sequence of tuples:

    <resource-class, affinity>; <resource-class, affinity>; ...

    The resource-class parameter identifies a resource class for which an affinity relationship is defined with respect to the TT. The affinity parameter may be a binary variable which takes one of the following values: 1) explicit inclusion, or 2) explicit exclusion. This way it is possible to use boolean expressions to specify the resource class affinities associated with a given TT.

    If no resource class afinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the TT and all resources.
         		  
  3. Adaptivity attribute
     
      In some scenarios, it might be desirable to dynamically change the paths of certain TTs in response to changes in network state. This process is called re-optimization. These changes can be: new resources become available, failed resources become reactivated, allocated resources become deallocated and more efficient paths become available.

    An adaptivity attribute associated with a TT indicates whether the trunk is subject to re-optimization. The attribute is a binary variable which tales one of the following values: 1) permit re-optimization., or 2) disable re-optimization. When re-optimization is enabled a TT can be re-routed through different paths by the underlying protocols in response to changes in network state. When re-optimization is disabled, the TT is "pinned" to its established path and cannot be re-routed in response to changes in network state.

    To promote stability, an MPLS implementation should not be too reactive to the evolutionary dynamics of the network. At the same time, it must adapt fast enough so that optimal use can be made of network assets. This implies that the frequency of re-optimization should be administratively configurable to allow for tunning.

    It should be noted that re-optimization is distinct from resilience. Formally, it can be stated that adaptivity to state evolution through re-optimization implies resilience to failures, whereas resilience to failures does not imply general adaptivity through re-optimization to state changes.
         		  
  4. Load distribution across parallel TTs
     
      When the aggregate traffic between two nodes is such that no single link can carry the load, the problem can be addressed by instantiating multiple TTs between the two nodes, such that each TT carries a portion of the aggregate traffic. In this case, it would be useful to have some atttribute that can be used to indicate the relative proportion of traffic to be carried by each TT. The underlying protocols will then map the load onto the TTs according to the specified proportions. It is also desirable to maintain packet ordering between packets belonging to the same microflow.  
Priority attribute
This attribute defines the relative importance of TTs. In a constraint-based routing framework priorities become very important because they can be used to determine the order in which path selection is done for TTs, at connection establishment and under fault scenarios. Priorities are also useful when implementing preemption because they impose a partial order on the set of TTs, according to which preemptive policies can be actualized.
Preemption attribute
This attribute determines whether a TT can preempt another TT from a given path, and whether another TT can preempt a specific TT. Preemption is used to assure that high priority TTs can always be routed through relative favorable paths within a differentiated service environment.
Four preempt modes are defined:
  1. Preemptor enabled, when a TT can preempt lower priority TTs designated as preemptable.
     
  2. Non-preemptor, when a TT can not preempt other TTs.
     
  3. Preemptable, when a TT can be preempted by higher priority TTs which are preemptor enabled.
     
  4. Non-preemptable, when a TT cannot be preempted by any other TT.
Feasible preempt mode combinations are: (1,3); (1,4); (2,3); and (2,4). The (2,4) combination should be the default.
A TT, say "A", can preempt another TT, say "B", when the following conditions (all) hold:
 
  1. A has a relatively higher priority than B.
     
  2. A contends for a resource utilized by B.
     
  3. The resource cannot concurrently accomodate A and B based on certain decision criteria.
     
  4. A is preemptor enabled.
     
  5. B is preemptable.
Resilience attribute
 
This attribute determines the behavior of a TT under fault condition. Many recovery policies can be specified for TTs whose established paths are impacted by faults. Some examples are:
 
  1. Do not re-route the TT. This policy can be applied when multiple parallel LSPs are provisioned between two nodes and a failure of one LSP cause the TTs placed on it to be mapped onto the remaining LSPs according to some well defined policy.
     
  2. Re-route through a feasible path with enough resources. In none exists, the do not re-route.
     
  3. Re-route through any available path regardless of resource constraint.
     
  4. Other schemes including some combinations of the above.
Policing attribute
 
This attribute determines the actions that should be taken by the underlying protocols when a TT becomes non-complaint, that is, when a TT exceeds its contract as specified in the traffic parameters. The policing attributes can indicate whether a non-conformant TT should be rate limited, tagged, or forwarded without any policing action.
 
   

 
From a Traffic Engineering perspective, it is necessary to be able to administratively enable or disable traffic policing for each TT.
   

Previous

Content

Next