Traffic engineering requirements based on MPLS
(RFC2702 Requirements for Traffic Engineering over MPLS)
1. introduce
2. Traffic engineering
2.1 Traffic engineering performance indicators
2.2 Traffic and resource control
2.3 Limitations of the existing IGP control mechanism
3. MPLS and traffic engineering
3.1MPLS map
3.2 Basic issues of MPLS-based traffic engineering
4. Enhanced functions based on MPLS traffic engineering
5. Properties and features of traffic trunk
5.1 Two-way traffic backbone
5.2 Basic operations on traffic backbone
5.3 Statistics and performance monitoring
5.4 Basic properties of traffic trunk
5.5 Traffic parameter attributes
5.6 General path selection and management properties
5.6.1 Explicit routing specified by network management
5.6.2 Multiple path priority
5.6.3 Resource category affinity attributes
5.6.4 Adaptive Attributes
5.6.5 Load allocation between parallel traffic trunks
5.7 Priority attributes
5.8 Preemption of attributes
5.9 Elasticity properties
5.10 Policy Attributes
6. Resource attributes
6.1 Maximum allocation factor
6.2 Resource level attributes
7. Constrained routing
7.1 Basic characteristics of constrained routing
7.2 Considerations on specific implementation
1. introduce
MPLS [1,2] integrates the tag switching framework and network layer routing. The basic idea is to assign a fixed-length short tag to the datagram based on the forwarding equivalent class FEC (Forwarding Equivalence Classes) at the MPLS domain entrance node. In the entire MPLS domain, the tags bundled with the datagram will determine the forwarding of the datagram, and the original header of the datagram will no longer be considered.
Based on this relatively simple specification, an effective protocol architecture can be designed to solve many key problems facing distinguishing services in the Internet. The most important application of MPLS will be traffic engineering, and the importance of this application has gradually become known to everyone. [1,2,3]
This article mainly discusses the application of MPLS in traffic engineering. The purpose of this article is to put forward the issues and requirements that need to be paid attention to when applying traffic engineering on large Internet backbone networks. We hope that the specifications of MPLS, or implementation based on this, will help achieve these goals. In addition, we also describe some of the basic functions required for MPLS implementation to meet the requirements of traffic engineering.
It should be noted that although our discussion is mainly based on the Internet backbone network, the functions described in this article are also applicable to traffic engineering on the enterprise network. Generally, these functions can be used on any tag switching network that applies the same technology, in which there are at least two paths between any nodes.
Some recent literature has studied MPLS-based traffic engineering and traffic management, among which the more famous are Li and Rekhter's work [3], as well as the research of some other researchers. In [3], a framework for using MPLS and RSVP to provide scalable distinction between services and traffic engineering on the Internet is proposed. This article supplements the above similar work. It reflects the author's experience in managing large Internet backbone networks.
2. Traffic engineering
This section describes some basic functions of traffic engineering within the current autonomous system on the Internet. And put forward the current limitations of IGP in terms of traffic control and resource control. This section puts forward the necessity of the requirements of MPLS.
Traffic engineering (TE) is mainly about optimizing the performance of the operating network. Generally speaking, it includes the application of technology, scientific criteria for measurement, modeling, induction and Internet traffic control, and how to apply these knowledge and techniques to practice to obtain some specific performance indicators.
One of the main purpose of traffic engineering is to optimize the utilization rate of network resources and traffic performance while promoting effective and reliable network operations. Due to the expensive network resources and the nature of fierce commercial competition on the Internet, traffic engineering has become an indispensable function in large-scale autonomous systems. These facts all show that it is necessary to maximize operational efficiency.
2.1 Traffic engineering performance indicators
The main performance indicators of traffic engineering can be divided into two types:
1. Traffic-oriented
2. Resource-oriented
Traffic-oriented performance metrics include all aspects of enhanced traffic QoS functions. In a single QoS-level, best-effort Internet traffic model, traffic-oriented performance metrics include: minimizing packet loss, minimizing delay, maximizing throughput, and enhancing service level agreements. In this traffic model, minimizing packet loss is the most important performance metric. In the future Internet that distinguishes services, some traffic-oriented performance indicators (such as delay peak changes, loss rate, etc.) related to statistics will become increasingly important.
Resource-oriented performance indicators include all aspects of optimizing resource utilization. Efficient network management is an important way to achieve resource-oriented performance indicators. Usually we want to ensure that when there are available resources on other optional paths, network resources on one path will not be overused. Bandwidth is a very important resource on the current network. Therefore, a central task of traffic engineering is to effectively manage bandwidth resources.
Whether it is resource-oriented or traffic-oriented traffic engineering, their primary performance metric is minimization of congestion. The congestion that is concerned here is mainly long-term congestion, rather than short-term congestion caused by sudden traffic. There are two main types of congestion:
1. Congestion occurs when network resources are insufficient to meet the load requirements.
2. When the mapping efficiency between service traffic and available resources is not high, congestion caused by some network resources being overused while the other resources are underutilized.
The first type of congestion can be solved in the following ways: (1) expand the network, or (2) apply classic congestion control technology, or (3) use the above two methods at the same time. Classic congestion control technology is an attempt to control business requests so that the business can match the available resources. Classic techniques for congestion control include: rate control, window control, router queue management, process control, and some other technologies (see [8] and its references).
The second type of congestion, that is, congestion caused by unreasonable allocation of resources, can usually be solved by traffic engineering.
Generally speaking, congestion caused by unreasonable resource allocation can be alleviated through load balancing. This type of strategy reduces congestion or reduces resource usage through effective resource allocation, minimizing congestion or maximizing resource utilization. When congestion is minimized, packet loss will be reduced, transmission delay will be shortened, and throughput will be increased. In this way, the service quality felt by end users will be significantly improved.
Obviously, load balancing is an important strategy for optimizing network performance. However, the strategies provided to traffic engineering must be flexible enough so that network administrators can implement other strategies that take into account the universal cost structure and utility, tax model.
2.2 Traffic and resource control
Network performance optimization is essentially a control issue. In flow engineering, a flow engineer or a control device acts as the controller of an adaptive control system. The system includes a series of interconnected network elements, a network performance monitoring system, and a complete set of network configuration and management tools. The traffic engineer formulates a complete set of control strategies, uses the network performance monitoring system to observe the network's status input, then describes the service traffic, and finally uses control measures to make the network reach an ideal state that is consistent with the control strategy. This process can be carried out in real time for the existing state of the network, or it can be predicted and taken corresponding measures to carry out in advance with the help of forecasting technology. The latter technology can prevent bad conditions from happening in the network in advance.
Ideally, the above control measures should include:
1. Modification of various traffic management parameters,
2. Modification of routing-related parameters,
3. Modification of resource-related attributes and constraints.
If possible, manual participation should be avoided during the flow engineering process. The above control measures can be automatically completed in a distributed, scalable way.
[1][2] [3] [4] [5] [6] [7] Next page
Article entry: csh Editor in charge: csh
2.3 Limitations of the existing IGP control mechanism
This section explains the obvious limitations of IGP in traffic engineering.
The existing Internet internal gateway protocol cluster does not provide the capability to traffic engineering. Therefore, it is difficult to implement effective strategies for network performance issues. In fact, IGPs based on shortest path algorithms are the main cause of congestion in AS networks. The shortest path algorithm is a simple optimization algorithm based on added value. These protocols are topologically driven, so they do not take into account the characteristics of the bandwidth and traffic available to the network. Congestion occurs when:
1. When the shortest paths of multiple service flows converge on a specific link or router interface, or
2. The shortest path to a service flow will pass through a link or interface that is not enough to support the service.
In both cases, congestion still occurs even if there are other paths with sufficient bandwidth. This congestion problem (symptom of unreasonable allocation of resources) is exactly what traffic engineering should avoid. For congestion caused by the second reason，Can be used“Load sharing for overhead paths”Technology to solve，But for congestion caused by the first cause，Especially for large networks with complex topology，This technique doesn't help much。
At present, the more popular way to solve the above defects of IGP protocol cluster is to use overlapping model technologies, such as IP over ATM, IP over FR, etc. The overlapping model provides a free virtual topology on the physical topology of the network, thus extending the space for network design. This virtual topology is composed of virtual circuits. In the eyes of the IGP routing protocol, these virtual circuits are equivalent to past physical links. The overlapping model also provides many other important services to support traffic and resource control, including: (1) VC-level constrained routing, (2) explicit routing that can be configured by network managers, (3) path compression, (4) call permitting control functions, (5) traffic shaping and traffic policy functions, and (6) VC survival functions. Relying on these features can achieve many traffic engineering strategies. For example, traffic traffic on overused network resources can be easily transferred to relatively idle network resources.
For large networks, the MPLS it uses must have at least the same level of functionality as the overlapping model. Fortunately, this function can be implemented more easily in MPLS.
3. MPLS and traffic engineering
This section explains the application of MPLS in traffic engineering. The following chapters explain the functions that MPLS should have in order to meet the requirements of traffic engineering.
MPLS itself has the potential to complete the various traffic engineering functions implemented by the overlapping model. The difference is that it uses an integrated model, which is more ideal than overlapping models and other similar technologies in terms of cost and scalability. It is also important that it will have the potential to automate traffic engineering functions. This will be further studied, and it is beyond the scope of this article.
Note on terms: The concept of traffic trunk will be widely used in the rest of this article. According to Li and Rekhter[3], the traffic backbone refers to a traffic flow of the same type that is placed on the same tag exchange path. In essence, the traffic backbone is an abstraction of a particular traffic feature. It would be beneficial to think of the traffic backbone as the routed object, that is, the path through which the traffic backbone can be changed. In this sense, the traffic backbone is very similar to the virtual circuits on the ATM network and the frame relay network. However, we must emphasize that there is a fundamental difference between the traffic backbone and the path it passes, that is, the LSP. LSP is a specific tag exchange path through which traffic passes. In practice, the term LSP is used synonymous with the traffic backbone. Other features of the traffic backbone used in this article are summarized in Section 5.0.
The attractiveness of MPLS can be attributed to the following points: (1) Through manual network management configuration or automatic configuration of lower-level protocols, it is easy to establish an explicit LSP that is not restricted by the traditional hop-by-hop routing protocol. (2) LSP can be efficiently maintained, (3) Traffic backbone can be used and mapped to the LSP, (4) Traffic backbone can be specified for the traffic backbone to adjust the behavior of the traffic backbone, (5) Various network resources can be specified for limiting the traffic backbone through the above established LSP, (6) It can not only combine services, but also divide services. IP forwarding based on traditional routing protocols only supports combination of services, (7) It can easily implement "constrained routing", (8) The overhead of MPLS traffic engineering is much smaller than other traffic engineering technologies.
In addition, by explicit tag switching paths, MPLS can implement quasi-circuit switching functions in existing Internet routing models. Many existing suggestions for MPLS-based traffic engineering focus on establishing explicit label switching paths. Although it is a basic function of flow engineering, it is not enough. To achieve performance optimization of existing networks for large networks, traffic engineering technology also needs other functions. This article describes some of these necessary functions.
3.1 MPLS Map
This section introduces the concept of "MPLS" map. It is the core of MPLS traffic engineering. The MPLS map is similar to the virtual topology map in an overlapping model. By selecting the LSP for the traffic backbone, the MPLS map is logically mapped onto the physical network.
An MPLS map contains a set of LSRs and LSPs. The LSR forms the nodes in the MPLS map, and the LSP provides a point-to-point logical connection for the LSR, thereby acting as a connection for the MPLS map. It is possible to establish a hierarchical MPLS map based on the concept of the tag stack (see [1]).
The reason why MPLS maps are important is that the basic problem of bandwidth management in MPLS is how to effectively map an MPLS map to the topology map of the physical network. The abstract description of MPLS map is as follows:
Let G=(V, E, c) represent the graph of the topology of the physical network. Here, V is a series of points in the network, and E is a set of connections: that is, for points v and w in V, if v and w are directly connected in G, then the object (v, w) is in E. Parameter c is a set of bandwidth or other constraints related to E and V. We will use G to refer to the basic network topology.
Let H=(U, F, d) be an MPLS map, where U is a subset of V, which represents a set of LSRs in the network, or more precisely, it represents the endpoint of at least one LSP. F refers to a set of LSPs. For x and y in U, if there is an LSP with x and y as endpoints, then the object (x, y) is in the set F. Parameter d is a set of requirements and restrictions associated with F. Obviously, H is a directed graph. We can see that H depends on the transmission characteristics of G.
3.2 Basic issues of MPLS-based traffic engineering
Implementing traffic engineering on MPLS faces the following three basic problems:
How to map packets to forwarding equivalent classes (FECs).
How to map forwarding equivalent classes to traffic backbone.
How to map traffic backbone to mark switching paths.
Although the first two questions are very important, this article is not directed at them. What is concerned with this article is the execution capability of the third mapping function, through which network operations are both efficient and reliable. This is actually a problem of mapping the MPLS map (H) to the basic network topology (G).
4. Enhanced functions based on MPLS traffic engineering
The previous section talks about the basic functions of traffic engineering on the current network. At the same time, the feasibility of using MPLS for traffic engineering was also discussed. The rest of this article will describe the functions required by MPLS to fully support MPLS-based traffic engineering on large networks.
Its required features include:
1. A set of attributes related to the traffic backbone and describe the behavioral characteristics of the traffic backbone.
2. A set of resource-related attributes that limit traffic backbones using various resources. These properties can also be regarded as limitations of topological properties.
3. "Constrained routing". With this technology and various attributes in the previous two points, MPLS will be able to limit the path selected by the traffic backbone. In addition, although constraint routing technology is only an optional feature of MPLS technology, it should be closely integrated with MPLS.
In the process of driving the network to an ideal state through network management activities or some automation technology, a series of attributes related to traffic backbone and resource and router-related parameters together constitute all control parameters that can be modified.
In a network, it is ideal that the network operator can dynamically change the above parameters without interrupting the operation of the network.
Previous page [1][2][3] [4] [5] [6] [7] Next page
Article entry: csh Editor in charge: csh
5. Properties and features of traffic trunk
This section describes properties related to traffic backbones that can control their behavior.
First, the basic properties of the traffic trunk are summarized as follows:
(1) The traffic backbone is a "collection" of business flows belonging to the same category. In some cases, we may want to relax this definition so that the traffic backbone can contain multiple types of traffic.
(2) In a separate business type model, such as the current Internet network, the traffic backbone can encapsulate all traffic between a pair of inlet-egress LSRs or a subnet.
(3) The traffic backbone is a routable object (similar to the virtual circuit of the ATM).
(4) The traffic trunk is obviously different from the LSP it passes through. In an operating environment, the traffic backbone can be transferred from one path to another.
(5) The traffic trunk is one-way
In practical applications, the traffic backbone can be represented by its inlet and exit LSR, the forwarding equivalent class it maps to, and a set of attributes that determine its behavioral characteristics.
There are two very important questions here: (1) Parameter configuration of the traffic backbone. (2) Path selection and maintenance rules for traffic trunk.
5.1 Two-way traffic backbone
Although the traffic backbone is conceptually one-way, in many practical cases it is very useful to initialize two traffic backbones in opposite directions at the same endpoint at the same time. A backbone, called the forward backbone, carries traffic from the source point to the end point. Another backbone, called the backbone, carries traffic from the end point to the source point. If the following two conditions are true, we call the collection of these two trunks a bidirectional traffic backbone (BIT).
(1) Both traffic backbones are initialized through atomic operations of the source point or network management station.
(2) Two traffic backbones must exist at the same time. That is, they are initialized at the same time and are demolished at the same time.
The topological characteristics of BITs should also be considered. A BIT can be topologically symmetric or topologically asymmetric. If the traffic backbone that makes up the BIT is routed along the same physical path, even if they are in different directions, we say that the BIT is "topologically symmetric". On the contrary, if the traffic backbone that makes up the BIT is routed along different physical paths, then this BIT is "topologically asymmetric".
It must be pointed out that the two-way traffic backbone is just for management convenience. In practice, most engineering functions can be implemented with only one-way traffic backbone.
5.2 Basic operations on traffic backbone
For traffic engineering, the important basic operations for it are summarized as follows:
Establish: Establish a traffic backbone.
Activation: Makes a traffic backbone start to transmit traffic. The establishment and activation of traffic backbone are logically two separate things. However, they can also be implemented and initiated as an atomic operation.
Deactivate: is a traffic backbone that stops traffic transmission.
Change attributes: Change the attributes of a traffic trunk.
Rerouting: Change the path of a traffic backbone. This process can be realized through network management or automatically implemented by lower-level protocols.
Demolition: Demolition a traffic backbone from the network and recycle all network resources allocated to it. These resources include tag space, available bandwidth, etc.
The above introduces the basic operations on the traffic backbone. In addition, there may be some additional operations, such as traffic planning and traffic shaping.
5.3 Statistics and performance monitoring
Statistics and performance monitoring functions are very important for the billing and traffic characteristic description functions of the network. The statistical data obtained from the statistical and performance monitoring system will be used for traffic description, performance optimization, capacity planning in traffic engineering, etc.
Due to the importance of the ability to obtain statistical data from the traffic backbone, this function is a most basic requirement in the traffic engineering implementation of MPLS.
5.4 Basic properties of traffic trunk
The attributes of a traffic trunk are parameters related to a traffic trunk and affect its behavioral characteristics.
The attributes of the traffic backbone can be clearly allocated through the network management, or the default allocation can be made on the entry LSR of the MPLS domain through the lower-level protocol when the packets are classified and mapped to the forwarding equivalent class. However, regardless of how these attributes are allocated, in order to meet the requirements of traffic engineering, these attributes should be modified through network management.
Among the basic properties of the traffic backbone, the implementation of traffic engineering has the following basic properties that are particularly important:
Flow parameter attributes
General path selection and management attributes
Priority attribute
Preemption of attributes
Elastic properties
Policy attributes
The combination of traffic parameters and policy attributes is similar to application parameter control in the ATM network. Most of the above properties can be found similar concepts in some existing mature technology. Therefore, it would be very simple to map the properties of the traffic backbone to many existing exchange and routing mechanisms.
Priority and preemption attributes can be regarded as related attributes because they represent the correlation between traffic backbones. Therefore, these correlations determine the behavior of traffic backbones competing network resources between each other during the process of establishing and maintaining paths.
5.5 Traffic parameter attributes
We can use the traffic parameter attributes to obtain the characteristics of the traffic to be transmitted in the traffic backbone (more precisely the forwarding equivalent class). These characteristics include peak rate, average rate, burst size allowable value, etc. From the perspective of traffic engineering, the reason why traffic parameters are important is that they reflect the resource requirements of the traffic backbone. They are useful for resource allocation and congestion prevention using expected policies.
From the perspective of bandwidth allocation, a single required bandwidth specification value can be calculated from the traffic parameters of the traffic backbone. The techniques for performing these calculations are well known. One example is the theory of effective bandwidth.
5.6 General path selection and management properties
The general path selection and management attributes define rules for selecting paths for traffic backbone and rules for maintaining established paths.
The calculation of the path can be automatically completed through the lower layer protocol or completed by the network management. If a traffic backbone does not have resource requirements or constraints related to it, traditional topology driving technology can be used for path selection. However, if there are certain requirements or policy restrictions on the traffic backbone, constraint routing technology must be used in path selection.
In Section 7, we describe a constraint routing framework that can automatically compute routing against a series of constraints. Some issues in identifying display routing through administrative behaviors, which we will discuss below in Section 5.6.
Path management will include all issues related to the paths that keep the traffic main flowing through. In some cases, it may be desirable that MPLS technology can dynamically reconfigure itself in order to be able to adapt to some changes in network state.
In order to control the path selection process and management process, a complete set of various attributes is required. The basic properties and behavioral characteristics related to the path selection of traffic backbone are described in the next subsection.
Previous page [1] [2][3][4] [5] [6] [7] Next page
Article entry: csh Editor in charge: csh
5.6.1 Explicit routing specified by network management
An explicit route specified for the traffic backbone through the network management refers to a path configured through the activities of the network operator. An explicit route specified by a network management can be partially specified or completely specified. This path is partially specified when only a portion of the intermediate nodes are specified. In this case, the complete path needs to be completed by the lower protocol. Due to operational errors, explicit routing specified by the network administrator can be contradictory or illegal. The lower protocol must be able to detect these errors and provide correct feedback.
An explicit route specified by the network administrator should have a "Path Priority Rule" attribute. The path priority law attribute is a binary variable that indicates whether an explicit route specified according to administrative requirements is "mandatory" or "non-mandatory".
If the attribute of an explicit route specified by the network management is "mandatory", then only this path can be used. If a forced path is not feasible, or the path cannot be established due to lack of sufficient resources, the path establishment process will fail. In other words, if a path is specified as mandatory, then an alternative path cannot be used regardless of the surrounding environment. Once this path is established, the path cannot be changed unless the path is revoked or a new path is created.
However, if an explicit route specified by the network administrator is "non-mandatory", it will be used if this path is available. Otherwise, an alternative path will be selected by the lower protocol.
5.6.2 Multiple path priority
In some cases, it may be necessary to specify multiple candidate explicit routes for a given traffic backbone through network management activities and define a set of priorities for these candidate routes. During the path establishment process, the appropriate path will be selected from the candidate path list according to priority. When a network fails, an alternative path is also selected from the candidate path list based on priority.
5.6.3 Resource category affinity attributes
The resource category affinity attribute is used to determine the types of network resource that a traffic backbone can or cannot be used on its path (see Section 6). These policy attributes will further limit the paths that a certain traffic backbone can use. The resource category attributes of a certain traffic have the following format:
〈Resource type, affinity〉;〈Resource type, affinity〉;…
The resource type parameter will indicate which resource type the object of the affinity attribute of a traffic trunk is; the affinity attribute parameter indicates the affinity relationship between the traffic trunk and a certain resource, that is, whether a certain resource must be used or must not be used on the path through which the traffic trunk flows. In particular, the affinity attribute may be a binary number that has one of two: (1) determines inclusion, and (2) determines induction.
If the affinity attribute is a binary number, it may use a Boolean expression to indicate the resource category affinity attribute of a certain traffic backbone.
If a traffic backbone does not have resource category affinity attribute, the affinity between the traffic backbone and all network resources is "unrelated", that is, it has no requirements for whether a certain type of resource must be used or not. In practical applications, this should be the default situation.
Resource category affinity attributes are a very useful and powerful tool. Using these attributes can implement strategies for many traffic engineering. For example, this property can be used to limit certain traffic backbones to a specific topological area of the network.
For traffic backbones with a certain resource category affinity attribute, when using the method of constraining routing (see Section 7) to calculate a display route for it, the following method can be used:
1. For Determining the Inclusion property, before calculating the path, delete all resources that do not belong to the specified resource category.
2. For the Determination Exclusion property, delete all resources belonging to the specified resource category before calculating the path.
5.6.4 Adaptive Attributes
As time changes, the characteristics and state of the network will also change. For example, new available resources are generated, the failed resources are restored to normal, the allocated resources are released, and so on. Oftentimes, there are sometimes more efficient paths. Therefore, from the perspective of traffic engineering, there are some management control parameters that require dictating the response of the traffic backbone to the above changes. In some cases, it may be desirable to dynamically change the path of the traffic backbone in response to changes in network state, a process called re-optimization. In other cases, such re-optimization may not be desired.
The adaptability attribute is part of the path-holding parameters of the traffic backbone. This part of the attributes of the traffic trunk indicates whether a certain traffic trunk can be re-optimized. The adaptive attribute can also be represented by a binary number, which has one of the following: (1) allows re-optimization, and (2) prohibits re-optimization.
When re-optimization is allowed, the lower-level protocol can re-rout the traffic backbone to different paths according to changes in network state (mainly changes in resource availability). On the contrary, if re-optimization is prohibited, the traffic backbone is like being "pinned" to this path and cannot be re-routed according to changes in network status.
Stability is a major issue when re-optimization is allowed. In order to ensure stability, the implementation solution of MPLS cannot be too sensitive to changes in network state. At the same time, it must also have sufficient response speed to make the most efficient use of network resources. This means that the re-optimized frequency should be configured and changed using network management methods.
It should also be noted that re-optimization is different from elasticity. There is a different attribute specifically used to indicate the elastic properties of the traffic backbone (see Section 5.9). In practice, if the traffic backbone is allowed to re-optimize, it means that the traffic backbone has elastic recovery for failures on the path. However, if a traffic backbone does not allow re-optimization and its path is not specified by the network management as "mandatory", it also requires elastic recovery of link and node failures on the path.
Formally, adapting to the development of network state through re-optimization means having elastic recovery for failures, while having elastic recovery for failures does not mean that adapting to changes in network state through re-optimization.
5.6.5 Load allocation between parallel traffic trunks
Load allocation on multiple parallel traffic backbones between two nodes is a very important issue. In many cases, a certain traffic volume between two nodes may not be borne by any separate link or path. However, the resources required for this traffic may be less than the total amount that all available paths in the network can provide. At this point, the only way is to break down the traffic traffic into some traffic subsets, and transmit these traffic subsets through multiple paths.
In one MPLS area, the above problems can be solved by initiating multiple traffic backbones between two nodes, so that the total traffic volume can be shared among each traffic backbone. To achieve this process, it is necessary to design a technology that can flexibly distribute loads to multiple parallel traffic backbones.
In particular, from an operational perspective, if multiple parallel traffic trunks are allowed to exist, then there needs to be an attribute that indicates the relative proportion of traffic volume carried by each traffic trunk. The lower layer protocol will map the load to the traffic backbone according to the specified proportion. Also, it is preferred to maintain the order between packets belonging to the same macrostream (same source address, destination address and port number).
5.7 Priority Attributes
The priority attribute defines the relative importance between traffic backbones. In the constrained routing technology of MPLS, priority attributes are very important. This property can be used to determine the order in which the path selection for the traffic backbone during connection establishment and failure recovery.
In the implementation of allowing resource preemption, priority attributes are also very important. Use this property to specify a certain order for the traffic backbone to implement a preemptive policy.
5.8 Preemption of attributes
The preemption attribute will determine whether a traffic trunk can seize the path of another traffic trunk, or whether the path of that traffic trunk can be preempted by other traffic trunks. This attribute is very important for realizing traffic-oriented performance metrics and resource-oriented performance metrics. In a service-distinguishing environment, preemption of attributes can ensure that high-priority traffic backbones can always use ideal paths.
During troubleshooting, preemption properties can be used to implement many priority recovery strategies.
There are four modes for preemption attributes: (1) preemption allowed, (2) preemption not allowed, (3) preemption allowed, and (4) preemption not allowed. A traffic backbone with the allow preemption attribute can preempt a traffic backbone with the allowed preempt, low priority. A traffic trunk with the attribute that is not allowed to be preempted is not allowed to be preempted by any traffic trunk, regardless of their relative priority. A traffic trunk with the allowed preemption attribute can be preempted by a traffic trunk with a allowed preemption higher than it.
It is worth noting that some preemption modes are mutually exclusive. Using the above numbers, the feasibility combination of preemption modes for any given traffic backbone can be: (1, 3), (1, 4), (2, 3) and (2, 4). Among them (2, 4) combination should be the default combination.
Only when all the following five conditions are met can it be said that one traffic backbone "A" can seize the path of another traffic backbone "B": (1) A preemption priority is higher than B, (2) The network resources used by B can meet the needs of A, (3) According to some judgment criteria, it has been concluded that network resources cannot meet the needs of A and B at the same time, (4) A has the attributes that allow preemption, and (5) B has the attributes that allow preemption.
Although preemption of attributes is very useful, in the current network service mode where you are trying your best, preemption of attributes cannot be considered a mandatory attribute. However, in differentiating service environments, preempting attributes becomes very necessary. Moreover, with the advent of fiber-optic Internet systems, certain protection and storage functions may need to be migrated from the fiber layer to data network elements (such as some gigabit and terabyte mark switching routers) to reduce costs, which requires preemption strategies to reduce storage time of high priority traffic backbone in the event of a failure.
Previous page [1] [2] [3][4][5] [6] [7] Next page
Article entry: csh Editor in charge: csh
5.9 Elasticity properties
The elastic attribute determines the behavioral characteristics of the traffic backbone when a failure occurs. In other words, when a fault occurs on the path through which the main traffic flows, the following basic problems need to be solved: (1) Fault detection, (2) Fault notification, (3) Link recovery and service recovery. It is obvious that the specific implementation of MPLS will need to have a mechanism to solve the above problems.
If the path through which the traffic trunk fails, then many recovery strategies can be specified for them. Here are some examples of feasible strategies:
1. No rerouting of traffic trunks. For example, there is already a certain technology that ensures survival in the specific implementation, which can ensure that when a failure occurs, the traffic backbone cannot be re-routed to ensure that the business continues. An example of this technique is (of course there are many other techniques). If there are multiple parallel paths between nodes, according to some control strategy, when a failure occurs, the traffic backbone on it is transferred to other LSPs after one LSP fails.
2. Reroute the traffic backbone to a path with sufficient resources. If there is no required path, no rerouting is performed.
3. Redirecting various resource constraint parameters to rerout the traffic backbone to any available path.
4. There are many other solutions, including some combination of the above strategies.
A "basic" elastic property determines the recovery process used when the path through which the traffic main flow fails. In particular, the "basic" elastic property is a binary number that determines whether a traffic backbone needs to be re-routed in the event of a failure. The "Extended" elastic property is used to determine the detailed processing of the traffic backbone in the event of a failure. For example, the extended elastic properties may specify a set of replacement paths that a certain traffic backbone can use in the event of a failure and the priority relationship between the paths.
The elastic attribute controls the interaction process between MPLS and routing.
5.10 Policy Attributes
When a traffic backbone no longer complies with the agreement when path establishment, that is, when the characteristics of a traffic backbone exceed the value specified by its traffic parameters, the policy attributes determine the processing method adopted by the lower protocol. Normally, policy attributes indicate whether the corresponding default traffic backbone is subject to rate limiting, marking, or not doing anything to continue forwarding. If you really want to use a certain strategy, you can directly use some existing algorithms, such as GCRA [11] of the ATM forum, to perform this function.
In many cases, there must be a certain strategic mechanism, but in other cases, it is not suitable to use a strategic mechanism. Generally speaking, it is hoped that a certain policy mechanism can be implemented at the entrance of the network (to comply with SLA), while at the core of the network, we must try our best to avoid using the policy mechanism unless the capacity constraints are clearly required.
Therefore, from the perspective of traffic engineering, it is necessary to have the ability to allow or prohibit operations of each traffic backbone through the network management.
6. Resource attributes
Resource attributes are part of topological state attributes, and their function is to limit the traffic backbone routing process on a specific resource.
6.1 Maximum allocation factor
The maximum allocation factor (MAM) of a resource is an attribute that can be configured through network management, which determines the proportion of the resource that can be used by the traffic backbone. The most commonly used resource mentioned here is bandwidth resources. However, this resource may also be a buffer resource on the LSR. The concept of MAM is similar to subscription and booking factors in frame relay or ATM networks.
The selection of MAM can cause a resource to be in two states: incomplete allocation or excessive allocation. If the sum of resource requirements of all traffic trunks participating in a resource allocation (which can be expressed by the traffic parameters of the traffic trunk) does not exceed the total capacity of the resource, then we say that the allocation of the resource is incomplete. If the sum of resource requirements of the traffic backbone participating in the allocation of a resource exceeds the total capacity of the resource, the allocation of the resource is called excessive allocation.
Incomplete allocation can be used to limit the use of resources. However, the MPLS environment is more complex compared to circuit switching, because in the MPLS environment, some data streams can be routed according to the traditional hop-by-hop protocol (which can also be used to use display routing) without considering resource limitations.
Over-allocation can leverage the statistical characteristics of traffic to achieve more efficient resource allocation strategies. In particular, excessive allocation is suitable when the requirements for the instantaneous peak of the flow backbone do not coincide.
6.2 Resource level attributes
The resource level attribute is a parameter assigned by the network administrator, which indicates the "level" of the resource. The concept of resource level can be regarded as a concept of "color". It can be considered that resources with the same "color" belong to the same level. Using resource level attributes, many traffic engineering strategies can be implemented. The resource that this attribute cares most is the link resource. The level attribute of a link resource is a very important aspect of the "link state" parameter.
Resource level attributes are a useful abstract concept. From a traffic engineering perspective, this property can be used to implement many strategies related to traffic-oriented and resource-oriented performance optimization. In particular, resource level attributes can be used for:
1. The same policy can be applied to a set of resources that are not in the same topological region.
2. Specify a priority relationship between each other for a set of network resources required to establish a traffic backbone path.
3. The traffic backbone is explicitly confined to a specific set of network resources.
4. Implement a common set of inclusion/extraction strategies.
5. Enhance local traffic inclusion strategies. Local traffic inclusion policies are policies that limit local traffic to specific network topology areas.
In addition, resource level attributes can also be used for user authentication.
It is usually possible to assign multiple network resource attributes to a certain resource. For example, all OC-48 links in a certain network can be assigned a certain attribute. In addition, a certain attribute can be assigned to a portion of these links that belong to a certain network area in order to implement a certain inclusive policy or to configure the network in a certain way.
Previous page [1] [2] [3] [4][5][6] [7] Next page
Article entry: csh Editor in charge: csh
7. Constrained routing
This section discusses issues related to MPLS domain and constrained routing. In current terms, constraint routing often refers to "QOS routing" [5, 6, 7, 10]. This article uses the name "constrained routing" because it better reflects the nature of this technology, and QOS routing is just a subset of this technology.
Constrained routing technology is a command-driven routing algorithm with resource reservation capabilities. It can coexist with existing topology-driven, hop-by-hop Internet Internal Gateway Protocol (IGP).
A constraint routing framework uses the following properties as input:
Attributes related to traffic trunk
Attributes related to resources
Other topological status information
Based on the above information, the constraint routing mechanism on each network node will automatically calculate a display route for each traffic backbone initiated on the node. In this case, the display route of each traffic backbone is a detailed tag exchange path that meets the requirements of the traffic backbone and obeys various constraints proposed by resource availability, management policies and other topological state information.
A constrained routing technology can greatly reduce manual configuration and manual intervention in traffic engineering strategy implementation.
In fact, a traffic engineer or an automaton will specify an endpoint for a traffic backbone and assign it a property set that contains the expected performance and behavioral characteristics of the traffic backbone. The constraint routing framework can find a feasible path that meets the expectations. If necessary, traffic engineers or traffic engineering support systems can use manual configuration display routing to complete better optimization.
7.1 Basic characteristics of constrained routing
A constrained route should at least have the ability to automatically establish a feasible path for the traffic backbone.
For most constrained routing parameters, it is generally believed that it is very difficult to use constrained routing technology. However, in practice, if the path exists, this feasible path can be found using a very simple, well-known heuristic algorithm [9]:
First, delete all resources that cannot meet the traffic trunk attribute requirements;
Secondly, use the shortest path algorithm on the remaining topology graphs.
It is obvious that as long as there is a feasible path, you can find this path using the above simple algorithm. We also use other rules to eliminate ties and further optimize the calculation results. Generally speaking, the purpose of removing congestion is to minimize congestion. However, if multiple traffic trunks are required to perform routing calculations at the same time, even if there are feasible paths, the above algorithm may not produce results.
7.2 Considerations on specific implementation
Many commercial implementations of frame relay and ATM switching devices can already support certain constraint routing. For these devices and various MPLS devices, it will be relatively simple to extend existing constraint routing in order to meet the requirements of MPLS.
For routers that use topology-driven and hop-by-hop IGP protocol, at least the following two methods can be used to implement constrained routing:
1. Extended existing IGP protocols such as OSPF, IS-IS protocol, etc. to enable them to support constrained routing. Now, efforts are being made to provide such methods, such as extensions to OSPF. [5,7]
2. Add a constraint routing process to each router that can coexist with the existing IGP protocol. This method is shown in Figure 1:
----------------------------------------------------------
|
---------------------------------------------------------
------------------- --------------------------- -----------------------
| MPLS |<->| Constrained routing process | | Traditional IGP process |
------------------- --------------------------- -----------------------
------------------------------------- -----------------------
Previous page [1] [2] [3] [4] [5][6][7] Next page
Article entry: csh Editor in charge: csh| Resource attributes, availability database | | Link status database |
------------------------------------- -----------------------
Figure 1 The third layer of constraint routing process in LSR
There are many important details in the process of implementing constrained routing on the third layer. These include:
Mechanism for exchanging topological state information (such as resource availability information, link status information, resource attribute information, etc.) between constrained routing processes
Mechanism for maintaining topological status information
Constrain the interoperability between routing processes and traditional IGP processes
Mechanisms that meet the adaptability requirements of traffic backbone
Mechanisms that satisfy the elasticity and survival of traffic trunks
In short, constrained routing will greatly help optimize the performance of the operation network through automatic searching of possible paths that meet the requirements of a set of constraint parameters of the traffic backbone. It can also greatly reduce the workload and manual intervention of display path configuration through network management during traffic engineering.
Previous page [1] [2] [3] [4] [5] [6][7]
Article entry: csh Editor in charge: csh