Requirements for TE Over MPLS 5'4 9'0

1
Requirements for TE Over MPLS5.4 9.0

• 2000? 2? 10?
• ????? ???? ???

2
1. Contents

• 5.4 Basic Attributes of Traffic Trunks
• 5.5 Traffic Parameter Attributes
• 5.6 Generic Path Selection and Management
  Attributes
• 5.7-10 Priority, Preemption, Resilience, Policing
  Attributes
• 6.0 Resource Attributes Maximum Allocation
  Multiplier(MAM), Resource Class Attributes
• 7.0 Constraint-Based Routing

3
5.4 Basic Traffic Engineering Attributes of
Traffic Trunks

• Attribute of a traffic trunk
• A parameter assigned t it which influence its
  behavioral characteristics
• Can be Explicitly assigned(by administration
  action), or implicitly assigned(by underlying
  protocol when packet is mapped to FEC at ingress)
• Should be possible to administratively modify
• Basic Attributes for Traffic Trunk
• Traffic Parameter(1), Generic Path selection and
  maintenance(2), Priority(3), Preemption(4),
  Resilience(5), Policing(6) attributes
• (1),(6) analogous to usage parameter control in
  ATM
• (3),(4) be regarded as relational attributes

4
5.5 Traffic parameter attributes

• Traffic parameters
• Used to capture the characteristics(such as, peak
  rates, average rates, permissible burst size,
  etc) of the traffic streams(precisely FEC)
• Indicates the resource requirements of the
  traffic trunk ? so important
• Useful for resource allocation and congestion
  avoidance
• Bandwidth allocation a required bandwidth value
  can be computed from traffic parameters, in well
  known computational technique(ex, the theory of
  effective bandwidth)

5
5.6 Generic Path Selection and Management
Attributes

• Generic Path Selection and Management Attributes
• Defines the rules for selecting the route as well
  as the rules for maintenance of established paths
• 5.6.1 Administratively Specified Explicit Paths
• Configured through operator action
• Completely specified or partially specified
• Inconsistent or illogical by operator error ? the
  protocol should be detect it and provide feedback
• Path preference rule attributes Binary value
• Mandatory Topological infeasible, or available
  resources are inadequate ? path setup fails, NOT
  used alternative path,
• non-mandatory

6
5.6 Generic Path Selection and Management
Attributes cont.

• 5.6.2 Hierarchy of Preference Rules For
  Multi-Paths
• Useful to administratively specify a set of
  candidate explicit paths for a given traffic
  trunk and define a hierarchy of preference
  relations on the path
• 5.6.3 Resource Class Affinity Attributes
• Used to specify the class of resources which are
  to be explicitly included or excluded from the
  path of the traffic trunk,
• Used to impose additional constraint on the path,
  that is policing attribute

7
5.6 Generic Path Selection and Management
Attributes cont.

• 5.6.3 Resource Class Affinity Attributescnt.
• ltresource-class, affinitygtltresource-class,
  affinitygt
• Affinity parameter binary variable
• (1)Explicit inclusion, or (2)explicit exclusion
• Default dont care, if NOT specified
• Used to implement various policies, ex) traffic
  trunk within specific topological regions of the
  network
• Usage Constraint-based routing framework
• For explicit inclusion, prune all resources NOT
  belonging to the specified classes prior to
  performing path computation
• For explicit exclusion, prune all resources
  belonging to the specified class

8
5.6 Generic Path Selection and Management
Attributes cont.

• 5.6.4 Adaptivity Attribute
• Administrative control parameter that can be used
  to specify how traffic trunks respond to dynamic
  network state change
• Binary variable
• (1)permit re-optimization can be rerouted
• (2)disable re-optimization NOT rerouted,
  Pinned
• Stability
• Should NOT be too reactive to the dynamic state
• The frequency of re-optimization should be
  administratively configurable to allow for tuning
• Re-optimization versus Resilience
• Adaptivity to state evolution through
  re-optimization implies resilience to failures,
• BUT resilience to failures does NOT imply general
  adaptivity through re-optimization to state change

9
5.6 Generic Path Selection and Management
Attributes cont.

• 5.6.5 Load Distribution Across Parallel Traffic
  Trunks
• Problem NO single link can carry the load
• Solution appropriately divide the aggregate
  traffic into sub-streams and route them through
  multiple paths
• In MPLS, each traffic trunk carries a proportion
  of the aggregate traffic
• Flexible means of load assignment to multiple
  parallel traffic trunk is REQUIRED
• From an operational perspective
• Required some attributes that can be used to
  indicate the relative proportion of traffic to be
  carried
• Desirable to maintain packet ordering within the
  multiple parallel paths

10
5.7 Priority Attribute

• 5.7 Priority Attribute
• Defines the relative importance of traffic trunks
• Used to determine the order in which path
  selection is done at establishment and failure
• Also important in permitting preemption
• 5.8 Preemption Attribute
• Determines whether a traffic trunk can preempt
  another traffic trunk or a specific trunk
• Used to assure that high priority traffic trunks
  can always be routed through relatively favorable
  paths within DS environment
• Used to implement various prioritized restoration
  policy

11
5.8 Preemption Attribute cont.

• 5.8 Preemption Attribute cont.
• For preempt modes (1)preemptor enable,
  (2)non-preemptor, and (3)preemptable,
  (4)non-preemptable
• Mutually exclusive combination
• (1, 3), (1, 4), (2,3), (2, 4)(default)
• For traffic trunk A and B, A preempt B
  Under all following conditions hold
• 1) A relatively higher priority than B
• 2) A contends for a resource utilized by B
• 3) The resource cannot concurrently accommodate
  A and B
• 4) A is preemptor and B is preemptable
• Is NOT mandatory attribute under best effort
  Internet
• BUT, in DS it may be required
• Moreover in the optical interworking
  architecture, protection and restoration function
  are migrated to data network(such as gigabit and
  terabit LSR), it can be reduce restoration time
  costs

12
5.9 Resilience Attribute

• 5.9 Resilience Attribute
• Determines the behavior of traffic trunk under
  fault conditions
• The basic problems need to be addressed
• (1) fault detection, (2)fault notification, (3)
  recovery and service restoration
• Many recovery polices
• 1. Do not reroute the traffic trunk
• Ex) a survivability scheme may already exist,
  such as multiple parallel label switched path are
  provisioned between two nodes
• 2. Reroute through a feasible path with enough
  resources, if NONE exists, then do not reroute
• 3. Reroute through any available path regardless
  of resource constraints
• 4. Combination of the above

13
5.9 Resilience Attribute cont.

• 5.9 Resilience Attribute cont.
• Basic resilience attribute binary variable
  which determines the target traffic trunk is to
  be rerouted or not
• Extended resilience attribute specify
  detailed actions to be taken under fault
  scenarios
• Ex) a set of alternative path, and the rules that
  govern the relative preference
• In MPLS, it is mandatory attribute

14
5.10 Policing Attribute

• 5.10 Policing Attribute
• Determines the actions that should be taken by
  underlying protocol when a traffic trunk becomes
  non-compliant(ex, a traffic trunk exceeds its
  contract)
• Generally, it indicates whether a non-compliant
  traffic trunk is to be rate limited, tagged, or
  simply forwarded(ex, GCRA(Generic Cell Rate
  Algorithm) performs it in ATM)
• Undesirable in some situation
• In ingress, To enforce compliance with SLA,
• and in core, To minimize policing, except
  capacity constraints
• For TE, it is necessary to be enable or disable
  traffic policing

15
6.0 Resource Attributes

• 6.0 Resource Attributes
• Part of the topological state parameters, which
  are used to constraint the routing
• 6.1 Maximum Allocation Multiplier(MAM)
• Administratively configurable attribute which
  determines the proportion of the resource that is
  available for allocation to traffic trunks
• Mostly applicable to link bandwith, also to
  buffer resources on LSRs
• Analogous to the concepts of subscription and
  booking factors in FR and ATM

16
6.0 Resource Attributes cont.

• 6.1 Maximum Allocation Multiplier cont.
• The value of MAM under-allocated or
  over-allocated
• Under-allocated
• The aggregate demands that can be allocated to it
  are always less than the capacity of the resource
• Used to bound the utilization of resources
• In MPLS, more complex, because conventional hop
  by hop routing and explicit routing without
  consideration for resource constraints
• Over-allocated
• The allocated aggregate demands can exceed the
  capacity of the resource
• Used to take advantage of the statistical
  characteristics of traffic, and when the peak
  demands of traffic trunks do not coincide in time

17
6.0 Resource Attributes cont.

• 6.2 Resource Class Attribute
• Express some notion of class for resources
• Resources can be viewed as Colors
• Used to implement many policies
• 1. Apply uniform policies to a set of resources
  that do not need to be in the same topological
  region
• 2. Specify the relative preference of sets of
  resources
• 3. Explicitly restrict the placement of traffic
  trunks to specific subsets of resources
• 4. Implement generalized inclusion/exclusion
  policies
• 5. Enforce traffic locality containment policies
• Can be used for identification purpose
• In general, a resource can be assigned more than
  one resource class attribute, For example OC-48
  links

18
7.0 Constraint-Based Routing

• 7.0 Constraint-Based Routing
• Referred to QoS Routing, BUT Constraint-Based
  Routing generally encompasses QoS routing as a
  subset
• Enables a demand driven, resource reservation
  aware, routing paradigm to co-exist with current
  topology driven hop by hop Internet IGP
• Constraint-Based Routing Frameworks input
• The attributes associated with traffic trunks
• The attributes associated with resources
• Other topology state information
• Based on these input, each node automatically
  computes explicit routes for each traffic trunk,
  under constraints
• It can greatly reduce the level of manual
  configuration and intervention required to
  actualize TE policies

19
7.0 Constraint-Based Routing cont.

• 7.1 Basic Features of Constraint-Based Routing
• At least have the capability to automatically
  obtain a basic feasible solution to the traffic
  trunk path placement problem
• Constraint-Based Routing problem is known to be
  intractable for most realistic constraints
• BUT, the very simple heuristic solution
• First prune resources that do NOT satisfy the
  requirements of the traffic trunk attributes
• Next, run a shortest path algorithm on the
  residual graph
• Additional rules can be specified to break ties
  and perform further optimization

20
7.0 Constraint-Based Routing cont.

• 7.2 Implementation Consideration
• Many commercial implementation already exist in
  FR and ATM switches
• So, MPLS Constraint-Based Routing implementation
  can be easily extended from those existing
  implementation
• For hop by hop IGP routers, two incorporation
  way
• By extending current IGP protocols(such as OSPF,
  IS-IS) to supporting constraint-based routing
• By adding a constraint-based routing process to
  each router which can co-exist with current IGPs

21
7.0 Constraint-Based Routing cont.

• 7.2 Implementation Consideration cont.

22
7.0 Constraint-Based Routing cont.

• 7.2 Implementation Consideration cont.
• Important details associated with implementing
  constraint-based routing on Layer 3 devices
• Mechanism for exchange of topology state
  information(resource availability, link state,
  and resource attribute information) between
  constraint-based routing processes
• Mechanism for maintenance of topology state info.
• Interaction between constraint-based routing
  process and conventional IGP process
• Mechanism to accommodate the adaptivity
  requirements of traffic trunk
• Mechanism to accommodate the resilience and
  survivability requirements of traffic trunk

23
8.0 Conclusion 9.0 Security Consideration

• 8.0 Conclusion
• Some issues described here can be addressed by
  incorporating a minimal set of building blocks
  into MPLS,
• And then using a network management
  superstructure to extend the functionality
• Constraint-Based Routing does not have to be part
  of core MPLS specification, but MPLS require some
  interaction with it to meet requirements
• 9.0 Security Consideration
• Does not introduce new security issue
• But, the manipulation of administratively
  configurable parameters can be executed in a
  secure way