MPLS網路近年已被視為未來有線網路系統之主流。它結合了目前各種交換式路由器技術之優點，提供更具彈性、擴充性以及更高效率之一種 IP 交換技術。MPLS 提供一個能整合 Layer 2 快速標頭交換之效能及 Layer 3 彈性路由選擇之優點，且可廣為各方所接受之標準化的網路傳輸技術。 在MPLS網路中，Label必須越簡單越好，但隨著Internet網路快速膨脹，Label數之飽和問題也已經浮現。為了提高MPLS網路的可擴充性，Label Merge就變成未來非常重要的課題。 目前已經提出許多Label-Merge方法，皆是致力於提高MPLS網路的可擴充性，但又盡量避免它伴隨而來的Payload、Buffer和Delay 的問題。而這些已經提出的Merge機制法，皆沒有加入服務等級的功能，研究論文將進一步加強這些 Merge 機制，增加 CoS 的功能，並且仍然維持 Merge 機制的重要目的：提高網路可擴充性、增加 Payload 使用率、減少 Delay 時間和 Buffer 使用量，而來與 Non-CoS Merge機制互相分析比較，並期盼加入 CoS 功能後的 Merge 機制，可以提高網路傳輸功效和品質保證。 One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints, which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. A new mechanism is proposed whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This information is most valuable in failure scenarious but is benificial during other path setup functions as well. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. This document describes a mechanism that helps to minimize thenegative effects on MPLS traffic caused by Label Switch Router's(LSR's) control plane restart, and specifically by the restart of itsLabel Distribution Protocol (LDP) component, on LSRs that are capableof preserving the MPLS forwarding component across the restart.The mechanism described in this document is applicable to all LSRs,both those with the ability to preserve forwarding state during LDPrestart and those without (although the latter need to implement onlya subset of the mechanism described in this document).The mechanism makes minimalistic assumptions on what has to bepreserved across restart - the mechanism assumes that only the actualMPLS forwarding state has to be preserved; the mechanism does notrequire any of the LDP-related state to be preserved across therestart.
