+ All Categories
Home > Documents > 04281271

04281271

Date post: 08-Nov-2015
Category:
Upload: sugengsa
View: 4 times
Download: 1 times
Share this document with a friend
Description:
IEEE
Popular Tags:
6
Multi - layer Traffic Engineering Experimental System in IP Optical Network Daisaku Shimazaki, Eiji Oki and Kohei Shiomoto NTT Network Service Systems Laboratories, NTT Corp. 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Email: {shimazaki.daisaku, oki.eiji, shiomoto.kohei}@lab.ntt.cojp Abstract-We developed distributed-controlled multi-layer traffic engineering system. There is no previous works that report the system. Therefore, we can not confirm feasibility and scalability of the system. In this paper, we report an experiment on our system consisting of Internet protocol (IP) routers and optical cross-connects (OXCs). In this system, control is provided by generalized multi-protocol label switching (GMPLS) and IP network topology and IP routes are dynamically re-configured to suit traffic characteristics. These functions prevent traffic congestion as well as any decrease in link utilization rates. We had experiments to test behavior of the routers and OXCs depend- ing on traffic characteristics. We cleared that the distributed- controlled multi-protocol label switching (MPLS)/GMPLS traffic engineering system was feasible and scalable by the experiments. I. INTRODUCTION Broadband access lines bring various services to the IP network. Some P2P software and video delivery services are causing rapid increases in traffic loads. New broadband services may cause unforeseeable fluctuations in traffic loads. New broadband network which can carry traffic of these services is required. This network should be manageable because it contains many types of service. MPLS/GMPLS [1] traffic engineering can meet the above requirement. We can strictly set the route of an MPLS/GMPLS label-switched path (LSP) from source node to destination node and collect information about LSPs, such as traffic values. In an LSP network, we can control the assigned bandwidth or quality-of-service (QoS) of every LSP because the network operator or network element can acquire all LSP information. The centralized MPLS/GMPLS network, unfortunately, has scalability and robustness problems. The centralized network means there is one node that can control the network. In the centralized network, a specific node has all information of the network and indicates all nodes. It is difficult that the specific node has scalability and robustness. Therefore, we focused on the distributed MPLS/GMPLS network. Many studies have examined the distributed MPLS/GMPLS network [2] - [4]. We previously proposed a distributed control mechanism for the MPLS/GMPLS network [5]. These papers proposed algorithms of distributed LSP network and investigated the performance of them. However, there is no confirmation validation report. We must confirm the behavior of the distributed mechanism, stability and processing capacity. This paper introduces distributed MPLS/GMPLS net- work experiment system called as IP optical network. We constructed experimental system and confirmed distributed MPLS/GMPLS network control. This system can measure traffic rate and establish and delete optical LSP depending on traffic demand. The rest of the paper is organized as follows. In Sec- tion II, we introduce a distributed virtual network topology (VNT) reconfiguration method. In Section III, distributed MPLS/GMPLS experimental system we constructed is ex- plained. In Section IV, we describe the experiment that we confirmed in the system. In Section V, the conclusion is given. II. IP OPTICAL NETWORK A. Virtual Network Topology (VNT) A multi-layer GMPLS network [1] applies the concept of hierarchical LSPs. In the network, the higher-layer network refers to a lower-layer LSP as a virtual link called forwarding adjacency (FA). The virtual network consisting of FAs is called the VNT [6], [7]. This paper considers two layer LSPs, packet LSP and optical LSP. Figure 1 shows that a lower-layer optical LSP is referred to as a virtual link by a higher-layer packet LSP and the virtual network consisting of optical LSPs is called the VNT. Packet LSPs, which carry IP packets, are established on optical LSPs. Fig. 1. Virtual Network Topology (VNT) B. Traffic-driven VNT re-configuration If the number of packet LSPs set in an optical LSP is fixed, the utilization rate of the optical LSP becomes small when the traffic carried by the packet LSPs becomes small. If there are many optical LSPs with low utilization rates, network utilization decreases, which raises costs. VNT reconfiguration, which consists of dynamically establishing and deleting optical LSPs and rerouting packet LSPs, can reduce the number of router interfaces and wavelengths. At the same time, VNT reconfiguration can prevent network congestion. In the GMPLS architecture, a link-state routing protocol is used for topology discovery. Each node advertises the link state of all links originating from the node. The residual 1-4244-1206-4/07/$25.00 ©2007 IEEE
Transcript
  • Multi-layer Traffic Engineering ExperimentalSystem in IP Optical Network

    Daisaku Shimazaki, Eiji Oki and Kohei ShiomotoNTT Network Service Systems Laboratories, NTT Corp.3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan

    Email: {shimazaki.daisaku, oki.eiji, shiomoto.kohei}@lab.ntt.cojp

    Abstract-We developed distributed-controlled multi-layertraffic engineering system. There is no previous works thatreport the system. Therefore, we can not confirm feasibility andscalability of the system. In this paper, we report an experimenton our system consisting of Internet protocol (IP) routers andoptical cross-connects (OXCs). In this system, control is providedby generalized multi-protocol label switching (GMPLS) and IPnetwork topology and IP routes are dynamically re-configuredto suit traffic characteristics. These functions prevent trafficcongestion as well as any decrease in link utilization rates. We hadexperiments to test behavior of the routers and OXCs depend-ing on traffic characteristics. We cleared that the distributed-controlled multi-protocol label switching (MPLS)/GMPLS trafficengineering system was feasible and scalable by the experiments.

    I. INTRODUCTION

    Broadband access lines bring various services to the IPnetwork. Some P2P software and video delivery servicesare causing rapid increases in traffic loads. New broadbandservices may cause unforeseeable fluctuations in traffic loads.New broadband network which can carry traffic of theseservices is required. This network should be manageablebecause it contains many types of service.MPLS/GMPLS [1] traffic engineering can meet the above

    requirement. We can strictly set the route of an MPLS/GMPLSlabel-switched path (LSP) from source node to destinationnode and collect information about LSPs, such as trafficvalues. In an LSP network, we can control the assignedbandwidth or quality-of-service (QoS) of every LSP becausethe network operator or network element can acquire all LSPinformation.

    The centralized MPLS/GMPLS network, unfortunately, hasscalability and robustness problems. The centralized networkmeans there is one node that can control the network. In thecentralized network, a specific node has all information of thenetwork and indicates all nodes. It is difficult that the specificnode has scalability and robustness.

    Therefore, we focused on the distributed MPLS/GMPLSnetwork. Many studies have examined the distributedMPLS/GMPLS network [2] - [4]. We previously proposed adistributed control mechanism for the MPLS/GMPLS network[5]. These papers proposed algorithms of distributed LSPnetwork and investigated the performance of them. However,there is no confirmation validation report. We must confirm thebehavior of the distributed mechanism, stability and processingcapacity.

    This paper introduces distributed MPLS/GMPLS net-work experiment system called as IP optical network. Weconstructed experimental system and confirmed distributedMPLS/GMPLS network control. This system can measure

    traffic rate and establish and delete optical LSP dependingon traffic demand.

    The rest of the paper is organized as follows. In Sec-tion II, we introduce a distributed virtual network topology(VNT) reconfiguration method. In Section III, distributedMPLS/GMPLS experimental system we constructed is ex-plained. In Section IV, we describe the experiment that weconfirmed in the system. In Section V, the conclusion is given.

    II. IP OPTICAL NETWORKA. Virtual Network Topology (VNT)A multi-layer GMPLS network [1] applies the concept of

    hierarchical LSPs. In the network, the higher-layer networkrefers to a lower-layer LSP as a virtual link called forwardingadjacency (FA). The virtual network consisting ofFAs is calledthe VNT [6], [7]. This paper considers two layer LSPs, packetLSP and optical LSP. Figure 1 shows that a lower-layer opticalLSP is referred to as a virtual link by a higher-layer packet LSPand the virtual network consisting of optical LSPs is called theVNT. Packet LSPs, which carry IP packets, are established onoptical LSPs.

    Fig. 1. Virtual Network Topology (VNT)

    B. Traffic-driven VNT re-configurationIf the number of packet LSPs set in an optical LSP is

    fixed, the utilization rate of the optical LSP becomes smallwhen the traffic carried by the packet LSPs becomes small. Ifthere are many optical LSPs with low utilization rates, networkutilization decreases, which raises costs. VNT reconfiguration,which consists of dynamically establishing and deleting opticalLSPs and rerouting packet LSPs, can reduce the number ofrouter interfaces and wavelengths. At the same time, VNTreconfiguration can prevent network congestion.

    In the GMPLS architecture, a link-state routing protocol isused for topology discovery. Each node advertises the linkstate of all links originating from the node. The residual

    1-4244-1206-4/07/$25.00 2007 IEEE

  • resources on each link are part of the link state. The link stateis flooded throughout the entire network. When a node sets upan LSP to a destination, it calculates a feasible route for theLSP by running the constraint-based shortest path first (CSPF)algorithm. If a feasible route is found, the node initiates theLSP setup procedure.

    In this scheme, each node runs the VNT calculation al-gorithm, which requires the current virtual network topologyand the traffic demand of the packet LSPs. The informationon traffic demand of the packet LSPs must be advertised.The GMPLS link-state routing protocol [9] is extended toinclude this traffic demand information. We need to avoidservice disruption when an optical LSP is released. The packetLSPs must be rerouted before the underlying optical LSP.To advertise an optical LSP as dormant, the GMPLS routingprotocol is extended. Once each node receives the notice of thedormant link state, it reroutes the packet LSPs on the dormantoptical LSP to non-dormant optical LSPs. After all packetLSPs are rerouted, the dormant optical LSP is torn down. Inthis way, the graceful teardown of LSP is implemented in adistributed manner.

    Fig. 2. Traffic driven VNT re-configuration

    The VNT design problem has been extensively studied forstatic traffic demand [10], [11]. The VNT can be designedfor a given initial traffic demand. As the network grows, thetraffic demand can significantly differ from the initial demand.Reconfiguration of the VNT would be required to adapt suchtraffic demand change.

    Several methods for VNT reconfiguration have been pro-posed [12], [13]. Those methods assume that the future trafficdemand is given. Those methods aimed at the reduction oftopology change in reconfiguration process. The new VNTis determined from the current one to adapt the given trafficdemand. The traffic demand is hard to anticipate accuratelyin real networks. The traffic demand also fluctuates frequentlyin real networks. Traffic measurement and reconfiguration ofthe VNT should be orchestrated to cope with unpredictabletraffic demand. A method for reconfiguration of the VNTunder dynamic traffic demand change would be required tocope with unpredictable traffic demand.

    The problem of VNT reconfiguration under dynamic trafficchanges was studied in a recent work [14]. The methoduses an off-line algorithm for time-variant offered traffic. Itassumes that a set of traffic matrices at different instants

    is known a priori. Another work on VNT under dynamictraffic changes includes an on-line reconfiguration method[15]. The method monitors the traffic instead of assuming anyfuture traffic pattern. Simple adjustments are made to currentVNT to mitigate congestion and reclaim network resourcefor under-utilized optical LSPs if possible. The method isbased on centralized control, which collects the traffic demandmeasurements and heuristically calculates the new VNT to

    suit the latest traffic demand information. The centralizedcontroller initiates optical LSP setup/teardown procedure. Aheuristic algorithm is used to calculate the VNT. A new opticalLSP is established between the end nodes of multi-hop trafficwith the highest load using the most congested optical LSP tomitigate the congestion.A distributed VNT reconfiguration mechanism that can

    handle unpredictable traffic demands is studied in [5]. In thedistributed approach, each node decides whether it shouldinitiate optical LSP setup/teardown. Unless the coordinationmechanism is properly implemented, an inconsistent VNTmight be formed. The proposed method uses a link-state rout-ing protocol for each node to share the same virtual topologyand the traffic demand over the each optical LSP, which ismeasured at the originating node. Each node calculates the newVNT using a simple heuristic algorithm, compares it with theold one, and initiates optical LSP setup/teardown if necessary.

    C. VNT re-configuration algorithmWe define two types of traffic value thresholds; TH: con-

    gestion threshold, TL: low utilization threshold, for VNT re-configuration. Traffic loads on the optical LSPs are measuredat the ingress nodes of the LSPs and VNT reconfiguration isperformed when traffic loads exceed TH or fall under TL.When traffic congestion, as determined against TH, occurs,

    the packet LSP in the congested optical LSP that has thelargest traffic value is selected to be moved. Next, the routertries to establish an optical LSP between ingress and egressnode of the target packet LSP. If the optical LSP is established,the target packet LSP is moved to the optical LSP. Thissequence is repeated until congestion is resolved.The router tries to delete any optical LSP whose traffic load

    is under TL. Of course, before the deletion, all packet LSPsare moved to other optical LSPs without triggering congestion.This sequence is also repeated until the link's low utilizationis resolved.

    Fig. 3. VNT re-configuration algorithm

    D. Advertisement of traffic loadsAs mentioned above, traffic information is advertised by

    extended open shortest path first (OSPF). Traffic loads aremeasured at the ingress nodes of packet and optical LSPs.The utilized bandwidth information is advertised by the OSPFformat shown in Figure4. The value of sub TLV type is32773 for packet LSPs and 32774 for optical LSPs. Utilizedbandwidth is given in units of mega bytes per second in IEEEfloating Point format.

  • 0 1 2 301234561890123456189012345618901

    Type length

    Utilized bandwidth

    Fig. 4. OSPF extension for advertisement of bandwidth utilization

    III. EXPERIMENTAL NETWORK

    The experimental network system consisted of GMPLSrouters, GMPLS OXCs, traffic generators, and a VNT viewer.This section describes each piece of equipment.

    A. Multi-layer networkFigure shows the experimental network.

    VNT aview - I

    Optical 1NTview 4 NT, 77777 ' e wer

    W:oXC3 :Traffic Generator

    Fig. 5. Traffic-driven VNT reconfiguration experimental network

    In this multi-layer network, Optical LSPs, whose LSP typeis FSC, are established between GMPLS routers. Packet LSPsare established via Optical LSPs terminated in GMPLS routers.In this experimental network, Packet LSPs are representedby MPLS LSPs, which are terminated in GMPLS routers,the same as Optical LSPs. Therefore, routers in this networkhandle GMPLS and MPLS entities.

    Table shows the software specifications. We used RED-HAT Linux patched by MPLS-Linux [17], open-source soft-ware, to realize label switched routing. To forward pack-ets, we must change parameter net.ipv4.ip forward in the/etc/sysctl.conf file to enable.

    No. Item Spec

    1 CPU Pentium 4 3.2GHz2 RAM 2GB DDR2-SDRAM 400MHz ECC3 NIC > 1OOBASE-T x 3 (Control plane IF, One or

    more GMPLS data plane IF, One or moreMPLS data plane)

    Fig. 7. Hardware specifications of PCs for GMPLS router

    [Redhat Linux 9 kernel 2.4.20 + MPLS Linux1.172Self-manufactured software (OSPF-TE,RSVP-TE)

    Fig. 8. Software specifications for GMPLS router

    Figure 9 shows the hardware and software structure ofthe GMPLS router PC. GMPLS controller gathers trafficinformation from the network interface cards by the simplenetwork management protocol (SNMP).

    Os risement

    Other nodeH/W

    Fig. 6. Hierarchical network

    B. Router

    We realized GMPLS routers on commercial PCs. Tableshows the hardware specifications of the PCs. The PCs hadseveral network interface cards. One interface card is used forthe GMPLS control plane. The GMPLS control plane interfacesends and receives OSPF advertisement packets and RSVP-TE signaling packets, which establish or release LSPs. Otherinterface cards are used to implement the GMPLS and MPLSdata planes. Each PC had as many data plane interfaces as thenumber of TE-links.

    Fig. 9. PC module structure for GMPLS router

    Figure 10 shows the software module structure of theGMPLS controller.

    In this experimental system, we used self-written GMPLScontroller software. If NetBSD operating system is used forthe platform of GMPLS PC router, there is some open sourceMPLS software, such as AYAME [16].C. OXCThe GMPLS OXC consists of commercial available optical

    switches and the GMPLS controller mentioned above (Figure10). We realized the GMPLS controller by adding the opticalswitch control function to the controller designed for GMPLSrouters. In contrast, TRM and CSPF were deleted because thefunctions of gathering traffic information and route calculationwere not needed.

    . Make configuration file for GMPLS controller software.SW-PORT is related to SW TYPE, IF ID and Label.

    . Compare SW TYPE, IF ID and Label in RSVP messageand GMPLS controller configuration.

    . Change the optical switch.

  • Fig. 10. GMPLS Controller module structure

    GMPLScoGntLrolntrplplnnsignal - * Q .RSVP TE signaling

    GMPLS TE-link SW I/F7_

    Optical switch i

    D. Traffic generator

    TrfGen is the tool that enables to generate traffic from any to

    any and consists of traffic transceiver unit and controller unit.

    Figure 13 shows characteristics of controller unit of TrfGen.Traffic pattern in IP network is studied in [18] [20]. Wecan define traffic pattern as any probability model functionfor each pairs of sender and receiver and program the patternsas a traffic schedule. Figure 14 shows the preference view oftraffic profile. We can change the function of packet size andinter-departure time of traffic pattern as exponential, Paretoand constant distribution. The packet over MTU size willbe divided and sent. Figure 15 shows the view of schedulepreference of traffic pattern. The transceiver unit of TrfGen isbased on I-ITG version 2.4 [21] which is free software.

    Fig. 12. Configuration table of GMPLS controller for OXC

    Traffic volume fi(x): data size11t r, |(1 )Constant

    (2)Exponentialfi(x) (3)Pareto

    -4 4-- im e

    .2

    3

    ..... /

    TX 2

    Fig. 13. Traffic generator system structure

    Fig. 14. Preference view of traffic pattern profile

    E. VNT ViewerVNT viewer is the tool that enables the network status to be

    visible. Figure 16 shows view of it. It receives IP and opticallayer traffic engineering information by OSPF and displaysit as topology. It also gathers route information of LSP fromingress router. It can display the traffic value graph of LSPs.The traffic value information is gathered from ingress routerby SNMP. We can grasp network status in real time from VNTviewer.

    IV. VNT RECONFIGURATION EXPERIMENT

    A. Feasibility of VNT reconfiguration experiment with trafficincreaseldecrease scenario

    Packet LSPs were established between all routers. OpticalLSPs were established between Router A - OXC 1 - RouterB (optical LSP 1) and Router B - OXC 2 - Router C (opticalLSP 2). Packet LSP 1 between Router A and Router B wasestablished via optical LSP 1. Packet LSP 2 between Router Band Router C was established via optical LSP 2. Packet LSP3 between Router A and Router C was established via opticalLSP 1 and 2.

    Constant traffic patterns were loaded to packet LSP 1, 2 andfluctuant traffic was loaded to packet LSP 3. TH = 80kbps,TL = 1Okbps. Figure 17 shows VNT reconfiguration wasperformed when traffic whose pattern was Pareto distributionwith 1.9 shape parameter was loaded. The parameter e infigure 17 means moving-average parameter that was applied tomeasured traffic value, see Equation (1). Rn is the statisticalrate, e is the moving-average parameter, X, is rate measured

    SW-TYPE IF-ID UPSTREAM SW-PORT/LABEL

    FSC A_i D.C. X_i (upstream)X_i (downstream)

    LSC A_i L X_ij (upstream)(upstream) X-ijL (downstream)

    I__ I______ (downstream) I

  • 250Theoretical reconfiguration timee=O.1200

    7 150

    50

    00 5 10 15 20 25 30

    Time [hour]Fig. 17. VNT reconfiguration experiment with traffic increase/decreasescenario

    Fig. 15. Preference view of traffic pattern schedule

    P-layer view(IP topology, MPLS LSP loadMPLS LSP route) graph

    _ ..-

    _ *sP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Il

    information is advertised by extended OSPF has no scalabilityproblem in the aspect of OSPF advertisement load.

    100000

    c 10000

    u 1000

    100Ct

    o ~ 10

    C 10 1

    0.11 10 100

    Number of nodesOptical-layer view ./ >(Fiber topology, Optical LSP Status viewroute)

    Fig. 16. VNT Viewer

    the n-th measurement. Equation (1) shows that a small eemphasizes the past statistical rate.

    Rn = eXn + (1 -e)Rn-1 (1)

    Figure 17 shows that VNT re-configuration was performedwhen measured traffic value was over TH and under TLsuccessfully and the traffic pattern whose shape parameter was1.9 did not need smoothing with moving average parameter.

    B. ScalabilityAs mentioned above, the traffic value information is ad-

    vertised by OSPF. We should investigate OSPF load becauseOSPF advertisement interval will be short. Figure 18 showsestimated OSPF load and measured plots. Each plot is averageof three times measurements. We estimated OSPF load usingOSPF packet format [22], [9] and 4. Estimation condition;Average nodal degree: 2.2, OSPF update interval: 2 seconds,packet LSP: established between all nodes. We also measuredOSPF load in the experimental system. The measured plotswere almost on the estimated line. Figure 18 shows that thecontrol plane of 1000 nodes network should have throughputabout 15Mbps. Therefore, the method that the traffic value

    Fig. 18. Load of OSPF advertisement

    We also measured consumed processor power of GMPLSrouter shown by figure 19. Each plot is average of three timesmeasurements. Figure 19 shows that there is little correlationbetween gathering period of traffic value information andaverage CPU utilization ratio. Therefore, the method that thetraffic value information is advertised by extended OSPF hasfew scalability problems in the aspect of OSPF processingload.C. Packet loss experiment caused by make-before-break

    In this experiment, make-before-break was performed byMPLS LSP rerouting since this should, in theory, preventpacket loss. Make-before-break means the procedure of rewrit-ing ingress and egress router tables, see figure 20.We measured packet loss in the network topology shown in

    IV-A. The threshold traffic rates are TH = 100kbps, 1Mbps,10Mbps, TL = 4kbps, 40kbps, 400kbps. Figure 21 showsthe result. This figure shows that no packet loss occurred indecreasing traffic rate. By contrast, some packet loss occurredin increasing traffic rate.We described the reason why packet loss occurs below.

    Packet order reversalProcess power shortage of the hardwareothers

    We first captured egress node interface to check whetherpacket order reversal occur or not when VNT reconfiguration

    e=l

    A.ooook~verage rate --- - e=0 1

    j ._ T I T

    TL- l/

    1000

    .l 3k. .l

    e=l1 oc=l1.9

  • interface.2.5

    2

    15

    1 1

    U 05

    Router 1 *

    Router 2

    Router 3 AA A

    4Gathering period [sec]

    8

    Fig. 19. Consumed CPU power for processing traffic value advertisement

    Ingress Egress

    RSVP PATH

    RSVP RESV

    RSVP CONF

    (0 Add new label table entry(2 Change label table entry(O Delete old label table entry

    Fig. 20. Make-before-break procedure

    occurred. We recognized however packets were not forwardedto next hop in ingress node during about 1 second.We checked the next reason. We assumed that the PC router

    did not have enough processor power to forward the packetswithout packet loss. We measured packet loss with differentialtraffic rate. Figure 21 shows the results. In our experimentsystem, the packet loss occurred with 100 kbps in increasingcase. In contract, the router PC can forward the packets with400 kbps without packet loss in the decrease case. We canassume that processor power shortage of the hardware wasnot the cause of packet loss with comparison between bothexperiments.We made additional investigations and it become clear that

    it takes the Linux kernel a significant time to recognize a new

    Threshold TH 1 OOK 1 M 1OMVNT reconfiguration A A Awith traffic increasing

    Threshold TL 4K 40K 400KVNT reconfiguration 0 0with traffic decreasing

    A: Occasional packet loss0: No packet loss in every times* We tried each test three times.

    Fig. 21. Measurement result of packet loss in VNT reconfiguration withmake-before-break

    V. CONCLUSION

    In this paper, we developed IP Optical traffic engineeringtechnologies to address the requirements. We report the ex-periment of IP optical traffic engineering that IP routers andOXCs are controlled by GMPLS and IP network topology andIP routing are dynamically re-configured depending on trafficvalue increase and decrease. These function achieved preven-tion of traffic congestion or decrease of link utilization ratio.We also confirmed the scalability of our distributed networkscontrol system logically and experimentally. Additionally, itbecame clear that make-before-break method prevented packetloss.

    REFERENCES[1] E. Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Ar-

    chitecture," IETF RFC, RFC 3945, Oct. 2004.[2] M. Kodialam and T. V. Lakshman, "Dynamic Routing of Restorable

    Bandwidth-Guaranteed Tunnels Using Aggregated Network ResourceUsage Information," IEEE/ACM Trans. Networking, vol. 11, no. 3,pp.399-410, Jun. 2003.

    [3] S. Butenweg, "Two distributed reactive MPLS traffic engineering mech-anisms for throughput optimization in best effort MPLS networks," Proc.of ISCC 2003, vol. 1, pp. 379-384, Jul. 2003.

    [4] B. Dekeris and L. Narbutaite, "Traffic control mechanism within MPLSnetworks," Proc. of ITI 2004, vol. 1, pp. 603-608, Jun. 2004.

    [5] K. Shiomoto, E. Oki, W. Imajuku, S. Okamoto, N. Yamanaka, "Dis-tributed Virtual Network Topology Control Mechanism in GMPLS-BasedMultiregion Networks," IEEE JSAC, Vol. 21, No. 8, p.p. 1254 - 1262,Oct. 2003.

    [6] K. Shiomoto, D. Papadimitriou, J.L. Le Roux, M. Vigoureux, D. Brun-gard, "Requirements for GMPLS-based multi-region and multi-layernetworks (MRN/MLN)," IETF draft, draft-ietf-ccamp-gmpls-mln-reqs-02.txt, Oct. 2006, work in progress.

    [7] J.L. Le Roux, D. Brungard, E. Oki, D. Papadimitriou, K. Shiomoto,M. Vigoureux, "Evaluation of existing GMPLS Protocols against MultiLayer and Multi Region Networks (MLN/MRN)," IETF draft, draft-ietf-ccampgmpls-mln-eval-02.txt, Oct. 2006, work in progress.

    [8] K. Kompella and Y. Rekhter, "Routing Extensions in Support of General-ized Multi-Protocol Label Switching (GMPLS)," IETF RFC, RFC 4202,Oct. 2005.

    [9] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of GeneralizedMulti-Protocol Label Switching (GMPLS)," IETF RFC, RFC 4203, Oct.2005.

    [10] R. Ramaswami and K. N. Sivarajan, "Design of logical topologies forwavelength-routed optical networks," IEEE J. Selected Areas Commun.,vol. 14, pp. 840 - 851, June 1996.

    [11] B. Mukherjee, D. Banerjee, S. Ramamurthy, and A. Mukherjee, "Someprinciples for designing a wide-area WDM optical network," IEEE/ACMTrans. Networking, vol. 4, pp. 684 - 696, Oct. 1996.

    [12] J.-F. P. Labourdette, G. W. Hart, and A. S. Acampora, "Logicallyrearrangeable multihop lightwave networks," IEEE Trans. Commun.,vol.39, pp. 1223 - 1230, Aug. 1991.

    [13] D. Banerjee and B. Mukherjee, "Wavelength-routed optical networks:Linear formulation, resource budgeting tradeoffs, and a reconfigurationstudy," IEEE/ACM Trans. Networking, vol. 8, pp. 598 - 607, Oct. 2000.

    [14] F. Ricciato, S. Salsano, A. Belmonte, and M. Listanti, "Off-line con-figuration of a MPLS over WDM network under time-varying offeredtraffic," in Proc. IEEE INFOCOM, vol. 1, June 2002, pp. 57 - 65.

    [15] A. Gencata and B. Mukherjee, "Virtual-topology adaptation for WDMmesh networks under dynamic traffic," in Proc. IEEE INFOCOM, vol. 1,June 2002, pp. 48 - 56.

    [16] http://www.ayame.org/index.php[17] http://mpls-linux.sourceforge.net/[18] K. Thompson, G.J. Miller, R. Wilder, "Wide-area Internet traffic patterns

    and characteristics," IEEE Network, Vol. 11, Issue 6, pp. 10-23, Nov.-Dec.1997.

    [19] V. Paxson and S. Floyd, "Wide Area Traffic: The Failure of PoissonModeling," IEEE/ACM Trans. on Networking, pp. 236-244, June 1995.

    [20] W. Leland, M. Taqqu, W. Willinger, and D. Wilson, "On the Self-Similar Nature of Ethernet Traffic (Extended Version)," IEEE/ACMTrans.on Networking, pp. 1-15, Feb. 1994.

    [21] http://www.grid.unina.it/software/ITG/download.php

    [22] J. Moy, "OSPF Version 2," IETF RFC, RFC 2328, Apr. 1998.