service profile-aware control plane - ku ittc · 2005-07-07 · wesam alanqar b.s.e.e., uae...

1

Service Profile-Aware Control Plane:

A Multi-Instance Fixed Point Approximation within a Multi-Granularity VPN Loss Networks Perspective

BByy WWeessaamm AAllaannqqaarr

BB..SS..EE..EE..,, UUAAEE UUnniivveerrssiittyy,, UUAAEE,, 11999977 MM..SS..EE..EE..,, UUnniivveerrssiittyy ooff MMiissssoouurrii--CCoolluummbbiiaa,, 11999999

Submitted to the Department of Electrical Engineering and Computer Science and the Faculty of the Graduate School of the University of Kansas in partial fulfillment of the requirements for the degree of Doctor of Philosophy

4

ABSTRACT The need to establish network connections in a service profile-aware fashion is becoming

increasingly important due to the variety of candidate wired and wireless client networks with

Quality of Service (QoS) networking infrastructures for some of emerging services like

VoIP/Multimedia for wireless networks and Ethernet for wired networks. The control plane

optimization of network connections will have to take into account a number of service

profile parameters and network constraints to efficiently utilize network resources. In a

networking scenario where a multi-service operation in common network infrastructure is

assumed, efficient algorithms and protocols for service profile-differentiation and dynamic

allocation of network resources will play a key role. To fulfill this need, a new Service

Profile-Aware (SPA) control plane model is required to play a vital role in future converged

wired and wireless networks in integrating service profile layer, control plane layer, and

switching infrastructure layer.

Up until now, the criteria for network infrastructure operation via the existing Internet

Engineering Task Force (IETF) and International Telecommunications Union (ITU) control

plane models do not consider the service profile layer when establishing network

connections. This work proposes the novel concept of a SPA control plane model that

demonstrates its superiority over existing control plane models in multiple aspects including

full realization of the multi-granularity network resources, and its complete consideration for

services’ architectures and their associated service profile feature set. Detailed comparison

between the three control plane models were considered from multiple dimensions including

traffic management schemes, components-level interaction between (service profile, control

plane, network infrastructure) layers, and network infrastructure realization from both

horizontal “network domains” and vertical “resource granularity and network partitions”

perspective. Multiple service models were analyzed based on their service profile parameters

from both an architectural and mathematical perspective. Detailed mathematical analysis of

the three control plane models was performed based on a multi-instance Fixed Point

Approximation (FPA) within a multi-granularity Virtual Private Network (VPN) loss

networks. The performance analysis of the SPA new traffic management schemes found a

significant increase in service allowed load while maintaining lower service blocking

probability and network utilization over IETF and ITU control plane models.

5

ACKNOWLEDGMENTS This dissertation could not have been completed without the support and inspiration of many

people. I would like to acknowledge the contributions of, and thank, the following: My

academic and dissertation advisor, Dr. Victor Frost for his vision for this project and his

guidance and persistence in insisting on high quality results. His timely suggestions and

feedback helped me immensely in my work. The trust that he put in my technical capabilities

has been a strong support and encouragement during the hard times I faced while completing

my residency requirement and working on the dissertation.

I am grateful to my parents, Ibrahim Alanqar and Laila Qaradaya, for all their prayers and for

giving me the gifts of life and education. I couldn’t have reached what I have achieved in life

without their sacrifices. I can never forget they instilled in me values of conviction,

persistence, and hard work.

My wife and friend, Haya Qadi Al-Tamimi, for her sacrifice, encouragement and support of

my efforts throughout my four years of study. Her walk with God, support, sacrifice,

encouragement, and love for me has been a source of constant strength. I can never thank her

enough for her patience and understanding on those days during this undertaking where my

approach to family needs and life in general was less than optimum. My two sons, Loay and

Qusay, for living their first few years without their father being available for them.

My twin sister, Taghreed, for her love that will continue growing in my heart for the rest of

my life. My two sisters, Amal and Areej, for their true love. My brothers, Wael and Waleed,

for their love and continuous encouragement.

Above all, to God for giving me the strength and confidence to realize my goals.

6

TABLE OF CONTENTS

1 Introduction................................................................................................................... 23 1.1 Problem statement ..............................................................................................................23 1.2 Problem motivation/significance ........................................................................................23 1.3 Research approach..............................................................................................................24 1.4 Research hypotheses...........................................................................................................24 1.5 Research objectives ............................................................................................................25 1.6 Overview ............................................................................................................................26

2 Background- Previous Research and Standardization Efforts................................. 27 3 Configured VPN Service Models- Service Profile Parameters ................................. 33

3.1 Definitions and notation .....................................................................................................35 3.2 Configured VPN service models ........................................................................................37

3.2.1 Point Dedicated Actual (PDA) ................................................................................. 39 3.2.2 Point Shared Actual (PSA) and Point Shared Granular (PSG) ................................. 39 3.2.3 Semi-meshed Dedicated Actual (SDA) .................................................................... 40 3.2.4 Semi-meshed Shared Actual (SSA) and Semi-meshed Shared Granular (SSG)....... 41 3.2.5 Fully-meshed Dedicated Actual (FDA) .................................................................... 43 3.2.6 Fully-meshed Shared Actual (FSA) and Fully-meshed Shared Granular (FSG) ...... 44

4 Control Plane Models- Traffic Management Schemes .............................................. 46 4.1 Control plane components overview ..................................................................................46 4.2 Traffic management capabilities definitions.......................................................................49 4.3 Control plane models and associated traffic management capabilities...............................51 4.4 IETF control plane model...................................................................................................54 4.5 ITU control plane model.....................................................................................................55 4.6 SPA-Dedicated control plane model..................................................................................56

4.7 SPA-Shared control plane model.......................................................................................56

5 Control Plane Models– Transport Network Realization........................................... 59 5.1 Horizontal view: multi-domain realization.........................................................................59 5.2 Vertical view: multi-granularity realization .......................................................................61

5.2.1 IETF control plane model ......................................................................................... 61 5.2.2 ITU control plane model........................................................................................... 62 5.2.3 SPA control plane model .......................................................................................... 63

5.3 Vertical view: resources partitioning..................................................................................65

7


6 Control Plane Models- Component-Level Interaction .............................................. 69 6.1 IETF control plane model...................................................................................................70 6.2 ITU control plane model.....................................................................................................72 6.3 SPA control plane model ....................................................................................................74

7 Analysis Methodology – Fixed Point Approximation ................................................ 77 7.1 Notation ..............................................................................................................................80 7.2 Fixed Point Approximation (FPA) framework...................................................................85


8 Mathematical Formulation of Control Plane Models for Traffic Management Schemes ....................................................................................................................... 92

8.1 Step-1 CAC for multi-rate service requests ........................................................................93 8.1.1 Base method ............................................................................................................. 93 8.1.2 IETF control plane model ......................................................................................... 94 8.1.3 ITU and SPA-Dedicated control plane model .......................................................... 95 8.1.4 SPA-Shared control plane model.............................................................................. 96

8.2 Step-2: Calculating link’s reduced load.............................................................................96 8.2.1 Base method ............................................................................................................. 96 8.2.2 IETF control plane model ......................................................................................... 97 8.2.3 ITU and SPA-Dedicated control plane models......................................................... 97 8.2.4 SPA-Shared with static load partitioning (without NE)............................................ 97 8.2.5 SPA-Shared with dynamic load partitioning (with NE) ........................................... 99

8.3 Step-3: Calculating link’s occupancy probability and admissibility probability ..............100 8.3.1 Base method ........................................................................................................... 100 8.3.2 IETF control plane model ....................................................................................... 100 8.3.3 ITU and SPA-Dedicated control plane model ........................................................ 101 8.3.4 SPA-Shared- Static load partitioning and disabled inverse multiplexing (without NE,

without IM)............................................................................................................. 102 8.3.5 SPA-Shared- Dynamic load partitioning and disabled inverse multiplexing (with NE,

without IM)............................................................................................................. 103 8.3.6 SPA-Shared- Static load partitioning and enabled inverse multiplexing (without NE,

with IM).................................................................................................................. 103

8

8.3.7 SPA-Shared- Dynamic load partitioning and enabled inverse multiplexing (with NE, with IM).................................................................................................................. 104

8.4 Step-4: Calculating routing probability for each possible route .......................................104 8.4.1 Base method ........................................................................................................... 104 8.4.2 IETF control plane model ....................................................................................... 105 8.4.3 ITU control plane model......................................................................................... 106 8.4.4 SPA-Dedicated control plane model....................................................................... 106 8.4.5 SPA-Shared control plane model............................................................................ 106

8.5 Step-5: Compute network-wide blocking probability.......................................................107 8.5.1 Base Methods ......................................................................................................... 107 8.5.2 IETF control plane model ....................................................................................... 107 8.5.3 ITU and SPA-Dedicated control plane models....................................................... 107 8.5.4 SPA-Shared control plane models .......................................................................... 108

8.6 Step-6: Compute network-wide average permissible load ...............................................109 8.6.1 IETF control plane model ....................................................................................... 109 8.6.2 ITU and SPA-Dedicated control plane models....................................................... 109 8.6.3 SPA-Shared control plane models .......................................................................... 110

8.7 Step-7: Compute network-wide utilization.......................................................................111 8.7.1 IETF control plane model ....................................................................................... 111 8.7.2 ITU and SPA-Dedicated control plane models....................................................... 111 8.7.3 SPA-Shared control plane models .......................................................................... 111

9 Scenarios and Performance Evaluation .................................................................... 112 9.1 Network topology analyzed..............................................................................................112 9.2 Modeling parameters ........................................................................................................116

9.2.1 Parameters specifics of input load .......................................................................... 116 9.2.2 Parameters specifics of control plane components ................................................. 116 9.2.3 Parameters specifics of configured VPN service models considered ..................... 118

9.3 Performance metrics .........................................................................................................118 9.4 Modeling environment .....................................................................................................122

10 Computational Cost of the Traffic Management Schemes...................................... 124 10.1 Computed cost of FPA....................................................................................................124

10.1.1 Base model ............................................................................................................. 124 10.1.2 IETF control plane model ....................................................................................... 125 10.1.3 ITU control plane model......................................................................................... 125 10.1.4 SPA-Dedicated control plane model....................................................................... 126

9

10.1.5 SPA-Shared control plane model............................................................................ 126 10.2 Implementation cost........................................................................................................126

10.2.1 IETF control plane model ....................................................................................... 127 10.2.2 ITU control plane model......................................................................................... 128 10.2.3 SPA-Dedicated control plane model....................................................................... 129 10.2.4 SPA-Shared control plane model............................................................................ 129

11 Discussion of Model Validation and Accuracy ......................................................... 132 11.1 Discussion of model validation.......................................................................................132

11.1.1 Fixed point uniqueness ........................................................................................... 132 11.1.1.1 Alternate routing impact ...................................................................................... 132 11.1.1.2 Connection admission control via trunk reservation............................................ 137

11.1.2 Accuracy of mathematical models assumptions ..................................................... 137 11.2 Discussion of model accuracy ........................................................................................142

11.2.1 Occupancy probabilities computation..................................................................... 142 11.2.2 Routing probabilities computation.......................................................................... 144 11.2.3 LPF and IMF traffic management operations ......................................................... 145

11.3 Discussion of trends in system performance ..................................................................146 11.3.1 Analysis of operational space for network topologies and services........................ 146 11.3.2 7-node topology case study..................................................................................... 148

12 Summary of System Performance ............................................................................. 151 12.1 Average network-wide blocking probability ..................................................................152 12.2 Average per source-destination pair permissible load ....................................................153 12.3 Average network-wide resource utilization ....................................................................155

13 Discussion of the Impact of SPA Functionality on System Performance............... 163 13.1 State-Dependent routing impact on blocking probability ...............................................163 13.2 State-Dependent routing impact on permissible load .....................................................164 13.3 State-Dependent routing impact on utilization ...............................................................164 13.4 w/o(NE,IM) traffic management scheme impact on blocking probability .....................164 13.5 w/o(NE,IM) traffic management scheme impact on permissible load............................165 13.6 w/o(NE,IM) traffic management scheme impact on utilization......................................165 13.7 (w/NE,w/oIM) traffic management scheme impact on blocking probability .................166 13.8 (w/NE,w/oIM) traffic management scheme impact on permissible load........................166 13.9 (w/NE,w/oIM) traffic management scheme impact on utilization..................................166 13.10 (w/oNE,w/IM) traffic management scheme impact on blocking probability ..............167

10

13.11 (w/oNE,w/IM) traffic management scheme impact on permissible load.....................167 13.12 (w/oNE,w/IM) traffic management scheme impact on utilization...............................167 13.13 w/(NE,IM) traffic management scheme impact on blocking probability ....................168 13.14 w/(NE,IM) traffic management scheme impact on permissible load...........................168 13.15 w/(NE,IM) traffic management scheme impact on utilization.....................................169 13.16 Generalizing the performance analysis results..............................................................169

13.16.1 SPA superiority trend based on 4-node and 7-node topologies .............................. 169 13.16.2 SPA superiority trend justification based on the performance impact of the SPA

control plane model components ............................................................................ 170 14 Conclusions .................................................................................................................. 201 15 Next Steps - Future Related Work ............................................................................ 202

15.1 IETF control plane model ...............................................................................................205 15.2 ITU control plane model.................................................................................................205 15.3 SPA control plane model ................................................................................................205

16 References .................................................................................................................... 208 16.1 Journals & papers ...........................................................................................................208

16.1.1 Single-Domain control plane function analysis ...................................................... 208 16.1.2 Next-Generation SONET........................................................................................ 208

16.2 Standards recommendations ...........................................................................................209 16.2.1 ITU-T optical control building blocks generic architecture.................................... 209 16.2.2 ITU-T protocol specific implementations............................................................... 209 16.2.3 ITU-T optical transport standards........................................................................... 210 16.2.4 IETF GMPLS building blocks specific protocols................................................... 210

16.3 Traffic allocation and resource partitioning schemes .....................................................211 16.4 Fixed point approximation for multi-rate loss networks.................................................212 16.5 Optical networking market analysis................................................................................213

17 Appendix-A: List of Acronyms.................................................................................. 214 18 Appendix-B: Pseudo-Code generic algorithms......................................................... 216

18.1 IETF control plane model ...............................................................................................216 18.2 ITU control plane model.................................................................................................217 18.3 SPA-Dedicated control plane model...............................................................................218 18.4 SPA-Shared control plane model....................................................................................219

19 Appendix-C: Detailed Modeling Results- 4-Node Topology ................................... 222 19.1 Blocking probability .......................................................................................................222

11

19.1.1 Dedicated resources ................................................................................................ 222 19.1.2 Shared resources ..................................................................................................... 227 19.1.3 VPN resources ........................................................................................................ 232 19.1.4 Physical resources................................................................................................... 238

19.2 Permissible load..............................................................................................................244 19.2.1 Dedicated resources ................................................................................................ 244 19.2.2 Shared resources ..................................................................................................... 249 19.2.3 VPN resources ........................................................................................................ 254 19.2.4 Physical resources................................................................................................... 260

19.3 Utilization .......................................................................................................................266 20 Appendix-D: Detailed Modeling Results- 7-Node Topology with 2-Alternate

Routing ...................................................................................................................... 271 20.1 Blocking probability .......................................................................................................271

20.1.1 Dedicated resources ................................................................................................ 271 20.1.2 Shared resources ..................................................................................................... 276 20.1.3 VPN resources ........................................................................................................ 281

20.2 Permissible load..............................................................................................................287 20.2.1 Dedicated resources ................................................................................................ 287 20.2.2 Shared resources ..................................................................................................... 292 20.2.3 VPN resources ........................................................................................................ 297

21 Appendix-E: Detailed Modeling Results- 7-Node Topology with 3-Alternate Routing ...................................................................................................................... 303

21.1 Blocking probability .......................................................................................................303 21.1.1 Dedicated resources ................................................................................................ 303 21.1.2 Shared resources ..................................................................................................... 308 21.1.3 VPN resources ........................................................................................................ 313

21.2 Permissible load..............................................................................................................319 21.2.1 Dedicated resources ................................................................................................ 319 21.2.2 Shared resources ..................................................................................................... 324 21.2.3 VPN resources ........................................................................................................ 329

12

LIST OF FIGURES

Figure 2-1: Mapping ITU-T Generic Control Plane Architectures Recommendations to IETF

Control Plane Protocols .................................................................................................. 32 Figure 3-1: Coarse, Actual, Granular Bandwidth Relationship .............................................. 36 Figure 3-2: Configured VPN Service Models......................................................................... 38 Figure 3-3: PDA Service Configuration ................................................................................. 39 Figure 3-4: PSA and PSG Service Configurations ................................................................ 40 Figure 3-5: SDA Service Configuration ................................................................................ 41 Figure 3-6: SSA and SSG Service Configurations ................................................................ 42 Figure 3-7: FDA Service Configuration ................................................................................ 43 Figure 3-8: FSA and FSG Service Configurations ................................................................. 45 Figure 4-1: Control Plane Components .................................................................................. 49 Figure 4-2: Control Plane Models Based on Traffic Management Schemes.......................... 53 Figure 4-3: Traffic Management of IETF Control Plane Model............................................. 54 Figure 4-4: Traffic Management of ITU Control Plane Model .............................................. 56 Figure 4-5: Traffic Management of SPA Shared Control Plane Model................................. 58 Figure 5-1: Control Plane Routing Areas Realization of Transport Network Partitioning into

Sub-Networks ................................................................................................................. 60 Figure 5-2: IETF Control Plane Model Realization of Transport Network Granularity Levels

........................................................................................................................................ 64 Figure 5-3: ITU and SPA-Dedicated Control Plane Models Realization of Transport Network

Granularity Levels .......................................................................................................... 64 Figure 5-4: SPA-Shared Control Plane Models Realization of Transport Network Granularity

Levels.............................................................................................................................. 65 Figure 5-5: Instance Realization of Transport Network Partitions for the IETF Control Plane

........................................................................................................................................ 67 Figure 5-6: Instance Realization of Transport Network Partitions for ITU/SPA-Dedicated

Control Plane Models ..................................................................................................... 68 Figure 5-7: Instance Realization of Transport Network Partitions for the SPA-Shared Control

Plane................................................................................................................................ 69 Figure 6-1: IETF Control Plane Components Operational Flow Sequence............................ 71 Figure 6-2: ITU Control Plane Components Operational Flow Sequence ............................. 73

13

Figure 6-3: SPA-Dedicated Control Plane Components Operational Flow Sequence ........... 76 Figure 6-4: SPA-Shared Control Plane Components Operational Flow Sequence ................ 77 Figure 7-1: Fixed Point Approximation (FPA) Computation Steps ....................................... 87 Figure 7-2: FPA Framework................................................................................................... 87 Figure 7-3: IETF single FPA Instance for Three Transport Network Partitions .................... 88 Figure 7-4: ITU Three FPA Instances for Three Transport Network Partitions..................... 90 Figure 7-5: SPA-Dedicated Three FPA Instances for Three Transport Network Partitions... 91 Figure 7-6: SPA-Shared Three FPA Instances for Three Transport Network Partitions........ 92 Figure 9-1: Modeled ITU, SPA-Dedicated Network Partitions Compared to IETF Physical

Resources “4-node topology” ....................................................................................... 113 Figure 9-2: Modeled SPA-Shared Network Partitions Compared to IETF Physical Resources

...................................................................................................................................... 114 Figure 9-3: Modeled ITU, SPA-Dedicated Network Partitions Compared to IETF Physical

Resources “7-node topology” ....................................................................................... 114 Figure 9-4: Modeled SPA-Shared Network Partitions Compared to IETF Physical Resources

...................................................................................................................................... 115 Figure 9-5: Modeled SPA-Shared Network Partitions Compared to IETF Physical Resources

“7-node topology”- 1 STS-1 Sharing Scenario............................................................. 116 Figure 9-6: Modeling Environment ...................................................................................... 123 Figure 11-1: Network Topologies Analyzed in Base Method .............................................. 139 Figure 12-1: Network-Wide Blocking Probability Percentage Reduction (IETF-DR as

Reference Model)- 7-node with 2-Alternate Routing ................................................... 157 Figure 12-2: Network-Wide Blocking Probability Percentage Reduction (IETF-DR as

Reference Model)- 7-node with 3-Alternate Routing ................................................... 158 Figure 12-3: Network-Wide Permissible Load Percentage Difference (IETF-DR as Reference

Model) - 7-node with 2-Alternate Routing ................................................................... 159 Figure 12-4: Network-Wide Permissible Load Percentage Difference (IETF-DR as Reference

Model) - 7-node with 3-Alternate Routing ................................................................... 160 Figure 12-5: Network-Wide Utilization Percentage Reduction (IETF-DR as Reference

Model) - 7-node with 2-Alternate Routing ................................................................... 161 Figure 12-6: Network-Wide Utilization Percentage Reduction (IETF-DR as Reference

Model) - 7-node with 3-Alternate Routing ................................................................... 162

14

Figure 13-1: Average Network-Wide Blocking Probability (Physical Resources)-7 Node-2

Alternate Route- IETF (DR, SR), ITU (DR, SR), SPA-Dedicated............................... 173 Figure 13-2: Average Network-Wide Blocking Probability (Physical Resources)-7 Node –2

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM) ............................... 174 Figure 13-3: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM) ............................ 175 Figure 13-4: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM) ............................ 176 Figure 13-5: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM) .................................. 177 Figure 13-6: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2

Alternate Route- IETF(DR,SR), ITU(DR,SR),............................................................. 178 Figure 13-7: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM) ............................... 179 Figure 13-8: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 2

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM) ........................... 180 Figure 13-9: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 2

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM) ........................... 181 Figure 13-10: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM) ................................. 182 Figure 13-11: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM) ................................................. 183 Figure 13-12: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM................................................ 184 Figure 13-13: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM................................................ 185 Figure 13-14: Average Network-Wide Utilization (Physical Resources)-7 Node – 2 Alternate

Route-IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM) .................................................... 186 Figure 13-15: Average Network-Wide Blocking Probability (Physical Resources)-7 Node-3

Alternate Route- IETF (DR, SR), ITU (DR, SR), SPA-Dedicated............................... 187 Figure 13-16: Average Network-Wide Blocking Probability (Physical Resources)-7 Node –3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM) ............................... 188

15

Figure 13-17: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM) ............................ 189 Figure 13-18: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM) ............................ 190 Figure 13-19: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3

Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM) .................................. 191 Figure 13-20: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-Dedicated................................... 192 Figure 13-21: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM) ............................... 193 Figure 13-22: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM) ........................... 194 Figure 13-23: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM) ........................... 195 Figure 13-24: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3

Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM) ................................. 196 Figure 13-25: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM) ................................................. 197 Figure 13-26: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM................................................ 198 Figure 13-27: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate

Route- IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM................................................ 199 Figure 13-28: Average Network-Wide Utilization (Physical Resources)-7 Node – 3 Alternate

Route-IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM) .................................................... 200 Figure 15-1: Hierarchical Routing Architecture ................................................................... 204 Figure 15-2: IETF Control Plane Representation for Multi-Domain Network Architecture 205 Figure 15-3: ITU & SPA-Dedicated Control Plane Models Representation for Multi-Domain

Network Architecture.................................................................................................... 206 Figure 15-4: SPA-Shared Control Plane Representation of Multi-Domain Network

Architecture .................................................................................................................. 207 Figure 19-1: Average Network-Wide Blocking Probability (Dedicated Resources)-4 Node – 2

Alternate Route-STS-1 Sharing .................................................................................... 223

16

Figure 19-2: Average Network-Wide Blocking Probability (Dedicated Resources)-4 Node – 2

Alternate Route-STS-2 Sharing .................................................................................... 224 Figure 19-3: Average Network-Wide Blocking Probability (Dedicated Resources)-4 Node – 2


Alternate Route-STS-4 Sharing .................................................................................... 226 Figure 19-5: Average Network-Wide Blocking Probability (Shared Resources)-4 Node – 2




Alternate Route-STS-4 Sharing .................................................................................... 231 Figure 19-9: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2

Alternate Route-ITU (DR,SR), SPA-Dedicated ........................................................... 233 Figure 19-10: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2

Alternate Route- ITU (DR,SR), SPA-w/o(NE,IM)....................................................... 234 Figure 19-11: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2

Alternate Route-- ITU (DR,SR), SPA-w/NE,w/oIM.................................................... 235 Figure 19-12: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2

Alternate Route-- ITU (DR,SR), SPA-w/oNE,w/IM.................................................... 236 Figure 19-13: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2

Alternate Route-- ITU (DR,SR), SPA-w/(NE,IM) ....................................................... 237 Figure 19-14: Average Network-Wide Blocking Probability (Physical Resources)-4 Node-

IETF (DR, SR), ITU (DR, SR), SPA-Dedicated .......................................................... 239 Figure 19-15: Average Network-Wide Blocking Probability (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)........................................................... 240 Figure 19-16: Average Network-Wide Blocking Probability (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)....................................................... 241 Figure 19-17: Average Network-Wide Blocking Probability (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)....................................................... 242

17

Figure 19-18: Average Network-Wide Blocking Probability (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)............................................................. 243 Figure 19-19: Average Network-Wide Permissible Load (Dedicated Resources)-4 Node – 2

Alternate Route-STS-1 Sharing .................................................................................... 245 Figure 19-20: Average Network-Wide Permissible Load (Dedicated Resources)-4 Node – 2



Alternate Route-STS-4 Sharing .................................................................................... 248 Figure 19-23: Average Network-Wide Permissible Load (Shared Resources)-4 Node – 2




Alternate Route-STS-4 Sharing .................................................................................... 253 Figure 19-27: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2

Alternate Route-ITU(DR,SR),SPA-Dedicated ............................................................. 255 Figure 19-28: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2

Alternate Route-ITU(DR,SR),SPA-w/o(NE,IM).......................................................... 256 Figure 19-29: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2

Alternate Route-ITU(DR,SR),SPA-w/NE,w/oIM ........................................................ 257 Figure 19-30: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2

Alternate Route--ITU(DR,SR),SPA-w/oNE,w/IM....................................................... 258 Figure 19-31: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2

Alternate Route--ITU(DR,SR),SPA-w/(NE,IM) .......................................................... 259 Figure 19-32: Average Network-Wide Permissible Load (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-Dedicated .............................................................. 261 Figure 19-33: Average Network-Wide Permissible Load (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)........................................................... 262

18

Figure 19-34: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF

(DR, SR), ITU(DR,SR), SPA-(w/NE,w/oIM) .............................................................. 263 Figure 19-35: Average Network-Wide Permissible Load (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)....................................................... 264 Figure 19-36: Average Network-Wide Permissible Load (Physical Resources)-4 Node –

IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)............................................................. 265 Figure 19-37: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU,

SPA-Dedicated, SPA-w/o(NE,IM) ............................................................................... 267 Figure 19-38: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU,

SPA-Dedicated, SPA-w/NE,w/oIM.............................................................................. 268 Figure 19-39: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU,

SPA-Dedicated, SPA-w/oNE,w/IM.............................................................................. 269 Figure 19-40: Average Network-Wide Blocking Probability (Physical Resources)-4 Node-2

Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM) ................................... 270 Figure 20-1: Average Network-Wide Blocking Probability (Dedicated Resources)-7 Node – 2









Alternate Route-ITU(DR,SR), SPA-Dedicated ............................................................ 282

19

Figure 20-10: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)......................................................... 283 Figure 20-11: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM ....................................................... 284 Figure 20-12: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM ....................................................... 285 Figure 20-13: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)........................................................... 286 Figure 20-14: Average Network-Wide Permissible Load (Dedicated Resources)-7 Node – 2









Alternate Route-ITU(DR,SR), SPA-Dedicated ............................................................ 298 Figure 20-23: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)......................................................... 299 Figure 20-24: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM ....................................................... 300 Figure 20-25: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM ....................................................... 301

20

Figure 20-26: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2

Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)........................................................... 302 Figure 21-1: Average Network-Wide Blocking Probability (Dedicated Resources)-7 Node – 3









Alternate Route-ITU(DR,SR), SPA-Dedicated ............................................................ 314 Figure 21-10: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)......................................................... 315 Figure 21-11: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM ....................................................... 316 Figure 21-12: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM ....................................................... 317 Figure 21-13: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)........................................................... 318 Figure 21-14: Average Network-Wide Permissible Load (Dedicated Resources)-7 Node – 3


Alternate Route-STS-2 Sharing .................................................................................... 321

21

Figure 21-16: Average Network-Wide Permissible Load (Dedicated Resources)-7 Node – 3







Alternate Route-ITU(DR,SR), SPA-Dedicated ............................................................ 330 Figure 21-23: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)......................................................... 331 Figure 21-24: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM ....................................................... 332 Figure 21-25: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3

Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM ....................................................... 333 Figure 21-26: Average Network-Wide Blocking Permissible Load (VPN Resources)-7 Node

– 3 Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)..................................................... 334

22

LIST OF TABLES Table 3-1: Configured VPN Service Models.......................................................................... 37 Table 4-1: Control Plane Models and Associated Traffic Management Schemes.................. 51 Table 9-1: Control Planes Components Configuration Options ........................................... 120 Table 9-2: Performance Metrics for the Three Control Plane Models.................................. 121 Table 10-1: Traffic Management Schemes Impact on Control Plane Messages .................. 131 Table 11-1: Routes of the 7-Node Topology ........................................................................ 142 Table 11-2: Traffic Management Schemes Rank in Blocking Probability Reduction (IETF-

DR as Reference Model)............................................................................................... 150 Table 11-3: Traffic Management Schemes Rank in Permissible Load Increase (IETF-DR as

Reference Model).......................................................................................................... 151 Table 11-4: Traffic Management Schemes Rank in Utilization Reduction (IETF-DR as

Reference Model).......................................................................................................... 151 Table 12-1: Blocking Probability Reduction (IETF-DR as Reference Model)- 7-node

topology ........................................................................................................................ 153 Table 12-2: Permissible Load Increase (IETF-DR as Reference Model) - 7-node topology 154 Table 12-3: Utilization Reduction (IETF-DR as Reference Model) - 7-node topology ....... 155

23

1 Introduction

1.1 Problem statement

The architectures and functional operation of the control plane components for existing IETF

and ITU control plane models do not consider the service profile layer parameters. In

addition, the IETF control plane components do not consider a full realization of the network

resources multi-granularity representation. This component-level separation between the

service profile layer, control plane layer, and network infrastructure layer leads to a lack of

harmony between service demands’ detailed parameters and network infrastructure detailed

resources representation. This lack of harmony would lead to inefficient utilization of

network resources especially under operation scenarios requiring dynamic allocation of

network resources for differentiated services. Achieving this harmony will lead to a higher

optimization of network resources supporting differentiated services under dynamic network

operations.

Through the use of service profile layer parameters and network infrastructure multi-

granularity resources representation, the architectures and functional operation of the SPA

control plane components provide significant harmony between the network infrastructure

resources and service profile parameters. The SPA control plane components were

architected to utilize both the service profile layer parameters (service flow connectivity, load

partitioning flexibility, and service demand granularity), and network infrastructure detailed

resource representation parameter in its allocation of network resources supporting

differentiated services requests. Therefore, the problem is to develop a new control plane

model that provides this harmony and then demonstrate its superiority over existing control

plane models.

1.2 Problem motivation/significance

There are multiple aspects that differentiate this work from previous control plane research

efforts. First, this research proposes a new SPA control plane model with a detailed

description of its architectural and functional operation and then analytically shows its

superiority over existing IETF and ITU control plane models. Second, the current control

24

plane models are service architectures agnostic. This is the first time that services were

characterized by multiple architectures based on service profile features set including service

flow connectivity, load partitioning flexibility, and service demand granularity. Third, this is

the first time that the performance of both the IETF and the ITU control plane models were

analyzed while considering the proposed SPA control plane model in a common framework.

The comparison between the three control plane models was carried from three perspectives

including transport network granularity realization, operational level, and component-level

interaction between the transport layer, control plane layer, and the service profile layer.

1.3 Research approach

Detailed architectural and operational comparison of the IETF, ITU, and the proposed SPA

control plane models was performed (see sections 4- 6). Performance analysis of the three

control plane models was carried using Fixed Point Approximation analytical models. The

advantages of the SPA control plane over IETF/ITU models were analyzed using service

request blocking probability, permissible “non-blocked” load, and transport resources

utilization performance metrics. Detailed description of the performance metrics and their

relevant mathematical formulations for each control plane model is provided in section 9.3.

The analysis was divided into four phases, the first phase focused on defining the

architectures of the multiple configured VPN service proposed models, the second phase

focused on defining the architectures and functional operation of the control plane

components for the three control plane models, the third phase focused on defining the

mathematical models for the three control plane models traffic management schemes, the

fourth phase used Fixed Point Approximation (FPA) analytical model to compute the

performance metrics for the traffic management schemes of the three control plane models.

1.4 Research hypotheses

The hypotheses of this research were:

1. Since the SPA control plane model has a full knowledge of both the services

architectures/profile features set and the transport network granularity levels, the SPA

would provide a better match between service architectures/profile features set and the

transport network granularity levels; this will lead to a lower blocking, a higher

25

permissible “non-blocked” load, and a lower transport network utilization compared to

both the IETF and the ITU control plane models. It is expected that the benefit of the

SPA control plane will be highly dependent on the profile of the service request features

set (service flow connectivity, load partitioning flexibility, and service demand

granularity).

2. Since the routing component in the IETF control plane model has a coarse representation

of a multi-granularity transport network, whereas the ITU/SPA routing has a granular

representation of transport granularity levels, the following hypotheses are also

considered:

The IETF control plane model produces higher transport utilization and a higher

blocking probability than the ITU/SPA control plane models. This is also dependent

on the service request features set profile (service flow connectivity, load partitioning

flexibility, and service demand granularity).

IETF path computation element has less path options to compute. In ITU/SPA, since

routing component accurately represents transport granularity levels, path

computation has more path options to compute than IETF path computation element.

Thus, using IETF control plane model would lead to higher transport utilization and

higher blocking than using the ITU or SPA control plane models. This is also

dependent on profile of service features set (service flow connectivity, load

partitioning flexibility, and service demand granularity).

1.5 Research objectives

The main objective of this research is to prove that the SPA control plane model provides

lower blocking probability, higher permissible “non-blocked” load, and lower transport

network utilization compared to both the IETF and ITU control plane models. Thus, the

proposed SPA control plane model provides a new architecture for control plane

deployments. To achieve this objective, the following tasks were carried:

1. Develop detailed architectures for the service configuration models from the following

three perspectives:

a. Service flow connectivity

b. Load partitioning flexibility

c. Service demand granularity

26

2. Develop architectures for the three control plane models (IETF, ITU, SPA) from the

following three perspectives:

a. Transport network granularity realization

b. Component-level

c. Operational-level

3. Develop detailed mathematical models for the service configuration models to compute

the applied input load on each of the topology links based on the service flow

connectivity.

4. Modifying Fixed Point Approximation (FPA) to develop detailed mathematical models

for the three control plane models to compute the following performance metrics1:

a. Service blocking probability for both network-wide and per source-destination

pair

b. Permissible “non-blocked” load for both network-wide and per source-

destination pair

c. Occupancy probability “Utilization” for both network-wide and per source-

destination pair

5. Demonstrate the superiority of the SPA control plane model using the results of the

performance analysis.

1.6 Overview

The Dissertation is organized as follows: section 2 provides an overview of related previous

research and standardization activities. Section 3 provides a detailed architectural analysis of

the configured VPN service models applied to the three control plane models. Section 4

provides a detailed architectural analysis of the three control plane models from traffic

management schemes perspective. Section 5 provides a control plane technology overview

and a detailed architectural analysis of the three control plane models from transport network

realization perspective. Section 6 provides the component-level interaction between service

profile layer, control plane layer, and network infrastructure layer for the three control plane

models. Section 7 covers he analysis methodology. Section 8 provides detailed mathematical

1 Detailed description of the performance metrics and their relevant mathematical formulations for

each control plane model is provided in section 9.3.

27

analysis for the three control plane models. Section 9 covers analysis framework and

performance evaluation metrics. Section 10 covers the computational cost of the traffic

management schemes of each control plane model. Section 11 covers the mathematical

models validation and computation accuracy. Section 12 provides a summary of results

analysis for a seven-node topology. Section 13 provides a detailed analysis of SPA control

plane components impact. Section 14 provides conclusions. Section 15 provides

recommendations for future work. Section 16 provides references. Appendix-A provides list

of acronyms. Appendix-B provides pseudo-code generic algorithms for the FPA of the IETF,

ITU, and SPA control plane models. Appendix-C provides detailed results for the four-node

topology. Appendix-D provides detailed results for the seven-node topology with two

alternate routing. Appendix-E provides detailed results for the seven-node topology with

three alternate routing.

2 Background- Previous Research and Standardization Efforts

Telecommunications networks are usually segmented in a three-tier hierarchy: access,

metropolitan, and long haul. Long-haul/backbone networks span global distance and provide

large tributary connectivity between regional and metro domains. On the other end of the

hierarchy are access networks, providing connectivity to a plethora of customers within close

proximity. Straddled in the middle are metropolitan (metro) networks interconnecting access

and long-haul networks. Transport networks today are based on SONET digital hierarchy ring

architectures. Namely, smaller tributary rings, for example, OC-3 (155 Mb/s) or OC-12 (622

Mb/s), aggregate traffic onto larger core rings at higher bit rates, for example OC-48 (2.5

Gb/s). Overall, SONET has been very successful in delivering the fast wave of end-user

connectivity, namely voice.

Various emerging trends have greatly affected legacy SONET systems suitability for future

applications. The first trend is the growth in Internet applications, residential Internet has

produced sustained data traffic growth, with close to half of the households in North America

now having Internet connectivity [74]. Meanwhile, penetration rates are also growing

significantly in Europe and Asia [75]. One the corporate side, many businesses are heavily

utilizing existing Internet applications and busy developing new possibilities. For example,

28

Internet teleconferencing is commonplace and web hosting/mirroring and e-commerce are

growing rapidly. Other, more distance possibilities such as telemedicine and remote sensing

are also being studied. Apart from application/bandwidth growth, the number of simultaneous

peered sessions is also increasing rapidly, further accelerating volumes [76]. Also, many

studies indicate that Internet traffic exhibits highly bursty, asymmetric behaviors [77] and

overall customer demands can be more difficult to predict as compared to legacy voice

[78,76].

The second aspect is the growth in virtual Line/LAN services with varying bit-rate

requirements. These offerings are particularly attractive for enterprise clients wanting to build

Layer 1 VPNs (L1-VPNs) [26] to interconnect multiple locations via a full variety of data

interfaces/protocols (e.g., Gigabit Ethernet, SONET, frame relay, ATM, etc.).The lower-cost

native Ethernet interfaces is a key factor in the emerging metro market [7] (i.e., over 80% of

enterprise traffic originates in Ethernet form [6]. Overall, “LAN-like” service may become

subsets of more generalized virtual private networks (Layer-1 VPN) services [8,9]. Unlike

legacy leased-line services, virtual-line services will provide genuine transparency, enabling

customers to manage their own networks [6,8,10,11].

Pure capacity expansion will hardly suffice, as operators need intelligent “network level”

provisioning capabilities to support a full range of client protocols and applications.

Specifically, network infrastructures must efficiently allocate capacity resources and at the

same time provide very selective handling in order to enable competitive Service Level

Agreement (SLA) differentiation. Service differentiation can be achieved in many facets,

such as turn-up speed, channel quality, priority, protection levels/speed, etc [12]. Overall, it

has been argued that transparency and rapid, intelligent service creation capabilities are even

more important than raw capacity and equipment consolidation [8,13]. Additionally, given

the plethora of competing vendors, standards-based interoperable network control and

management will become more important as operators gradually induct differing gears.

In light of the above legacy SONET systems shortcomings, vendors and service providers

have sought to “enhance” SONET paradigms to better suit data traffic needs [6-14]. Although

these proposals have appeared under different names, e.g., “data-aware SONET” [17], herein

29

the term Next-Generation SONET (NGS) was selected. Overall, all these solutions share two

main features, namely efficient data tributary mapping and integrated higher layer (two/three)

protocol functionalities. SONET mapping of smaller packet interfaces (10,100 Mb/s

Ethernet) is usually done in “coarse” STS-1 increments and the resultant bit-rate in-

congruencies usually yield large amounts of stranded bandwidth [14] (e.g., 10 Mb/s Ethernet

allocated at full STS-1, 80% unused capacity).

NGS set of recommendations includes the development of ITU-T Link Capacity Adjustment

Scheme (LCAS) [20] recommendation, approved in 2001 which defines a transport network

capability that allows for “hitlessly” increasing/decreasing the number of “trails” (e.g., STS-1

circuits) assigned to a connection. Moreover, each circuit trail can be diversely router to

improve resiliency and failed trails can be removed together. Overall, LCAS defines a very

powerful new capability for exploiting virtual concatenation techniques and improving

capacity utilization. ITU-T G.707 [21] recommendation, approved in 2001, defines the virtual

concatenation mechanism. Virtual concatenation is a mechanism that provides flexible and

effective use of SONET/SDH payload. Virtual concatenation breaks the limitation incurred

by the legacy SONET hierarchy rigidity via the definition of pay-loads with flexible

bandwidth. It “virtually” concatenates several payloads to provide a payload with flexible

bandwidth, appropriate for data service accommodation.

Both the IETF and ITU standardization organizations had completely two opposite

approaches in standardizing optical control plane architectures and its supporting protocols.

The IETF approach was focused on extending MPLS-based protocols that were designed for

data networks to support the transport networks without taking into considerations the NGS

architectures. On the other hand, the ITU approach was focused initially on building generic

control plane architectures that are based on NSG architectures and then proposed protocol-

specific implementations of the generic control plane architectures using both GMPLS and

PNNI; this indicates that the IETF control plane model architectures were not optimized to

utilize NGS capabilities. ITU-T started the development of control plane architectures by

focusing on developing a set of NGS recommendations first and then developed generic

control plane architectures that were optimized to utilize NGS capabilities.

30

ITU-T G.8080 [15] recommendation, approved in 2001, defines the architecture for the

Automatic Switched Optical Network (ASON) that was developed within the context of NGS

capabilities. This recommendation provides canonical architecture for Call and Connection

operations and lays foundation for more detailed ITU-T control plane recommendations.

ITU-T G.7713 [17] recommendation, approved in 2001, addresses intra- and inter-control

domain signaling. This recommendation provides protocol neutral specifications support for

User Network Interface (UNI), Interior-Network-Network Interface (I-NNI), and Exterior-

Network-Network-Interface (E-NNI). Also, this recommendation functionally specifies

control plane architecture per transport network granularity level basis, allowing for

implementation of single control plane for multiple transport network granularity levels.

ITU-T G.7715 [19] recommendation, approved in 2002, provides the architecture and

requirements for routing in ASON, it covers aspects of ASON routing architectures, ASON

routing requirements, routing attributes, routing messages, routing message distribution

topology, and path selection. ITU-T G.7715.1 [24] recommendation, approved in 2003,

provides the generic ASON routing architecture and requirements for Link State protocols.

This recommendation provides architecture and requirements for a link state realization of

ITU-T G.7715 and ITU-T G.8080. In addition, this recommendation provides details on

routing information flow and communications between routing hierarchical levels. ITU-T

G.7714 [18] recommendation, approved in 2001, covers ASON generalized automatic

discovery techniques including aspects of neighbor/adjacency and service discoveries (i.e.,

transport network granularity level adjacencies discovery and service capability exchange).

IETF Generalized Multi-Protocol Label Switching (GMPLS) architecture [34] provides the

generic architecture of the optical control plane from an IETF perspective. GMPLS

architecture represents a strong push to increase vertical control plane integration (data and

optical) by extending/reusing existing data networking concepts/protocols. The overall aim is

to replace the features of multiple protocol layers in traditional multilayered models (e.g.,

separate addressing schemes, SONET/SDH protection, ATM traffic engineering) with a more

unified solution. There are several major required components for dynamic channel

provisioning and advanced SLA management optical networks, namely setup signaling,

resource discovery, and constraint-based routing. GMPLS implements all of these

31

requirements by extending MPLS signaling [35] and resource discovery protocols [38] and

defining multiple link-specific abstractions of the original MPLS label-swapping paradigm

(i.e., “implicit labels” for time-slots, wavelengths, and fibers). These definitions can be

further coupled with hierarchical label-stacking schemes to exploit scalability (e.g., packet

labels into TDM circuit labels into lambda labels). In particular, this ubiquity makes GMPLS

an ideal control framework for multi-service network platform. First, optical channel setup

signaling is accomplished by extensions to MPLS signaling protocols, namely RSVP-TE

(RSVP Traffic Engineering) [37] and CR-LDP (Constraint-Routing Label Distribution

Protocols) [36]. Here, the Explicit-Routing (ER) capability is used to indicate the channel

route and reserve resources. Meanwhile, actual route computation is done via constrained

routing/path computation. Finally, route computation requires network topological/resource

information, and is propagated via extensions to pertinent routing protocols, namely open-

shortest path first (OSPF) [39].

Multiple research efforts focused on the analysis of GMPLS control plane routing and

signaling performance in a single domain environment, some of the research efforts are

provided in [1-5]. The analysis of GMPLS routing and signaling performance concluded with

multiple disadvantages of the GMPLS control plane solution, this can be attributed to the lack

of consideration of NGS during the development of GMPLS protocols. GMPLS performance

issues led to the need to establish formal communications and liaison with ITU-T to help in

modifying GMPLS protocols to support NGS capabilities. Since 2003, both the IETF and

ITU-T standardization organizations established formal communications and liaisons

between the two organizations to collaborate in defining GMPLS protocols extensions to

support ASON generic architectures and NGS capabilities.

This collaboration led to the development of multiple ITU-T recommendations providing

protocol specific implementation of ASON signaling and routing protocols as specified in

both ITU-T G.7713.2 [22] recommendation that defines ASON distributed call and

connection management signaling mechanism using GMPLS RSVP-TE and ITU-T G.7713.3

[23] recommendation that defines ASON distributed call and connection management

signaling mechanism using GMPLS CR-LDP. In addition to the signaling extensions, a

routing core team was established between IETF and ITU experts to build the requirements

32

[43] for GMPLS routing for ASON based on ITU-T G.7715.1. Figure 2-1 provides the

current mapping between ITU-T control plane generic architectures and IETF control plane

specific protocols.

Figure 2-1: Mapping ITU-T Generic Control Plane Architectures Recommendations to IETF

Control Plane Protocols

Despite the IETF and ITU-T standardization organizations collaboration, the architectures

and functional operation of the control plane components for existing IETF and ITU control

plane models lack the service profile layer parameters consideration. This component-level

separation between the service profile layer, control plane layer, and network infrastructure

layer led to the lack of harmony between service demands’ detailed parameters and network

infrastructure detailed resources representation. This lack of harmony would lead to

inefficient utilization of network resources especially under operation scenarios requiring

dynamic allocation of network resources for differentiated services.

The provided survey gave guidance in identifying the drawbacks of both IETF and ITU

control plane architectures which was the starting point in developing the proposed SPA

control plane model. Through the accurate realization of both service profile layer parameters

and network infrastructure multi-granularity detailed resources representation, the

architectures and functional operation of the proposed SPA control plane components provide

Automatically Switched Transport Network (G.ASTN) G.8070Automatically Switched Optical Network (ASON) (G.8080) Optical Transport Network Architecture (G.872)

Transport Restoration CACSignaling Routing Discovery Link management

Link Management

GMPLS Routing Functional OSPF-TE and IS-IS SDH/SONET and G.709

GMPLS Signaling Functional RSVP-TE and CR-LDP SDH/SONET and G.709

G.7713 G.7715 G.7714 G.7716 G.CAC G.resG.gps

G.709/G.798G.DCN

ITU-T Generic Architectures

IETF ProtocolsGMPLS Architecture

Management AspectsOf Optical Networks

G.874

33

significant harmony between the network infrastructure resources and service profile

parameters. This research is focused on studying the impact of the architectural and

functional operation of the IETF, ITU, and SPA control plane models components on the

performance of a range of proposed configured VPN service models while considering a

multi-granularity transport network infrastructure.

3 Configured VPN Service Models- Service Profile Parameters

The SPA control plane model uses the service profile layer parameters as input to its traffic

management schemes; this section defines the parameters of the service profile layer and the

different service models architectures that can be defined based on the service profile layer

parameters. Nine service models architectures are defined in this section, the service models

are considered configured VPN service models because the service arrivals belong to

different customers that use common physical network resources, the set of service arrivals

belonging to the same customer must be able access a certain partition of the physical

network resources, a VPN, without competing with service arrivals from other customers.

Each customer’s VPN is constructed by reserving resources from the physical network links

to connect the customer’s end nodes; the reserved resources on any link for a certain

customer are reserved solely for the service arrivals of that customer. The physical network

resources are partitioned into multiple partitions with one partition for each configured

customer; this means that the physical network topology is partitioned logically into multiple

VPNs for the configured customers. This section defines the detailed architectures for the

VPN service configuration models from the perspective of the following service profile

parameters that are used by the SPA control plane model components:

1. Service flow connectivity: is a service profile layer parameter that defines the level of

service requests meshing between source-destination pairs. This parameter can be

configured as “fully-meshed”, “semi-meshed”, or “point-to-point”.

2. Load partitioning flexibility: is a service profile layer parameter that defines if the load of

the configured VPN service request can be partitioned between a dedicated network

resources partition and a shared network resources partition. This parameter can be

configured as “enabled” or “disabled”. The “enabled” configuration means that the

34

service request load can be partitioned. The “disabled” configuration means that the

service request load can not be partitioned.

3. Service demand granularity: is a service profile layer parameter that defines if the actual

bandwidth requirement Akb , e.g., 2 STS-1, of a service request flow can be split into

multiple flows each with a granular bandwidth requirement Gkb , e.g., STS-1,. This

parameter can be configured as “actual” or “granular”. The “actual” configuration means

that the actual service request flow can not be split into multiple service request flows.

The “granular” configuration means that the actual service request flow can be split into

multiple service request flows. The relationship between actual and granular bandwidth

requirements flows is illustrated in Figure 3-1.

4. Configured VPN service identification number: is a service profile layer parameter that

identifies the VPN service that the service request belongs to.

Each service request will be characterized by the following parameters (service demand

granularity, load partitioning flexibility, service flow connectivity, and configured VPN

service identification number). The reason for considering the service request a "VPN" is that

it SHOULD only use the allowed resources partition allocated to it based on the "configured

VPN service identification number" parameter in the service profile layer.

For a given physical link, each of its dedicated resources partitions is labelled with a

"configured VPN service identification number" that allows the service arrivals belonging to

a VPN with the same "configured VPN service identification number" to access the dedicated

resources partition. The shared sources partition is labelled with multiple "configured VPN

service identification numbers" indicating that the shared resources partition can be accessed

by any service arrivals with "configured VPN service identification number" that map to one

of the multiple "configured VPN service identification numbers" included in the shared

resources partition.

The IETF model does not consider the "configured VPN service identification number"

parameter as it multiplexes all the service requests from multiple customers on the same

physical resources. The ITU model uses the "configured VPN service identification number"

parameter by applying the set of service arrivals belonging to a specific customer to the

35

corresponding dedicated resources partition. The Service-Oriented-Shared model uses the

"configured VPN service identification number" parameter to split the load between the

dedicated and shared network resources partitions.

3.1 Definitions and notation2

1. jC : The physical capacity or bandwidth of link j, in units of bandwidth, circuits, or

trunks. Sj

vD

vDjj CCC += ∑ )(

2. Dedicated Resource Partition vDjC : The dedicated capacity on link j for configured VPN

service v. The dedicated arrival rate vDrkλ from the configured VPN service’s VPN arrival

rate vrkλ is applied to vD

jC resources without allowing an arrival rate from other configured

VPN services to use vDjC resources.

3. Shared Resources Partition SjC : The shared capacity on link j. The shared arrival

rate vSrkλ from multiple configured VPN services is applied to S

jC

4. VPN Resources vjC : The VPN capacity on link j used by configured VPN service v.

Sj

vDj

vj CCC +=

5. vrkλ : The arrival rate of class k calls between node pair r for configured VPN service v.

The configured VPN service arrival rate vrkλ can be partitioned into two rates; a dedicated

rate vDrkλ that can be applied to a dedicated resources partition vD

jC , and shared rate vSrkλ

that can be applied to a shared resources partition SjC . vS

rkvDrk

vrk λλλ +=

6. vDrkλ : The dedicated arrival rate. The portion of v

rkλ which is applied to the dedicated

resources partition vDjC of the link capacity jC . The dedicated rate applied to the

dedicated resources partition does not share its resources with any arrival rates from other

configured VPN services.

2 The listed notation will be in used in section 6.1 to derive the mathematical models for the service models.

36

7. vSrkλ : The shared arrival rate. The portion of v

rkλ which is applied to the shared resources

partition SjC of the link capacity jC . The service’s shared rate applied to the shared

resources partition share its resources with other configured VPN services’ shared rates.

8. Ckb : The coarse bandwidth requirement of class k service request, in units of bandwidth,

circuits, or trunks. Ckb represents the transport network maximum level of multiplexing.

9. Gkb : The granular, sub-rate, bandwidth requirement of C

kb , in units of bandwidth, circuits,

or trunks. Gkb represents the transport network minimum level of inverse multiplexing.

10. Akb : The actual bandwidth requirement of class k, in units of bandwidth, circuits, or

trunks. Figure 3-1 illustrates the relationship between Akb , C

kb , and Gkb . For example, a

class k with actual bandwidth requirement Akb of 2 STS-1, has a coarse bandwidth

requirement Ckb of 3 STS-1 and a granular bandwidth requirement G

kb of 1 STS-1.

11. Point-to-Point Flow: The service request takes place over a network between a single

sender and a single receiver.

12. Semi-Meshed Flow: The service request takes place between a source and a select group

of destinations.

13. Fully-Meshed Flow: The service request takes place between a source and all the

reachable destinations by the source node.

Figure 3-1: Coarse, Actual, Granular Bandwidth Relationship

Akb

Ckb

Gkb

Coarse Bandwidth

Actual Bandwidth

Akb

Gkb

Gkb

Akb

GranularBandwidth

Akb

Ckb

Gkb

Coarse Bandwidth

Actual Bandwidth

Akb

Gkb

Gkb

Akb

GranularBandwidth

37

3.2 Configured VPN service models

Figure 3-2 provides a graphical view of the different configured VPN service models based

on the listed service profile features set as provided in section 3.1. Based on the three

service’s profile features (service flow connectivity, load partitioning, service demand

granularity), multiple service configurations are introduced in Table 3-1. The following sub-

sections will provide a detailed architectural view of each of the listed configured VPN

service models as provided in Table 3-1.

Configured VPN

Services Models

Service Flow

Connectivity

Load

Partitioning

Flexibility

Service

Demand

Granularity

Point Dedicated Actual(PDA) Point-to-Point Disabled Actual

Point Shared Actual (PSA) Point-to-Point Enabled Actual

Point Shared Granular (PSG) Point-to-Point Enabled Granular

Semi-meshed Dedicated Actual (SDA) Semi-meshed Disabled Actual

Semi-mesh Shared Actual (SSA) Semi-meshed Enabled Actual

Semi-meshed Shared Granular (SSG) Semi-meshed Enabled Granular

Fully-meshed Dedicated Actual (FDA) Fully-meshed Disabled Actual

Fully-mesh Shared Actual (FSA) Fully-meshed Enabled Actual

Fully-meshed Shared Granular (FSG) Fully-meshed Enabled Granular

Table 3-1: Configured VPN Service Models

38

Figure 3-2: Configured VPN Service Models

Configured VPN Service Models

Point-to-Point

Semi-Meshed

Fully-Meshed

Load Partitioning Disabled

Load Partitioning Enabled

Granular Bandwidth Request

Coarse Bandwidth Request












39

3.2.1 Point Dedicated Actual (PDA)

Figure 3-3 illustrates the Point Dedicated Actual (PDA) configured VPN service model; the

point-to-point nature of the service flow connectivity feature indicates that the configured

VPN service arrival rate vrkλ generated from a source node is destined to only one destination

node. The dedicated nature of load partitioning nature indicates that the VPN service arrival

rate vrkλ is applied to the total physical capacity jC for all the links part of the source-

destination pair r. The actual nature of the service demand granularity level indicates that the

actual service demand Akb between a source-destination pair can not be split into sub rates G

kb .

Figure 3-3: PDA Service Configuration

3.2.2 Point Shared Actual (PSA) and Point Shared Granular (PSG)

Figure 3-4 illustrates the Point Shared Actual (PSA) and the Point Shared Granular (PSG)

configured VPN service models; the point-to-point nature of the service flow connectivity

feature indicates that the configured VPN service arrival rate vrkλ generated from a source

node is destined to only one destination node. The shared nature of load indicates that the

VPN service arrival rate vrkλ can be split into vD

rkλ and vSrkλ across vD

jC and SjC resources partitions

respectively. The actual nature of the service demand granularity level indicates that a service

request flow with actual bandwidth requirement Akb between a source-destination pair can not

be split into multiple service request flows each with granular bandwidth requirement Gkb . In

PSG, a service request flow with actual bandwidth requirement Akb between a source-

Physical ResourcesjC

vrkλ

Configured VPN Service

Akb


Destination Source

40

destination pair can be split into multiple flows each with granular bandwidth

requirement Gkb .

Figure 3-4: PSA and PSG Service Configurations

3.2.3 Semi-meshed Dedicated Actual (SDA)

Figure 3-5 illustrates the Semi-meshed Dedicated Actual (SDA) configured VPN service

model; the Semi-meshed nature of the service flow connectivity feature indicates that the

configured VPN service arrival rate vrkλ generated from a source node is destined to selected

destination nodes. The dedicated nature of load indicates that the VPN service arrival

rate vrkλ is applied to the total physical capacity jC for all the links part of the source-

destination pair r. The actual nature of the service demand granularity level indicates that the

service request flow with actual bandwidth requirement Akb between a source-destination pair

SjC

Dedicated Resources Partition-1

vD

jC

vDrkλ

vD

jC

vSrkλ

2=vrkλ

1=vrkλ

vSrkλ

Akb

Akb

Akb

Akb

vDrkλ

Gkb

Gkb

Gkb

Gkb

Gkb

Configured VPN Service-1




Destination

Destination Source

Source

Shared Resources Partition


Gkb

41

can not be split into multiple service request flows each with granular bandwidth

requirement Gkb .

Figure 3-5: SDA Service Configuration

3.2.4 Semi-meshed Shared Actual (SSA) and Semi-meshed Shared Granular (SSG)

Figure 3-6 illustrates the Semi-meshed Shared Actual (SSA) and the Semi-meshed Shared

Granular (SSG) configured VPN service models, the semi-meshed nature of the service flow

connectivity feature indicates that the configured VPN service arrival rate vrkλ generated from

a source node is destined to multiple selected destination nodes. The shared nature of load

partitioning nature indicates that the VPN service arrival rate vrkλ can be split into vD

rkλ and vSrkλ

across vDjC and S

jC resources partitions respectively. The actual nature of the service demand

granularity level indicates that a service request flow with actual bandwidth requirement Akb

between a source-destination pair can not be split into multiple service request flows each

with granular bandwidth requirement Gkb . In SSG, a service request flow with actual

Configured VPN

Service

Configured VPN

Service

Configured VPN

Service

Source

Destination

Destination

Akb

Akb

1=vrkλ

1=vrkλ

jC

42

bandwidth requirement Akb between a source-destination pair can be split into multiple flows

each with granular bandwidth requirement Gkb .

Figure 3-6: SSA and SSG Service Configurations


vDrkλ

vD

jC

vSrkλ

2=vrkλ

Configured VPN

Service-1

1=vrkλ

Akb

Akb

Akb

Akb

vDrkλ

vD

jC

vSrkλ

SjC

Gkb

Gkb

Gkb

Gkb

Gkb

Gkb



Configured VPN

Service-2

Configured VPN

Service-2

Configured VPN

Service-2

Configured VPN

Service-1

Configured VPN

Service-1

Destinations

Destinations

Destinations

Configured VPN

Service-2

Configured VPN

Service-1

Source

Source

Gkb

43

Figure 3-7: FDA Service Configuration

3.2.5 Fully-meshed Dedicated Actual (FDA)

Figure 3-7 illustrates the Fully-meshed Dedicated Actual (FDA) configured VPN service

model, the fully-meshed nature of the service flow connectivity feature indicates that the

configured VPN service arrival rate vrkλ generated from a source node is destined to all

reachable destination nodes. The dedicated nature of load partitioning nature indicates that

the VPN service arrival rate vrkλ is applied to the total physical capacity jC for all the links

part of the source-destination pair r. The actual nature of the service demand granularity level

indicates that the service request flow with actual bandwidth requirement Akb between a

source-destination pair can not be split into multiple service request flows each with granular

bandwidth requirement Gkb .

vrkλ A

kb

Akb 1=v

rkλ

Akb

1=vrkλ


Network Resources

jC

jC

jCConfigured VPN Service



Source

Destination

Destination

Destination

44

3.2.6 Fully-meshed Shared Actual (FSA) and Fully-meshed Shared Granular (FSG)

Figure 3-8 illustrates the Fully-meshed Shared Actual (FSA) and the Fully-meshed Shared

Granular (FSG) configured VPN service models; the fully-meshed nature of the service flow

connectivity feature indicates that the configured VPN service arrival rate vrkλ generated from

a source node is destined to all reachable destination nodes. The shared nature of load

partitioning nature indicates that the VPN service arrival rate vrkλ can be split into vD

rkλ and vSrkλ

across vDjC and S

jC resources partitions respectively. The actual nature of the service demand

granularity level indicates that a service request flow with actual bandwidth requirement Akb

between a source-destination pair can not be split into multiple service request flows each

with granular bandwidth requirement Gkb . In FSG, a service request flow with actual

bandwidth requirement Akb between a source-destination pair can be split into multiple flows

each with granular bandwidth requirement Gkb .

The FSG VPN service configuration model is the service model analyzed in this research for

the following reasons:

1. The fully-mesh service flow connectivity would indicate a higher network-wide input

load compared to the semi-meshed and point-to-point service flow connectivity; this

would allow the performance of the three control plane models to be evaluated under

realistic high input loads.

2. The Shared load partitioning would allow the Load Partitioning Function of the SPA

control plane to be evaluated

3. The Granular service demand would allow the Inverse Multiplexing Function of the SPA

control plane model to be evaluated.

45

Figure 3-8: FSA and FSG Service Configurations


vDrkλ

vD

jC

vSrkλ

2=vrkλ

Configured VPN

Service-1 1=v

rkλ

Akb

Akb

Akb

Akb

vDrkλ

vD

jC

vSrkλ

SjC

Gkb

Gkb

Gkb

Gkb

Gkb

Gkb



Configured VPN

Service-2

Configured VPN

Service-2

Configured VPN

Service-2

Configured VPN

Service-1

Configured VPN

Service-1

Destinations

Destinations

Destinations

Configured VPN

Service-2

Configured VPN

Service-1

46

4 Control Plane Models- Traffic Management Schemes

This section describes the traffic management schemes of IETF, ITU, and SPA control plane

models from the following control plane traffic management capabilities (details in section

4.2):

1. Routing update triggers

2. Network routing granularity

3. Load Partitioning Function (LPF)

4. Inverse Multiplexing Function (IMF)

4.1 Control plane components overview

This section provides a summary of the control plane components and operation. The control

plane enables the automation of transport network connections setup and teardown; this will

facilitate end-to-end connection setup. The purpose of the control plane is to:

1. Facilitate the fast and efficient configuration of transport layer connections.

2. Re-configure and modify connections that support existing configured services.

3. Perform a rapid restoration function. The control plane can automatically restore failed

connections to backup connections and prevent any violation of customers’ service level

agreement.

4. Reduce operational costs via more accurate inventory and topology information, resource

optimization through self-aware network, automated processes that eliminate manual

steps.

The control plane performs those operations that can be automated. These include automatic

connection setup “signaling”, resource/topology auto-discovery, routing, and the connection

admission control (CAC) function. The control plane interfaces with the transport plane to

perform these tasks. The control plane takes service setup requests, these requests are put

through a policy server to ensure that the client is allowed to make the request (i.e., CAC,

check bandwidth, destination, etc.). Next, the control plane computes a path, signals the

destination, and enables cross-connects in the transport network to reach the destination

through multiple connections establishment across the multiple switching elements.

47

The control plane is the collection of control plane components that are used to manipulate

transport plane network resources in order to provide the functionality of setting up,

maintaining, and releasing connections. The control plane architecture is described in terms

of components that represent abstract entities. Generically, every component has a set of

interfaces to support a collection of operations that specify a provided or used service of that

component. Figure 4-1 shows the functional block diagram of the control plane according to

ITU-T recommendation G.8080 [15] mainly highlighting the functional flow among the

different components. Following are brief description of each component:

NetCallC: Network call “service request” controller component accepts (after verifying user

rights and resource policy) and processes incoming call requests from a client network,

processes and generates service termination requests towards a client network, and validates

service parameters.

Connection Control (CC): is responsible for the establishment, termination, and

modifications of connections’ parameters for existing network connections. Connection

control is responsible for coordinating among the link resource manager, routing controller,

and both peer and subordinate connection controllers. The overall control of a connection is

performed by the protocol undertaking the set-up and release procedures associated with a

connection and the maintenance of the state of the connection.

Connection Admission Control (CAC): Connection admission control is essentially a

process that determines if there are sufficient resources to admit a connection (or re-

negotiates resources during a service request). This is usually performed on a link-by-link

basis, based on local conditions and policy. For a simple circuit switched network this may

simply devolve to whether there are free resources available. In contrast, for packet

switched networks such as ATM, where there are multiple quality of service parameters,

connection admission control needs to ensure that admission of new connections is

compatible with existing quality of service agreements for existing connections. Connection

admission control may refuse the connection request.

Traffic policy (TP): provides the function of implementing the set of rules applied to a

system. It is responsible for checking that the incoming user connection is sending traffic

according to the parameters.

48

Link Resource Manager (LRM): provides information about the allocation and de-allocation

of link connections, providing topology and status information status.

Neighbor Discovery: provides the function of collecting information about the topology of

the neighboring nodes in addition to the connectivity and capability of the links connecting

the network element to other network elements.

Protocol Controller (PC): provides the function of mapping the parameters of the abstract

interfaces of the control components into messages that are carried by a protocol to support

interconnection via an interface. Protocol Controllers are a sub class of Policy Ports, and

provide all the functions associated with those components. In particular, they report

protocol violations to their monitoring ports. They may also perform the role of

multiplexing several abstract interfaces into a single protocol instance. The details of an

individual protocol controller are in the realm of protocol design.

Routing Controller (RC): responds to requests from connection controller for path

information needed to set up connections and respond to requests for topology information

for network management purposes. Three approaches to dynamic path control can be

identified: hierarchical, source routing, and step-by-step routing. Hierarchical routing is

based on decomposition of a layer network into a hierarchy of sub-networks, each having its

own dynamic connection control. A node contains a routing controller, connection

controller, and link resource managers for a single level in a sub-network hierarchy. In the

case of source routing, in which the route of the connection is determined at a source node, a

federation of distributed connection controllers and routing controllers’ implements the

connection control process. A step-by-step routing differs from the previous case in a

reduction of routing information that each routing controller provides information only

about the next step. In this case, the operator cannot know the route of the paths before

executing of the path setup command, but they can easily establish new paths due to

avoidance of complicated path configurations.

49

Figure 4-1: Control Plane Components

4.2 Traffic management capabilities definitions

This section provides detailed description of the different traffic management capabilities for

the IETF, ITU, and SPA control plane models. The traffic management capabilities include

the different traffic handling mechanisms that are implemented in the control plane

components including routing component, Load Partitioning Function (LPF), and Inverse

Multiplexing Function (IMF). Nine traffic management schemes are defined based on the

traffic management mechanism configured for each control plane component. The detailed

description of the nine traffic management schemes is provided in section 4.3. The following

describes the configuration details for each traffic management capability:

1. Static routing: a routing mechanism where routes’ routing probabilities for each source-

destination pair are not prioritized based on the traffic occupancy state of all the links for

each possible route between a source-destination pair. Instead, the routing options

between a source-destination pair are statically prioritized. Two versions exist of static

routing. The first version is Direct Routing (DR) where the direct link “minimum number

of hops” between a source-destination pair is given a routing probability of one. The

second version is Split Routing (SR) where the routing probability of each route between

a source-destination pair is configured manually with the total probability of all the routes

between a source-destination pair equals one.

2. State-dependent routing: a routing mechanism where the routing probabilities for each

source-destination pair are determined based on the traffic occupancy state of all the links

for each possible route between a source-destination pair.

CC

PC

RC

LRM

TPNet

CallC

Authentication

Encryption boundary

Config portPolicy portMonitor port

DiscoveryFunction

CC

PC

RC

LRM

TPNet

CallC

Authentication

Encryption boundary

Config portPolicy portMonitor port

DiscoveryFunction

50

3. Network routing granularity: The network granularity level ( Akb , C

kb , Gkb ) used to

construct the routing tables.

4. Load Partitioning Function (LPF): a control plane capability to partition the configured

VPN service arrival load vrkλ into two partitions; a dedicated load vD

rkλ applied to the

dedicated resources partition and a shared load vSrkλ applied to the shared resources

partition. The rate partitioning handling capability has two options; Static Partitioning

(SS) and Network Engineering.

a. Static Sharing (SS): a control plane capability that statically partitions the

configured VPN service arrival load into two partitions between the dedicated

and shared resources partitions. One load partition, dedicated load, based on the

capacity ratio of the dedicated resources partition to the VPN resources partition

(sum of dedicated and shared resources), and another load partition, shared load,

based on the capacity ratio of the shared resources to the VPN resources

partition.

b. Network Engineering (NE): a control plane capability that dynamically partition

the configured VPN service arrival load between the dedicated and shared

resources partitions based on the blocking probability of the dedicated resources

partition. Here a two-round process is used to find the load partition ratio. In

round-1, the configured VPN service total load is applied to the dedicated

resources partition and a blocking probability is generated. In round-2, the load is

applied again to the dedicated resources partition in proportion to the unblocked

load and to the shared resources partition in proportion to the blocked load.

5. Inverse Multiplexing Function (IMF): a control plane capability that allows for

multiplexing and inverse multiplexing of traffic bandwidth. IMF function is used at the

source and destination nodes of a service request when inverse multiplexing and

multiplexing of traffic bandwidth is required to increase network bandwidth efficiency.

a. Multiplexing: Multiplexing is sending multiple signals or streams of information

on a carrier at the same time in the form of a single, complex signal and then

recovering the separate signals at the receiving end.

b. Inverse Multiplexing (IM): Inverse multiplexing speeds up data transmission by

dividing a service request with actual bandwidth requirement Akb into multiple

51

concurrent granular streams or flows with bandwidth requirement Gkb that are

transmitted at the same time across separate channels and are then reconstructed

at the other end back into the original data stream.

4.3 Control plane models and associated traffic management capabilities

Based on the three control plane traffic management capabilities (Routing, LPF, IMF),

multiple control plane models are defined (see table 4-1 and Figure 4-2).

Control Plane

Model

Routing

Component

Load Partitioning

Function (LPF)

Inverse

Multiplexing

Function

(IMF)

IETF-DR Static- Direct Disabled Disabled

IETF-SR Static- Split Disabled Disabled

ITU-DR Static- Direct Disabled Disabled

ITU-SR Static- Split Disabled Disabled

SPA-Dedicated State-Dependent Disabled Disabled

SPA-Shared

W/O (NE,IM) State-Dependent Enabled (SS) Disabled

SPA- Shared

(W/ NE, W/O IM) State-Dependent Enabled (NE) Disabled

SPA- Shared (W/O NE, W/ IM)

State-Dependent Enabled (SS) Enabled

SPA- Shared

W/ (NE,IM) State-Dependent Enabled (NE) Enabled

Table 4-1: Control Plane Models and Associated Traffic Management Schemes

52

Figure 4-2 provides a graphical view of the different control plane models based on the above

listed control plane capabilities. As illustrated in Table 4-1, The SPA control plane model can

operate under five traffic management schemes. It is important to note that the SPA control

plane model adds three additional capabilities on top of the IETF and ITU control plane

models capabilities; the SPA routing component is state-dependent, the LPF is enabled with

two possible configuration options (SS,NE), and the IMF with two configuration options

(enabled, disabled). This research compares each of these control plane models in a common

framework. Each of the control plane models listed in Table 4-1 will be discussed in details in

sections 44.4, 4.5, and 4.6.

53

Figure 4-2: Control Plane Models Based on Traffic Management Schemes

Control Plane Model

Control Plane Model

IETFIETF ITUITU SPASPA

Dedicated VPN

Dedicated VPN

Shared VPN

Shared VPN

With Network Engineering (w/NE)


Without Network Engineering

(w/oNE)


(w/oNE)

Dedicated VPN

Dedicated VPN

Shared VPN

Shared VPN

Direct RoutingDirect Routing Split RoutingSplit RoutingDirect RoutingDirect Routing Split RoutingSplit Routing

With Inverse Multiplexing (w/IM)With Inverse Multiplexing (w/IM)

Without Inverse Multiplexing (w/oIM)Without Inverse Multiplexing (w/oIM)



Control Plane Model

Control Plane Model

IETFIETF ITUITU SPASPA

Dedicated VPN

Dedicated VPN

Shared VPN

Shared VPN




(w/oNE)


(w/oNE)

Dedicated VPN

Dedicated VPN

Shared VPN

Shared VPN

Direct RoutingDirect Routing Split RoutingSplit RoutingDirect RoutingDirect Routing Split RoutingSplit Routing





54

4.4 IETF control plane model

As listed in Table 4-1, the IETF control plane model has the following traffic management

capabilities:

1. Disabled LPF: The IETF control plane model does have the Load Partitioning Function

(LPF) implemented; thus all the load from multiple configured VPN services are

multiplexed on the same physical topology. This is illustrated in Figure 4-3 where arrival

load from both configured VPN service-1 and configured VPN service-2 are multiplexed

into the same physical resources. As will be mention in section 5.3, this is considered

Complete Sharing (CS) from a transport network perspective.

2. Static Routing: As illustrated in Figure 4-3, the IETF control plane model routes traffic

between a source-destination pair not based on the traffic occupancy state of the network.

3. Disabled IMF: The IETF control plane model does not implement the IMF on the

arriving service flow so bandwidth requirement Akb is not split it into multiple flows each

with granular bandwidth Gkb . On the contrary, the IETF control plane model

consumes Ckb coarse resources from the transport network; this is due to the coarse

realization of the transport network by the IETF routing component. For example, a

service request with actual bandwidth requirement Akb = 2STS-1 will consume G

kb =

3STS-1 from the transport network resources.

Figure 4-3: Traffic Management of IETF Control Plane Model

jC



Direct Routing (DR)

Split Routing (SR)

1=vrkλ

2=vrkλ

Akb Akb

Ckb2

Physical Resources



-

55

4.5 ITU control plane model

As listed in Table 4-1, the ITU control plane model has the following traffic management

capabilities:

1. Enabled LPF: The ITU control plane model has the Load Partitioning Function (LPF)

implemented; thus the load from multiple configured VPN services is partitioned into

multiple transport network partitions, and no traffic multiplexing between different

configured VPN services is allowed. This is illustrated in Figure 4-4 where load from

configured VPN service-1 and configured VPN service-2 is directed to dedicated

resources partition-1 and dedicated resource partition-2 respectively. As will be mention

in section 5.3, this is considered Complete Partitioning (CP) from a transport network

perspective.

2. Static Routing: Similar to the IETF control plane model; the static routing is implemented

in each transport network partition.

3. Disabled IMF: The ITU control plane model does not implement the IMF on the arriving

service request.

56

Figure 4-4: Traffic Management of ITU Control Plane Model

4.6 SPA-Dedicated control plane model

As listed in Table 4-1, the SPA-Dedicated control plane model has the exact traffic

management capabilities like the ITU model except state-dependent routing instead of static

routing.

4.7 SPA-Shared control plane model

As listed in Table 4-1, the SPA Shared control plane model has the following traffic

management capabilities:

1. Enabled LPF: The SPA control plane shared control plane model has the Load

Partitioning Function (LPF) implemented; thus the load from multiple configured VPN

services is partitioned into multiple resources partitions, LPF can be configured as Static

Partitioning (SS) or Network Engineering (NE). The SPA Shared control plane model

implementation of the LPF is different from the ITU or SPA-Dedicated control plane

Configured VPN

Service-1

-


-


D

jC

D

jC

2=vrkλ

1=vrkλ

Configured VPN

Service-1

Configured VPN

Service-2

Configured VPN

Service-2

Akb

Akb

Direct Routing (DR)

Split Routing (SR)

Akb

Akb

57

models. In the ITU or SPA-Dedicated control plane models, the entire arriving load from

a configured VPN service-1 is applied to dedicated resources partition-1. Similarly, the

entire load from a configured VPN service-2 is applied to dedicated resources partition-2.

In the SPA Shared control plane model, the load from a configured VPN service-1 is

partitioned into dedicated load applied to dedicated resources-1 partition, and a shared

load applied to shared resources partition. Similarly, the arriving load from a configured

VPN service-2 is partitioned into dedicated load applied to dedicated resources-2

partition, and a shared load applied to shared resources partition. This is illustrated in

Figure 4-5 . As will be mention in section 5.3, this is considered Virtual Partitioning (VP)

from a transport network perspective. In summary, VP divides the network resources into

a dedicated resources partition (D) and a shared resources partition (S). A dedicated load

from a configured VPN service-1 is applied to the dedicated resources partition-1; hence

no multiplexing of arriving loads from different configured VPN services is allowed on

the dedicated resources partition-1. Arriving load from different configured VPN services

can share the shared resources partition; hence multiplexing of arriving loads from

different configured VPN services is allowed on the shared resources partition.

2. State-dependent Routing: performed in all the dedicated resources partitions in addition

to the shared resources partition.

3. Enabled IMF: The SPA shared control plane model implements the Inverse Multiplex

(IM) where the arriving service request flow with actual bandwidth requirement Akb is split

into multiple flows each with granular bandwidth requirement Gkb .

58

Figure 4-5: Traffic Management of SPA Shared Control Plane Model


vDrkλ

vD

jC

vSrkλ

2=vrkλ

Source

1=vrkλ

Configured VPN

Service-1

Akb

Akb

Akb

Akb

vDrkλ

vD

jC

vSrkλ

SjC

Gkb

Gkb

Gkb

Gkb

Gkb

Gkb

LPF

LPF

IMF

IMF

IMF

Configured VPN

Service-2

Source

Destinations

Destinations Shared Resources Partition


Configured VPN

Service-1

Configured VPN

Service-1

Configured VPN

Service-1

Configured VPN

Service-2

Configured VPN

Service-2

Configured VPN

Service-2

Destinations

59

5 Control Plane Models– Transport Network Realization

This section compares the three control plane models from a transport network architecture

realization perspective. The transport network can be viewed from both horizontal and

vertical perspective. Horizontally, the transport network can be divided into network

domains. One dimension of the vertical view is dividing the transport network into multi-

granularity levels, each granularity level with actual bandwidth rate Akb . The sub-rate at a

specific transport network granularity level is multiplexed into the upper transport network

granularity level. The other dimension of the vertical view is dividing the physical transport

network resources into network resources partitions or Virtual Private Networks (VPNs). The

IETF, ITU, and SPA control plane model do not differ in their realization of a multi-domain

transport network but differ in their realization of a multi-granularity transport network. The

multi-domain view was described to provide a full view, from the three control planes

perspective, of the multi-domain multi-granularity transport network.

5.1 Horizontal view: multi-domain realization

The following concepts need to be described to understand the architectural differences for

the three control plane models realizations of the transport network architecture and more

specifically the multi-granularity aspect of the transport network.

1. Sub-network: The physical transport network can be divided into sub-networks based on

different technologies or ownership of network domains. A physical topology can be

divided into multiple sub-networks “domains” to simplify and scale routing protocols.

Parent sub-networks can be further divided into child sub-networks. A sub-network can

be partitioned into smaller sub-networks. Sub-networks are defined to be completely

contained within higher level sub-networks. Figure 5-1 illustrates sub-network

partitioning.

2. Sub-network point (SNP): A control plane representation of a transport network resource.

Each transport network granularity level is represented by a group of SNPs. The group of

SNPs are connected to each other by Sub-Network Connections (SNCs) in the same

topological view of the transport network granularity level. When the network resource

represented by a certain SNP is allocated to a service request, the status of the relevant

60

SNP is changed to “busy”, otherwise when the resource is available for a service request,

the status of the relevant SNP remains “idle”.

Figure 5-1: Control Plane Routing Areas Realization of Transport Network Partitioning into

Sub-Networks

3. Sub-network connection (SNC): A sub-network connection is a dynamic relation between

two (or more in the case of broadcast connections) Sub-network points (SNPs) at the

boundary of the same sub-network. For example, two adjacent sub-networks can be

connected by an SNC.

4. Sub-network point pool (SNPP): A control plane representation of a set of sub-network

points that are grouped together for the purposes of routing. An SNP pool can represent a

collection of SNPs within the same sub-network “horizontal-view” or represent a

collection of SNPs across multiple granularity levels “vertical-view”.

5. Routing Area (RA): A control plane representation of a transport network sub-network.

Each transport network sub-network is represented by a routing area. RAs are

hierarchically contained: a higher level (parent) RA contains lower level (child) RAs that

in turn MAY also contain RAs, etc. Thus, RAs contain RAs that recursively define

successive hierarchical RA levels. If a parent sub-network is divided into child sub-

networks, the parent RA is divided into child routing areas, each child transport sub-

A transport networkgranularity level

SNP

SNP

SNP

Child Routing Areawithin a parent Routing Area

Parent Area

ParentRouting Area

Parent Routing Area

Parent Routing Area

Parent Routing Area

SNC

Child Routing Area

A transport networkgranularity level

SNP

SNP

SNP

Child Routing Areawithin a parent Routing Area

Parent Area

ParentRouting Area

Parent Routing Area

Parent Routing Area

Parent Routing Area

SNC

Child Routing Area

61

network is represented by a control plane child routing area. The group of routing areas at

different routing levels represents a hierarchal routing architecture3.

6. Routing Level (RL): In a multi-level hierarchy of RAs, it is necessary to distinguish

between routing at different levels of the RA hierarchy. Two routing areas at the same

level of the routing hierarchy but belong to two different parent routing areas can not

directly exchange routing topology between them as routing topology exchange has to be

carried via their parent routing areas in a routing level above the child routing areas level.

Routing information can be exchanged across adjacent levels of the RA hierarchy i.e.

parent level and child level, where child level represents the RAs contained by parent

level.4

5.2 Vertical view: multi-granularity realization

The multi-granularity realization has two dimensions; the first dimension is the transport

network multi-granularity aspect, e.g., an STS-12 carry 12STS-1, the second dimension is the

demand multi-granularity aspect, e.g., a service request flow with actual bandwidth

requirement Akb =2STS-1 can be split into two flows each with granular bandwidth

requirement Gkb =1STS1.

5.2.1 IETF control plane model

From a demand granularity perspective, the Inverse Multiplexing Function (IMF) in the

IETF control plane model is disabled. Hence, IETF control plane model will not consider the

demand granularity level feature of the service profile in its service request routing or path

computation. As illustrated in Figure 5-2, the service request flow with actual bandwidth

requirement Akb is not split into multiple flows each with granular bandwidth

3 It is important to note that a single transport network granularity level can be represented by a

hierarchal routing architecture.

4 There is no implied relationship between multi-granularity transport networks and multi-level routing. The group of Routing Controllers (RCs) providing routing update for a sub network can be architected as flat or hierarchal routing architecture

62

requirements Gkb , instead A

kb service request is considered a service request with coarse

bandwidth requirements Ckb , because the routing and path computation components in the

IETF control plane model have a coarse representation of transport network granularity. In

other words, IETF routing and path computation components are not architected to optimize

mapping between the granularity level of service demands and the available granularity

levels of transport network. As a result, transport network resources will not be efficiently

utilized due to mismatch between the granularity level of the service demand and the

granularity level of the transport network.

Figure 5-2 illustrates the IETF control plane realization of the granularity levels of the

transport network. It can be observed that the IETF control plane model represents a multi-

granularity transport network by one SNP; this indicates the coarse representation of the

transport network granularity levels. From an IETF control plane model perspective, the

multi-granularity transport network is one physical layer. This leads that a service request

with granular demand requirement will be mapped to a coarse granularity level in the

transport network. This is illustrated in Figure 5-2 where the service request with actual

bandwidth requirement Akb = 2 STS-1 is mapped to the transport network resources as a

service request with coarse bandwidth requirement Ckb = 3 STS-1.

5.2.2 ITU control plane model

From a demand granularity perspective, the Inverse Multiplexing Function (IMF) in the ITU

control plane model is disabled. Hence, ITU control plane model will not consider the

demand granularity level feature, of the service profile, in its service demand routing or path

computation. As illustrated in Figure 5-3, the service request flow with actual bandwidth

requirement Akb is not split into multiple flows each with granular bandwidth

requirements Gkb ; instead A

kb service request is considered a service request with actual

bandwidth requirements Akb . The reason for that is since the routing and path computation

components in the ITU control plane model have a granular representation of transport

network granularity levels.

63

In other words, ITU routing and path computation components are architected to optimize

mapping between the granularity level of service demands and the available granularity levels

of transport network. As a result, transport network resources will be more efficiently utilized

than the IETF control plane model due to match between the granularity level of the service

request and the granularity level of the transport network. Figure 5-3 illustrates the ITU

control plane realization of the granularity levels of the transport network. It can be observed

that the ITU control plane model represents a multi-granularity transport network by multiple

SNPs, one SNP for each granularity level of the transport network, this indicates the granular

representation of the transport network granularity levels. This leads that a service request

with a certain granularity demand requirement will be mapped to the most optimum

granularity level in the transport network. This is illustrated in Figure 5-3 where the service

request with actual bandwidth requirement Akb = 2 STS-1 is mapped to the transport network

resources as a service request with actual bandwidth requirement Akb = 2 STS-1.

5.2.3 SPA control plane model

Similar to the ITU control plane model, the SPA-Dedicated control plane model has the same

granular representation of the transport network granularity level and the demand granularity

level. The SPA-Shared differs from the SPA-Dedicated since the IMF can be enabled which

further splits a service request flow with actual bandwidth requirement Akb into multiple flows

each with granular bandwidth requirements Gkb as illustrated in Figure 5-4.

64

Figure 5-2: IETF Control Plane Model Realization of Transport Network Granularity Levels

Figure 5-3: ITU and SPA-Dedicated Control Plane Models Realization of Transport Network

Granularity Levels

Service Demand Granularity

Service Parameters

Service Configuration Profile

ITUControl Plane Model

Akb Akb

Service Request with granular bandwidth

Service request with actual bandwidth

Akb Akb

IMF Disabled

Multi-Granularity Transport

SNPP.. ..SNPs SNPsSNP

SNPP..SNP SNPs SNP

Granular representation of transport network granularity levels

Routing Area Routing Area

SNCGranular representation of transport network granularity levels


Service Parameters


IETF Control Plane Model

Ckb Ckb

Service Request with granular bandwidth Service request with

actual bandwidth

Akb Akb IMF Disabled


Coarse representation of transport network granularity levels

SNPSNP


SNC

Coarse representation of transport network granularity levels

65

Figure 5-4: SPA-Shared Control Plane Models Realization of Transport Network Granularity

Levels

5.3 Vertical view: resources partitioning

The concept of resource partitioning and reservation has been extensively studied [44-54].

Many of these were focused on different resources partitioning and reservation methods to

maintain the SLA requirements, lower blocking probability, of some services. One of the

concepts introduced was Complete Sharing (CS) where the network resources are completely

shared among all configured VPN services; this represents the extreme form of unrestricted

sharing. Complete Partitioning (CP) was another concept that was analyzed which provides

complete isolation of the traffic between different configured services accessing the same

network resources; this represents the other side of extreme form of restricted sharing. Virtual

Partitioning (VP) was an intermediate paradigm for disciplined sharing; this paradigm assigns

a dedicated and shared network resources partition to each configured VPN service. Dividing


Service Parameters


Service Profile-Aware Control Plane

Transport Network

Gkb Gkb

Service Request with Multiple granular bandwidth

Service request with actual bandwidth

Akb Akb

IMF Enabled


SNPP.. ..SNPs SNPsSNP

SNPP..SNP SNPs SNP

Granular representation of transport network granularity levels


SNCGranular representation of transport network granularity levels

66

the physical resources into multiple partitions is realized by the control plane using the

Control Plane Instance (CPI) 5 concept. Each CPI includes the following:

1. Routing Database (RDB): Contains the local topology and resources within each network

partition. The Routing Information Database (RDB) is a repository for the local topology

within, network topology, reachability, and other routing information that is updated as

part of the routing information exchange. The RDB may contain routing information for

more than one routing area. Each control plane instance has a RDB that includes the

network topology controlled by the control plane instance.

2. Collection of Routing Controllers (RCs)6: Exchange topology information within the

network partition. The RCs can be divided into multiple Routing Areas (RAs) within the

same Routing Level (RL). The RCs can be grouped in a flat routing architecture, one

routing level, or a hierarchal routing architecture, multiple routing levels. In this research,

the RCs are assumed to be grouped in a flat routing architecture. The hierarchal routing

architecture is proposed to be analyzed in the future work beyond the scope of this

research.

1. Link Resource Manager (LRM): Supplies all the relevant connection resource

information to the Routing Controller. It informs the RC about any state changes of the

connection resources it controls.

5 The Control Plane Instance (CPI) is another definition that can be used to define a group of Routing

Areas within the same Routing Level. In the case of IETF control plane model, one control plane

instance will be used to provide resource updates and capacity allocation across the N-transport

network partitions. In the case of ITU control plane model, N control plane instances will be used to

provide resource updates and capacity allocation across the N-transport network partitions. The SPA-

Shared control plane model is similar to the ITU control plane model as it has N control plane

instances but with LPF across the N control plane instances. 6 The RC functions include exchanging routing information with peer RCs and replying to a route

query (path selection) by operating on the Routing Database (RDB).

67


The IETF control plane model does not partition its physical topology RDB into multiple

RDB partitions based on transport network partitioning; thus, the resources at different

network partitions of the transport network are represented by one RDB. In other words, the

IETF control plane model supports the Complete Sharing (CS) concept. The IETF control

plane model represents the N-partitions of the transport network by one Control Plane

Instance (CPI). Figure 5-5 illustrates the IETF single control plane instance controlling three

transport network partitions.

Figure 5-5: Instance Realization of Transport Network Partitions for the IETF Control Plane


The ITU control plane model partitions its physical topology RDB into multiple RDB

partitions based on transport network partitioning; thus the resources of each network

partitions of the transport network is represented by a separate RDB. In other words, the ITU

control plane model supports the Complete Partitioning (CP) concept. The ITU control plane

model represents the N-partitions of the transport network by N Control Plane Instances

(CPIs). Figure 5-6 illustrates ITU three control plane instances controlling three network

resources partitions. It is important to note that ITU control plane instances do not exchange

routing information across CPIs by linking the Link Resource Management (LRM)

components of the control plane instances; thus not allowing customer traffic to be re-routed

One Control Plane Instance with one RDB for the Three Transport Network Partitions “VPNs”

LRMLRM


Network Partition “VPN-A”

Network Partition “VPN-C”

Network Partition “VPN-B”

RDBRDB

RCRC RCRC RCRCControl PlaneControl Plane

InstanceInstance

One Control Plane Instance with one RDB for the Three Transport Network Partitions “VPNs”

LRMLRM





RDBRDB

RCRC RCRC RCRCControl PlaneControl Plane

InstanceInstance

68

from one network resources partition to another network resources partition based on the

configured policy. The network resources within each network partition, controlled by a

control plane instance, are not shared with other network resources partitions. In other words,

the control plane instances in the ITU model are independent in their traffic management

scheme of each network resources partition. This would imply that ITU control plane model

has no Load Partitioning Function (LPF) implemented to coordinate load sharing by the

control plane instances across network resources partitions.

Figure 5-6: Instance Realization of Transport Network Partitions for ITU/SPA-Dedicated

Control Plane Models


The SPA control plane model has two versions; dedicated and shared. The SPA-Dedicated

control plane model implements the Complete Partitioning (CP) concept in its realization of

transport network resources partitions. The difference between the ITU and the SPA-

Dedicated control plane models is that the later implements state-dependent routing instead of

the static routing implemented by the ITU control plane model. The SPA-Shared control

plane model supports the Virtual Partitioning (VP) concept by allowing traffic exchange

across network resources partitions. This is enabled in the SPA-Shared control plane model

by linking the Link Resource Management (LRM) components of the control plane instances

via the Load Partitioning Function (LPF). Similar to the ITU control plane model, the SPA-

Three Control Plane Instance with Three RDB partitions for the Three Transport Network Partitions “VPNs”Without inter-control plane instances resource sharing via Load Partitioning Function (LPF)

LRM-ALRM-A

ITU/SPA-Dedicated Control Plane Models




RDB-ARDB-A

RCRC RCRC RCRC

LRM-CLRM-CRDB-CRDB-C

RCRC RCRC RCRC

LRM-BLRM-BRDB-BRDB-B

RCRC RCRC RCRC

Control PlaneControl PlaneInstanceInstance--AA

Control PlaneControl PlaneInstanceInstance--CC

Control PlaneControl PlaneInstanceInstance--BB

69

Shared control plane model represents the N-partitions of the transport network by N-Control

Plane Instances (CPIs). Figure 5-7 illustrates the SPA-Shared three control plane instances

controlling three network resources partitions with LPF, linking the Link Resource

Management (LRM) component of each control plane instance, which allows traffic

exchange across network resources partitions.

Figure 5-7: Instance Realization of Transport Network Partitions for the SPA-Shared Control

Plane

6 Control Plane Models- Component-Level Interaction

This section is focused on the component-level interaction between the control plane

components with both the service configuration profile components and the transport network

components. In analyzing the components operational flow for each of the three control

plane models, we need to include the impact of both the service configuration profile layer

and the transport network layer. As mentioned earlier, the service configuration profile layer

includes the following parameters:

1. Load partitioning flexibility (disabled vs. enabled)

2. Service demand granularity (granular vs. coarse)

3. Service flow connectivity (point-to-point, semi-meshed, fully-meshed)

SPA-Shared Control Plane ModelThree Control Plane Instance with Three RDB partitions for the Three Transport Network Partitions “VPNs”

With inter-control plane instances resource sharing via Load Partitioning Function (LPF)

LRM-ALRM-A Network Partition “VPN-A”



RDB-ARDB-A

RCRC RCRC RCRC


RCRC RCRC RCRC


RCRC RCRC RCRC




Resource Sharing via LPF


SPA-Shared Control Plane ModelThree Control Plane Instance with Three RDB partitions for the Three Transport Network Partitions “VPNs”


LRM-ALRM-A Network Partition “VPN-A”



RDB-ARDB-A

RCRC RCRC RCRC


RCRC RCRC RCRC


RCRC RCRC RCRC






70

4. Configured VPN service identification number (v)

The transport network provides parameters that are related to the transport network including:

1. Transport network granularity level (granular vs. coarse)

2. Transport topology occupancy state (per link)


The following service configuration profile parameters are considered in IETF control plane

model when a service request is handled:

1. Service demand granularity

2. Service flow connectivity

As illustrated in Figure 6-1, the following is the IETF control plane model components operational flow sequence:

Component Interaction: Control Plane Models & Service Configuration Profile:

1. Based on a service request initiation, the “service flow connectivity” parameter from the

service configuration profile layer is sent to the “path computation” component in the

IETF control plane layer, the “service demand granularity” parameter from the service

configuration profile layer is sent the Inverse Multiplexing Function (IMF) in the IETF

control plane layer.

2. Since IMF is disabled, the service request flow with actual bandwidth requirement Akb is

not split into multiple flows each with granular bandwidth requirement Gkb . Instead

Akb service request is considered a service request with coarse bandwidth requirement C

kb .

3. The “path computation” component analyzes the service flow to determine the source-

destination pair and the appropriate routing controllers to be contacted to determine the

appropriate route for the service request.

4. The “path computation” component sends a route query request to the “static routing”

component in the control plane layer.

71

Component Interaction: Control Plane Models & Transport Network :

5. Since the routing component in the IETF control plane model has a coarse realization of

the transport network multi-granularity levels, the transport network coarse-granularity

level is provided to the “static routing” component.

6. The “static routing” component provides the topology routing options to the “path

computation” component without considering the transport topology traffic occupancy

state for each of the topology links.

7. The “path computation” component computes a route based on:


b. Service demand coarse bandwidth requirement Ckb

c. Transport network coarse granularity level.

8. A connection setup is initiated.

Figure 6-1: IETF Control Plane Components Operational Flow Sequence

Static Routing


Service Parameters

Transport Network

Path Computation

Coarse Transport Network Granularity Levels

Connection Setup


1

2

65

43


Routing Component

Service Flow Connectivity

Inverse Multiplexing Disabled 2

Inverse Multiplexing Function (IMF)

1

8

7

72


The following service configuration profile parameters are considered in ITU control plane

model when a service request is handled:




As illustrated in Figure 6-2, the following is the ITU control plane model components operational flow sequence:


1. Based on a service request initiation, the “service flow connectivity”, “service demand

granularity” and “configured VPN service identification number” parameters from the

service configuration profile layer are sent to the “control plane instance selection”

component in the ITU control plane layer.

2. Based on the “configured VPN service identification number” parameter, the “control

plane instance selection” component decides which control plane instance is responsible

for handling the arriving service request.

3. Since IMF is disabled for all Control Plane Instances (CPIs), the service request flow

with actual bandwidth requirement Akb is not split into multiple flows each with granular

bandwidth requirements Gkb , instead A

kb service request is considered a service request

with actual bandwidth requirement Akb . The reason for that is provided in section 5.2.2.

4. The “path computation” component for the selected control plane instance analyzes the

service flow to determine the source-destination pair and the appropriate routing

controllers to be contacted to determine the appropriate route for the service request.

5. The “path computation” component sends a route query request to the “static routing”

component in the control plane layer.

73


6. Since the ITU control plane model has a granular realization of the transport network

multi-granularity levels, the transport network fine-granularity levels are provided to the

“static routing” component.

7. The “static routing” component provides the topology routing options to the “path

computation” component without considering the transport topology traffic occupancy

state for each of the topology links.



b. Service demand actual bandwidth requirement Akb

c. Transport network fine “detailed” granularity level.


Figure 6-2: ITU Control Plane Components Operational Flow Sequence

Static Routing


Configured VPN Service Identification Number

Service Parameters

Transport Network

Control Plane Instance (CPI) Selection

Path Computation

Granular Transport Network Granularity Levels

Connection Setup

ITU Control Plane Model

2

4 87

65

9


Routing Component

2Inverse Multiplexing Disabled 3



111

74

6.3 SPA control plane model

The SPA-Dedicated control plane model has the same sequence like the ITU control plane

model expect step (6) since the routing component in the SPA-Dedicated implements state-

dependent routing instead of fixed routing. The following service configuration profile

parameters are considered in SPA-Shared control plane model when a service request is

handled:

1. Load partitioning flexibility




As illustrated in Figure 6-4, the following is the SPA-Shared control plane model components

operational flow sequence:


1. Based on a service request initiation, the “service flow connectivity”, “service demand

granularity”, “load partitioning flexibility” and “configured VPN service identification

number” parameters from the service configuration profile layer are sent to the “control

plane instance selection” component in the SPA-Shared control plane layer.

2. Based on the “configured VPN service identification number” parameter, the “control

plane instance selection” component decides which control plane instance is responsible

for handling the arriving service request.

3. If the service load partitioning is permissible by the arrival service request, the service

arrival rate is partitioned between the dedicated and shared resources partitions using the

following two options:

a. Static Sharing (SS): statically partition the configured VPN service arrival

load into two partitions. A dedication load based on the capacity ratio of the

dedicated resources partition to the VPN resources partition (sum of

dedicated and shared resources), and a shared load based on the capacity

ratio of the shared resources partition to the VPN resources partition. This

option is called “without Network Engineering”

75

b. Network Engineering (NE) enabled: dynamically partition the arrival load

between the dedicated and shared resources partitions of a configured VPN

service based on the blocking probability of the dedicated resources partition.

In round-1, the configured VPN service total load is applied to the dedicated

resources and a blocking probability is generated. In round-2, the unblocked

load is applied again to the dedicated resources partition and the blocked load

is applied to the shared resources partition.

4. If the service demand granularity is provided by service request, the control plane Inverse

Multiplexing Function will split each service request with actual bandwidth requirement Akb into multiple flows each with granular bandwidth requirement G

kb .

5. The “path computation” component for the selected control plane instance analyzes the

service flow to determine the source-destination pair and the appropriate routing

controllers to be contacted to determine the appropriate route for the service request.

6. The “path computation” component sends a route query request to the “state-dependent

routing” component in the control plane layer.


7. Since the SPA control plane model has granular realization of the transport network

multi-granularity levels, the transport network fine-granularity levels are provided to the

“state-dependent routing” component. In addition, the “state-dependent routing”

component captures the transport topology traffic occupancy state for each of the

topology links.

8. The “state-dependent routing” component provides the topology routing options to the

“path computation” component while considering both the transport topology traffic

occupancy state for each of the topology links and the transport network fine granularity

levels.



b. Service demand actual bandwidth requirement Akb

76

c. Arrival load partitioning flexibility

d. Transport network fine granularity levels.

e. Transport network occupancy state per topology link


Figure 6-3: SPA-Dedicated Control Plane Components Operational Flow Sequence

State-DependentRouting



Service Parameters

Transport Network

Control Plane Instance (CPI) Selection

Path Computation


Connection Setup

SPA-DedicatedControl Plane Model

2

4 87

65

9


Routing Component

2Inverse Multiplexing Disabled 3



111

77

Figure 6-4: SPA-Shared Control Plane Components Operational Flow Sequence

7 Analysis Methodology – Fixed Point Approximation

This section provides the analysis methodology used to provide a common quantitative

framework for studying the performance of the IETF, ITU, and SPA control plane models.

Fixed Point Approximation (FPA) concept was used to compute the following parameters

where the last three were used as performance metrics:

1. Link’s reduced load jkλ

2. Link’s occupancy probability )(np j and link’s blocking probability jka

3. Routing probability for each possible route mrkq

4. Network-wide blocking probability kB

5. Network-wide average permissible load kλ̂

6. Network-wide utilization U

Detailed description of the performance metrics and their relevant mathematical formulations

for each control plane model is provided in section 9.3.

State-DependentRouting


Arrival RatePartitioning

Service Parameters

Transport Network

Service DemandGranularity

Inverse MultiplexingDisabled vs. Enabled

Network Engineering Vs. Static Sharing

Path Computation


Connection Setup

Current Topology Occupancy State “Per link”

SPA-SharedControl Plane Model

3 4

568

77

9

10

Service Configuration

Profile


Control Plane Instance (CPI) Selection1

2111

Routing Component

Inverse Multiplexing Function (IMF)Load Partitioning Function (LPF)

78

The analytical models need to provide a mathematical representation for:

1. Connection Admission Control (CAC) for service requests with multi-rate bandwidth

requirements in a multi-granularity transport network. The mathematical models have to

provide three versions addressing the IETF, ITU, and SPA control plane realization of

multi-granularity service request and multi-granularity transport network.

2. A routing mechanism for multi-rate multi-hop loss networks

3. Traffic management schemes, capacity assignment/allocation, in presence of the control

plane Load Partitioning Function (LPF) and Inverse Multiplexing Function (IMF)

For the rest of our discussion we will use the terms calls and service requests

interchangeably. In a loss network traffic arrives in the form of calls, each requiring a fixed

amount of bandwidth on every link along a path/route chosen between the source and

destination nodes. Upon a service request arrival, if the network has a route with the required

bandwidth available on its entire links, the service request is admitted and set up, and it will

hold the requested bandwidth for the entire duration of the service request; otherwise the

service request is rejected or blocked. Upon the departure of a service request, the occupied

bandwidth is released from all the links on the route. State-dependent routing [68] is a

commonly studied routing policy, under which a service request is assigned to a certain route

based on the state of the network, e.g., link congestion level.

Kelly in [59] provided an analytical framework for a multiple links and multiple classes of

calls with different arrival rates and different bandwidth requirement. When static or fixed

routing is associated with each source-destination node pair, a loss network can be modeled

as a multi-dimensional Markov process, with the dimension of the state space being the

product of the number of routes allowed in the network and the number of service request

classes. This can be explained since the number of calls of each class on each route uniquely

defines the state of the network. This Markov process possesses a product form which

simplifies the computation of the solution. In the case of alternative routing, each source-

destination node pair is allowed more than one route. This leads to a situation that can no

longer be represented in product form. Kelly in [59] defined equilibrium state probabilities

that can be derived by writing out the entire set of detailed balance equations and solving

them. This approach however, is not practical in dealing with large networks with a large

79

number of routes and integrated services with potentially a large number of service classes,

since the computational complexity is both exponential in the number of routes and

exponential in the number of service classes. This leads to the need for fast computational

techniques that provide accurate estimates.

Blocking probabilities in a loss network, and the reduced load approximation (also known as

the fixed point method) proposed for computing blocking probabilities have been studied

extensively. As discussed in [63]–[66], the reduced load approximation is based on the

following two assumptions:

1. Link independence assumption. Under this assumption, blocking is regarded as to occur

independently from link-to-link. This assumption allows us to compute the blocking

probability at each link separately.

2. Poisson assumption. Under this assumption, calls arrive at a link as a Poisson process and

the corresponding arrival rate is the original external offered rate thinned by blocking on

other links, thus known as the reduced load. Consider the case of a single class of calls

with fixed/static routing. Using Erlang’s formula, the blocking probability of each link

can be expressed by the offered service request arrival rate and the blocking probabilities

of other links. This leads to a set of nonlinear fixed point equations with the link blocking

probabilities as the unknown variables. Solving these equations gives us the

approximation on the blocking probability of each link. Recent work on using reduced

load approximation for fixed routing can be found in [60], [61], [66], and [67].

The analytical methods developed here are based on Liu and Baras [68] which proposed a

mathematical model to compute the blocking probability of a multi-rate multi-hop loss

networks with state-dependent routing. We will assume the same assumptions used in [68] as

follows:

1. All links are assumed to be undirected. For traffic between two nodes, we will not

differentiate the source from the destination. Consequently a feasible route set is

associated with a pair of nodes, regardless of the ordering. This assumption is adopted

only for the simplicity of notation and our discussion. Our models can be applied to

directional link scenarios in a straightforward manner.

80

2. Calls arrive at the network as a Poisson process and the total offered load to an

individual link is also a Poisson process with rate thinned by blocking on other links.

3. Blocking occurs independently from link to link, determined by their respective arrival

rates. That is, even though the conditions of successive links along a route are dependent

(so is the blocking on these links), we will nevertheless treat them as being independent.

This assumption becomes more reasonable as traffic gets heavier.

4. We will assume that given stationary inputs, certain random quantities of interest have

well-defined averages. These include the number of on-going calls on a link of each

class, the average service request holding time, and the reduced load on a link. With these

averages we can further assume that there is a stationary probability of choosing a

particular route under the state-dependent routing scheme. Thus, the key is to find these

probabilities so that the state-dependent routing can be approximated with a stationary,

non-state-dependent routing algorithm with the derived probabilities of route selection.

7.1 Notation

The Fixed Point Approximation mechanism uses the notation specified in sections 3.1 and 4.1

to describe the configuration VPN service models and the control plane models respectively.

In addition, the following notation is used:

1. N : The set of nodes in the network. We will use N to denote both the set and the total

number of nodes in a network topology.

2. J : The set of links in the network. Again, we will use J to denote both the set and the

total number of links in the network.

3. K : The total number of service request classes. Each class k has a bandwidth

requirement denoted by kb , and a mean service request holding time denoted by kμ .

],.....,2,1[ KkkK =

4. R : Both the set and the total number of node pairs in the network. Since we ignore the

ordering of a pair. 2

)1( −=

NNR

5. rM : The set of routes allowed between node pair r . We will also use rM to denote the

total number of routes between node pair r

81

6. mr : The thm route of the source-destination node pair r . Here, rMm ,.....,2,1= . mr

defines a set of links.

7. rkB : The blocking probability of a class k service request between node pair r

8. DrkB : The blocking probability of a class k service request between node pair r for

dedicated network resources partition D.

9. vDrkB : The blocking probability of a class k service request between node pair r for

dedicated network resources partition D of configured VPN service- v. This blocking

probability is obtained during round-1 of FPA when Network Engineering is enabled for

the SPA-Shared control plane model.

10. SrkB : The blocking probability of a class k service request between node pair r for shared

network resources partition S.

11. vrkB : The blocking probability of a class k service request between node pair r for VPN

network resource partition v.

12. kB : The network-wide blocking probability of a class k service request.

13. vkB : The network-wide blocking probability of a class k service request for VPN network

resource partition v.

14. jka : The probability that link j is in a state of admitting class k calls, or the admissibility

probability of link j.

15. Djka : The probability that dedicated network resources partition D in link j is in a state of

admitting class k calls, or the admissibility probability of link’s resources partition D in

link j.

16. Sjka : The probability that shared network resources partition S in link j is in a state of

admitting class k calls, or the admissibility probability of link’s resource partition S in

link j.

17. vDjka : The probability that dedicated resources for configured VPN service v in link j is in

a state of admitting class k calls, or the admissibility probability of link’s resources

partition D for configured VPN service v in link j.

82

18. vjka : The probability that VPN network resources partition v in link j is in a state of

admitting class k calls, or the admissibility probability of link’s resources partition v in

link j. This is the admissibility of both the dedicated resources partition vDjka and the

shared resources partition Sjka .

19. )(np j : The stationary occupancy probability of link j, i.e., the probability that exactly n

circuits/trunks are being used on link j.

20. Djp : The stationary occupancy probability of dedicated resources partition D for link j,

i.e., the probability that exactly n circuits/trunks are being used on network resource

partition D for link j.

21. )(npvDj : The stationary occupancy probability of dedicated resources partition D for

configured VPN service-v for link j, i.e., the probability that exactly n circuits/trunks are

being used on dedicated resources partition D of configured VPN service-v for link j.

22. )(np Sj : The stationary occupancy probability of shared resources partition S for link j,

i.e., the probability that exactly n circuits/trunks are being used on network resource

partition S for link j.

23. mrkq : The probability that the thm route is chosen for a class k service request between

node pair r.

24. mDrkq : The probability that the thm route is chosen for a class k service request between

node pair r in network resources partition D.

25. mSrkq : The probability that the thm route is chosen for a class k service request between

node pair r in shared network resources partition S.

26. )( mDn rA : The event that all links in network resources partition D on route mr have at

least n free circuits/trunks.

27. )(1 mDn rA + : The event that all links in network resources partition D on route mr have at

least n+1 free circuits/trunks.

28. )( mkDn rrA − : The event that all links belonging to route kr and not route mr in network

resources partition D have at least n free circuits/trunks.

83

29. )( mkD

n rrA − : The event that at least one of the links belonging to route kr and not

route mr in network resources partition D has less than n free circuits/trunks.

30. )(1 mkDn rrA −+ : The event that all links belonging to route kr and not route mr in network

resources partition D have at least n+1 free circuits/trunks.

31. )(1 mkD

n rrA −+ : The event that at least one of the links belonging to route kr and not

route mr in network resources partition D has less than n+1 free circuits/trunks.

32. )(~m

Dn rA : The event that all links in shared network partition D on route mr have at least n

free trunks/circuits and at least one link on route mr has exactly n free trunks/circuits.

33. )(1 mSn rA + : The event that all links in shared network resources partition S on

route mr have at least n+1 free circuits/trunks.

34. )( mkSn rrA − : The event that all links belonging to route kr and not route mr in shared

network resources partition S have at least n free circuits/trunks.

35. )( mkS

n rrA − : The event that at least one of the links belonging to route kr and not

route mr in shared network resources partition S has less than n free circuits/trunks.

36. )(1 mkSn rrA −+ : The event that all links belonging to route kr and not route mr in shared

network resources partition S have at least n+1 free circuits/trunks.

37. )(1 mkS

n rrA −+ : The event that at least one of the links belonging to route kr and not

route mr in shared network resources partition S has less than n+1 free circuits/trunks.

38. )(~m

Sn rA : The event that all links in shared network resources partition S on route mr have

at least n free trunks/circuits and at least one link on route mr has exactly n free

trunks/circuits.

39. mrjkλ : The reduced load on link j contributed by traffic class k on route mr and thinned by

blocking probability on other links.

84

40. mrDjkλ : The reduced load on dedicated resources partition D in link j contributed by traffic

class k on route mr and thinned by blocking probability on other network partitions from

other links.

41. mrDjk

NEλ : The reduced load on dedicated resources partition D in link j contributed by

traffic class k on route mr and thinned by blocking probability on other network partitions

from other links. This reduced load results from configuring the Load Partitioning

Function (LPF) to perform Network Engineering (NE) traffic management.

42. mrSjkλ : The reduced load on shared resources partition S in link j contributed by traffic


other links.

43. mrSjk

NEλ : The reduced load on shared resources partition S in link j contributed by traffic


other links. This reduced load results from configuring the Load Partitioning Function

(LPF) to perform Network Engineering (NE) traffic management.

44. Srkλ~ : sum of all the shared loads applied to the shared network resources partition S

jC

45. Srk

NEλ~ : sum of all the shared loads applied to the shared network resources

partition SjC .This reduced load results from configuring the Load Partitioning Function

(LPF) to perform Network Engineering (NE) traffic management.

46. Djkλ : The aggregated load of class k on dedicated network resources partition D for link j

from the load generated at all the source-destination pairs r.

47. Djk

NEλ : The aggregated load of class k on dedicated network resources partition D for link

j from the load generated at all the source-destination pairs r. This reduced load results

from configuring the Load Partitioning Function (LPF) to perform Network Engineering

(NE) traffic management.

48. Sjkλ : The aggregated load of class k on shared network resources partition S for link j

from the load generated at all the source-destination pair r.

85

49. Sjk

NEλ : The aggregated load of class k on shared network resources partition S for link j

from the load generated at all the source-destination pair r. This reduced load results from

configuring the Load Partitioning Function (LPF) to perform Network Engineering (NE)

traffic management.

50. jn : The number of “in-progress” calls in the link j. jj Cn ,.....,2,1= .

51. Djn : The number of “in-progress” calls in the network resource partition D for link j.

52. Djkn : The number of “in-progress” class-k calls in the dedicated resourced partition D.

53. vDjkn : The number of “in-progress” class-k calls in the dedicated resources partition D of

VPN v.

54. Sjkn : The number of “in-progress” class-k calls in the shared resources partition S.

55. rkλ̂ : Source-destination pair r permissible “non-blocked” load for class k service request

arrivals.

56. Drkλ̂ : Source-destination pair r permissible “non-blocked” load for class k service request

arrivals on network resource partition D.

57. kλ̂ : Network-wide permissible “non-blocked” load for class k service request arrivals.

58. Dkλ̂ : Network-wide permissible “non-blocked” load for class k service request arrivals on

network resource partition D.

59. jU : Link j utilization.

60. DjU : Network resource partition D in Link j utilization.

61. U : Network-wide utilization.

7.2 Fixed Point Approximation (FPA) framework

This section provides the FPA common framework that will be specialized for each control

plane model. The detailed fixed point approximation mathematical formulas for each control

plane model are provided in section 8. The main objective of the Fixed Point Approximation

is to compute the source-destination pair r route blocking probability rkB for class k. In order

86

to compute rkB , we need to use the first point approximation to compute jkλ , jka , )(np j and

mrkq . We will use the same analysis done by Liu and Baras in [68] to compute the above

variables. The FPA steps are as follows:

Step-1 Calculating link’s reduced load jkλ . Recall that mrjkλ is the reduced load on link j

contributed by traffic class k on route mr and thinned by blocking probability on other

links. Note that we first take a portion of the total offered load rkλ that is routed on mr with

probability mrkq , and then multiple it with the probability that this portion is admitted by

all links other than link j. We fix the link admissibility probability jka and the route

probability mrkq . Once jka and m

rkq are calculated, then jkλ , reduced load on link j based on

service class k, can be computed.

Step-2: Calculating link’s occupancy probability )(np j and link’s admissibility

probability jka . We fix jkλ to get the link occupancy probability )(np j and jka . The

CAC mechanism for each control plane model is used to deny or grant network resources

to a service request bandwidth requirements.

Step-3: Calculating routing probability for each possible route mrkq . Once the occupancy

probability is calculated, mrkq can be calculated.

Step-4: Compute network-wide blocking probability kB for class k

Step-5: Compute the network-wide average permissible load kλ̂ for class k

Step-6: Compute network-wide utilization U

By repeated substitution, the equilibrium fixed point can be solved for all the set of

unknowns.

Figure 7-1 illustrates the interaction of the set of unknowns during FPA computation. Figure

7-2 illustrates the modeling framework by showing the network topology parameters and the

service parameters as input to the Fixed Point Approximation mechanism. When the FPA

variables converge, the per-route blocking probability is computed. The contribution of this

87

work was to specialize this common FPA for each control plane model to compute the

compute jkλ , jka , )(np j and mrkq .

Figure 7-1: Fixed Point Approximation (FPA) Computation Steps

Figure 7-2: FPA Framework

)(np j

Estimating Link’s Reduced Load

Estimating Occupancy

Probabilities

jkamrkq

Estimating Admissibility Probabilities

Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

jkλ

Service Arrivals

)(np j



Probabilities

jkamrkq


Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

],........,,[

],........,[

],.......,,[],......,,[

21

21

21

21

Kk

mrjk

mrj

mrj

mrjk

Kk bbbbKkkK

μμμμ

λλλλ

=

=

==

],....,,[],.....,,[

].,..........[log____#

].,,.........2,1[],........,2,1[

21

21

,2,1

jj

mm

rr

CCCCrrrr

MMMMytopoinpairsnodeofR

JJNN

==

====

2∑ ∏

∈

−=m mrj

jkmrkrk aqB 1 Compute Per-Route

Blocking Probability

Topology Parameters

1

jkλService Arrivals

)(np j



Probabilities

jkamrkq


Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

],........,,[

],........,[

],.......,,[],......,,[

21

21

21

21

Kk

mrjk

mrj

mrj

mrjk

Kk bbbbKkkK

μμμμ

λλλλ

=

=

==

],....,,[],.....,,[

].,..........[log____#

].,,.........2,1[],........,2,1[

21

21

,2,1

jj

mm

rr

CCCCrrrr

MMMMytopoinpairsnodeofR

JJNN

==

====

2∑ ∏

∈

−=m mrj



Topology Parameters

1

jkλ

88


As described in section 5.3.1, the IETF control plane model represents the N-network

resources partitions of the transport network by one Control Plane Instance (CPI). This leads

to a one Fixed Point Approximation (FPA) instance required to compute vjkλ , jka and )(np j

on the physical resources level. As describes in section 5.3.1, the IETF control plane model

has one RDB providing routing options for the multiple network partitions within the

physical network topology. From a FPA perspective, the FPA statically sets the routing

probability for each possible route between a source-destination pair r. Thus, no mrkq is

computed based on the link(s) occupancy probabilities between the source –destination pair r.

Figure 7-3 illustrates the IETF control plane model single FPA instance for multiple network

resource partitions. It should be noted that there is no arrow from the occupancy

probability )(np j computation step and the routing probability mrkq computation step; which

indicates that the routing probability mrkq for each source-destination pair is set statically.

Figure 7-3: IETF single FPA Instance for Three Transport Network Partitions


As described in section 5.3.2, the ITU control plane model represents the N-network

resources partitions of the transport network by N-Control Plane Instances (CPIs). This leads


)(np j



Probabilities

jkamrkq


Estimating Routing

Probabilities

One FPA Instance for the Three Transport Network Partitions “Dedicated Resources”

No State-Dependent Routing

Dedicated Resources-1



jkλ

89

to N-Fixed Point Approximation (FPA) instances required to compute Djkλ , D

jka , )(np Dj on

each network resources partition. As describes in section 5.3.2, the ITU control plane model

has N- RDB providing routing options for the N-network resources partitions within the

physical network topology. Similar to the IETF control plane model and from a FPA instance

perspective, each of the N FPA instances statically sets the routing probability for each

possible route between a source-destination pair r. Thus, no mDrkq is computed based on the

link(s) occupancy probabilities between the source –destination pair r within the transport

resources partition controlled by the FPA instance.

Figure 7-4 illustrates the ITU control plane model three FPA instances for the three network

resource partitions. Similar to the IETF control plane model, it should be noted that, for each

FPA instance, there is no arrow from the occupancy probability )(np Dj computation step and

the routing probability mDrkq computation step; which indicates that the routing

probability mDrkq for each source-destination pair is set statically. The Complete Partitioning

(CP) from a physical resources perspective is reflected on the N-FPA instances as it should be

noted from Figure 7-4 that there is no interaction between the FPA instances; this indicates

that no Load Partitioning Function (LPF) is implemented.

90

Figure 7-4: ITU Three FPA Instances for Three Transport Network Partitions


Similar to the ITU control plane mode, the SPA-Dedicated control plane model represents the

N-network resources partitions of the transport network by N-Control Plane Instances (CPIs).

This leads to N-Fixed Point Approximation (FPA) instances required to compute Djkλ , D

jka ,

)(np Dj and mD

rkq on each network resources partition. A difference from the ITU control

plane model, each of the N FPA instances, in the SPA-Dedicated control plane model,

dynamically computes the routing probability for each possible route between a source-

destination pair r. Thus, mDrkq is computed based on the link(s) occupancy probabilities

between the source –destination pair r within the transport resources partition controlled by

each FPA instance. Figure 7-5 illustrates the SPA-Dedicated control plane model three FPA

instances for the three network resource partitions. To enable the state-dependent routing, it

should be noted that, for each FPA instance, there is an arrow from the occupancy

probability )(np Dj computation step and the routing probability mD

rkq computation step; which

indicates that the routing probability mDrkq or each source-destination pair is computed



Probabilities


Estimating Routing

Probabilities

Three FPA Instance for the Three Transport Network Partitions “Dedicated Resources”

No State-Dependent Routing

ITU Control Plane Model




Per Network PartitionPer Network Partition

Per Network Partition


mDrkq

)(npDj

Djka

Djkλ

91

dynamically based on the links’ occupancy probabilities within each network resources

partition.

The SPA-Shared control plane mode is similar to the SPA-Dedicated control plane model in

its state-dependent routing and N-CPIs for the N-network resources partitions, but differs in

allowing load sharing between the FPA instances via the Load Partitioning Function (LPF).

Figure 7-6 illustrates the SPA-Shared control plane model three FPA instances for the three

network resource partitions. It should be noted that the three FPA instances are inter-

connected by a Load Partitioning Function (LPF) to allow the arrival load allocation on

different network resources partitions based on the defined policy by the (LPF).

Figure 7-5: SPA-Dedicated Three FPA Instances for Three Transport Network Partitions



Probabilities


Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

SPA-Dedicated Control Plane Model




Three FPA Instance for the Three Transport Network Partitions “Dedicated Resources”

With State-Dependent Routing




mDrkq

)(npDj

Djka

Djkλ

92

Figure 7-6: SPA-Shared Three FPA Instances for Three Transport Network Partitions

8 Mathematical Formulation of Control Plane Models for Traffic

Management Schemes

This section presents the detailed Fixed Point Approximation mathematical models

developed for the traffic management schemes of the IETF, ITU, SPA-Dedicated, and SPA-

Shared control plane models. As described in section 7.2, the main objective of the Fixed

Point Approximation is to compute the source-destination pair route r blocking

probability rkB . In order to compute rkB , we need to use the FPA to compute jkλ , jka ,

)(np j and mrkq . The FPA steps are as follows:

Step-1: Connection Admission Control (CAC) for multi-rate service requests

Step-2: Calculating link’s reduced load jkλ .

Step-3: Calculating link’s occupancy probability )(np j and link’s admissibility

probability jka .



Probabilities


Estimating Routing

ProbabilitiesIn

the

case

of S

tate

-D

epen

dent

Rou

ting

SPA-Shared Control Plane Model


Shared Resources


Three FPA Instance for the Three Transport Network Partitions “2 Dedicated & 1 Shared Resources”

With State-Dependent Routing





mDrkq

)(npDj

Djka

Djkλ


93

Step-4: Calculating routing probability for each possible route mrkq .7

Step-5: Compute network-wide blocking probability kB for class k

Step-6: Compute network-wide average permissible load kλ̂ for class k

Step-7: Compute network-wide utilization U

We will first present the base method as provided in [68] and then specialize for each traffic

management scheme of the three control plane models.

8.1 Step-1 CAC for multi-rate service requests

8.1.1 Base method

The problem of fair and efficient resource sharing has a long history. Foschini, Gopinath and

Hayes [44] consider admission control policies which induce product-form equilibrium

distributions, and show that a threshold policy is optimal. Gopal and Stern [45] use Markov

Decision Theory to determine threshold policies that maximize the link utilization.

Kraimeche and Schwartz [46] consider a class of restricted-access policies which aim to

reduce blocking probabilities. The recent important work on Link Sharing by Floyd and

Jacobson [47] has motivations in common with this work, except that the framework here is

that of calls and loss models. The work of Ash et. al. [48] on class-of-routing is also aimed at

balancing fairness and efficiency. Borst and Mitra [49] develop computational algorithms for

analyzing heterogeneous traffic classes in virtual partitioning network architectures. A key

assumption in our analytic approximation is link independence, which is common to FPAs

for loss networks. Excellent sources of information on FPAs are Kelly [50] and Ross [51].

Recent applications of virtual partitioning to admission control and buffer management are

reported in [52] and [53], respectively.

Finding the equilibrium distribution for the individual granularity levels is nontrivial in the

presence of multi-rate traffic. Various approximations have been suggested for single links

with multi-rate traffic, some of which can be modified to apply here. Kaufman [54] and 7 Calculating routing probability for IETF and ITU control plane models are not carried since both control plane models support static routing rather than state-dependent routing.

94

Roberts [55] developed an exact recursion for the multi-rate case when there are no

admission controls. Roberts [56] and Bean [57] give approximations for links with trunk

reservation. Borst and Mitra [153] compare these approaches for virtual partitioning, as well

as considering two-dimensional approximations.

For Liu and Baras in [68], a service request with bandwidth requirement kb for class k is

admitted to a link j with capacity jC if the total consumed resources by all classes k is less

than jC as provided in the equation below:

∑∈

−≤Ki

iijk nbCb ; where in is the number of existing connections of class i.


Since the IETF control plane model routing component has a coarse representation of the M-

granularity transport network as described in section 5.2.1, the IETF routing component

advertises the traffic occupancy of the coarse, e.g., STS-3, granularity level of the transport

link without granular view of the traffic occupancy of the fine, e.g., STS-1, granularity level.

As discussed in section 5.2.1, the Inverse Multiplexing Function (IMF) in the IETF control

plane model is disabled. Hence, IETF control plane model will not consider the service

request granularity level feature, of the service profile, in its CAC mechanism. A service

request with actual bandwidth requirements Akb =2 STS-1 that arrives at a link will consume

Ckb =3 STS-1 resources from the physical link capacity jC . A service request ( A

kb ) will be

accepted if the following condition apply:

∑∈

−≤Kk

kj

Ckj

Ak nbCb …………….. (1)

Where Kjn is the number of “in-progress” class-k calls in the link j. It should be noted that the

IETF CAC mechanism permits a service request based on the coarse bandwidth requirement Ckb of the arriving service request rather than actual bandwidth requirements A

kb . This leads to

95

higher link utilization, under low input loads, due to the mismatch between service request

bandwidth requirements and link’s granularity levels.

8.1.3 ITU and SPA-Dedicated control plane model

Since the ITU control plane model routing component has a granular representation of the

transport network granularity levels as described in section 5.2.2, the ITU routing component

advertises the traffic occupancy of the fine, for example STS-1, granularity level of the

transport link. As discussed in section 5.2.2, the Inverse Multiplexing Function (IMF) in the

ITU control plane model is disabled. Hence, ITU control plane model will not consider the

service request granularity level feature, of the service profile, in its service request routing or

path computation. The service request flow with actual bandwidth requirement Akb =2 STS-1

is not split into multiple flows each with granular bandwidth requirements Gkb =1 STS-1,

instead Akb service request is considered a service request with actual bandwidth

requirement Akb 8. A service request ( A

kb ) will be accepted if the following condition apply:

∑∈

−≤Kk

Djk

Ak

Dj

Ak nbCb …………….. (2)

Where Djkn is the number of “in-progress” class-k calls in the in dedicated resources partition

D. It should be noted that the ITU CAC mechanism permits a service request based on its

actual bandwidth requirement ( Akb ) of the arriving service request rather than coarse

bandwidth requirements ( Ckb ). This leads to lower link utilization due to the match between

service request bandwidth requirements and link’s granularity levels.

8 The reason for that is since the routing and path computation components in the ITU control plane

model have a granular representation of transport network granularity levels. In other words, ITU

routing and path computation components are architected to optimize mapping between the granularity

level of service demands and the available granularity levels of transport network. As a result,

transport network resources will more efficiently utilized than the IETF control plane model due to

match between the granularity level of the service demand and the granularity level of the transport

network.

96

The SPA-Dedicated control plane model has the exact CAC like the ITU control plane model

except utilizing state-dependent routing in its routing component.

8.1.4 SPA-Shared control plane model

The SPA-Shared control plane model differs from both the ITU and SPA-Dedicated control

plane models since it can enable the IMF and further divide the service request flow with

actual bandwidth requirement STSb Ak 2= into multiple flows each with granular service

requests STSbGk 1= . A service request ( A

kb ) will be accepted on the dedicated resources

partition D if the following condition applies:

∑∈

−≤Kk

vDjk

Gk

vDj

Gk nbCb …………….. (3)

A service request ( Akb ) will be accepted on the shared resources partition S if the following

condition applies:

∑∈

−≤Kk

vSjk

Gk

vSj

Gk nbCb …………….. (4)

8.2 Step-2: Calculating link’s reduced load

8.2.1 Base method

Liu and Baras in [68] introduced a method to compute the reduced load on link j due to class

k by each source-destination pair r that passes through link j. Recall that mrjkλ is the reduced

load on link j contributed by traffic class k on route mr and thinned by blocking probability on

other links. It is given by the reduced load approximation as:

∏≠∈

∈=jiri

ikmmrkrkjk

m

mr arjIq,

][λλ …………….. (5)

where I is the indicator function. Note that we first take a portion of the total offered load

rkλ that is routed on mr with probability mrkq , and then multiple it with the probability that this

97

portion is admitted by all links other than link j. The aggregated load of class k on link j from

the load generated at all the source-destination pairs r is:

∑ ∑∈ ∈

=Rr Mr

jkjkrm

mrλλ …………….. (6)


In the IETF control plane model, the total offered load vrkλ for each configured VPN service v

is applied to link j, this indicated the Complete Sharing (CS) concept introduced above.

Equation (5) can be modified by replacing rkλ by vrkλ as shown in equation (7), equation (6)

used to compute the aggregate, reduced, load due to all source-destination pair r remains the

same.

∏≠∈

∈=jiri

ikmmrk

vrkjk

m

mr arjIq,

][λλ …………….. (7)

8.2.3 ITU and SPA-Dedicated control plane models

In the ITU control plane model, the total offered load vrkλ for each configured VPN service v

is applied to its dedicated resources partition D; this indicated the Complete Partitioning (CP)

concept introduced above. In the ITU control plane model, the reduced load is computed for

each network resources partition D as shown in equation (8)

∏≠∈

∈=jiri

Dikm

mDrk

Drk

Djk

m

rm arjIq,

][λλ …………….. (8)

The aggregated load of class k on network resources partition D for link j from the load

generated at all the source-destination pairs r is:

∑ ∑∈ ∈

=Rr Mr

Djk

Djk

rm

mrλλ …………….. (8)

8.2.4 SPA-Shared with static load partitioning (without NE)

Traffic partitioning without Network Engineering “w/oNE” is when the Load Partitioning

Function (LPF) is configured to partition the configured VPN service v total arrival

98

load vrkλ between the dedicated resources vD

jC and the shared resources SjC based on the

resources ratios between dedicated and shared resources partitions9 as given below:

Sj

vDj

vDjv

rkvDrk CC

C+

= .λλ …………….. (9)

Sj

vDj

vSjv

rkvSrk CC

C+

= .λλ …………….. (10)

The dedicated load vDrkλ from configured VPN service-v is then used to generate per-link j

load as given below based on the dedicated resources routing and admissibility probabilities

∏≠∈

∈=jimri

Dikm

mDrk

vDrk

mrDjk arjIq

,][λλ …………….. (11)


generated at all the source-destination pairs is the same as equation (8). Each of the

configured VPN services-v apply their shared load vSrkλ on the shared resources S; thus the

total shared load from all configured VPN services on the shared resources partition is the

sum of all the shared loads as given below:

∑∀

=v

vSrk

Srk λλ~ …………….. (12)

The total shared load Srkλ~ is then used to generate per-link j load as given below based on the

shared resources routing and admissibility probabilities

∏≠∈

∈=jiri

Sikm

Smrk

Srk

Sjk

m

mr arjIq,

][~λλ …………….. (13)

The aggregated load of class k on network shared resources partition S for link j from the load

generated at all the source-destination pairs r is provided in equation (14).

∑ ∑∈ ∈

=Rr Mr

Sjk

Sjk

rm

mrλλ …………….. (14)

9 This partitioning configuration is considered Static Splitting (SS). Other load partitioning configuration is considered when LPF is configured as Network Engineering (NE) to perform dynamic load partitioning

99

8.2.5 SPA-Shared with dynamic load partitioning (with NE)

Traffic partitioning with Network Engineering “w/NE” is when the Load Partitioning

Function (LPF) is configured to partition the configured VPN service v total arrival load vrkλ

between the dedicated resources vDjC and the shared resources S

jC based on the dedicated

resources pair blocking probability vDrkB . FPA is carried in two rounds on the dedicated

resources partitions and one round on the shared resources partition. In round-1, the

configured VPN service-v total arrival load vrkλ is applied to the dedicate resource partition

vDjC as given below:

∏≠∈

∈=jimri

Dikm

mDrk

vrk

mrDjk

NE arjIq,

][λλ …………….. (14)


generated at all the source-destination pairs r is the same as equation (8) but with replacing

Djkλ and mrD

jkλ by Djk

NEλ and mrDjk

NEλ respectively. When round-1 of the FPA on dedicated

resources partitions is complete, the pair blocking probability vDrkB is used to generate the

configured VPN service-v shared load vSrk

NEλ which is the configured VPN service v total load

multiplied by the dedicated resources partition blocking probability. vDrk

vrk

vSrk

NE B.λλ = …………….. (15)

The blocking probability vDrkB is the complement of the admissibility probability of a class k

service request between node pair r for dedicated network resources partition D of configured

VPN service- v. for a source-destination pair r. The pair admissibility probability is the sum

of the admissibility probability of each route mrm∈ multiplied by the routing probability mrkq .

The route admissibility probability is the product of the admissibility probability of all the

links mrj∈ .

∑ ∏∈

−=m mrj

vDjk

mDrk

vDrk aqB 1 …………….. (16)

100

The reduced load on the shared resources is computed using the same equations as provided

in (12-14) but with replacing the terms Srkλ~ , mrS

jkλ , and Sjkλ by the terms S

jkNEλ , mrS

jkNEλ , and

Srk

NEλ~ respectively. In round-2, the non-blocked load from round-1 is applied again to each

dedicate resource partition vDjC as given in equation (17) below:

)1.( Drk

vrk

vDrk

NE B−= λλ …………….. (17)

The reduced load on the dedicated resources partition D is computed using the same equation

as provided in (14)

8.3 Step-3: Calculating link’s occupancy probability and admissibility

probability

8.3.1 Base method

In [69] Kaufman gave a simple one-dimensional recursion for calculating the link’s

occupancy probabilities.

∑ −=K

kjk

jkkj bnpbnnp )()(μλ

…………….. (18)

The total number of in-progress calls in link j is the sum of weighted sum of all the in-

progress classes from all classes ∑∈∈

=jkk CnKb

kCk nbn

,

. Note that 0)( =np j if 0<n

and 1)(0

=∑ =

jC

n j np . The link’s admissibility probability of link j for class k is the sum of the

occupancy probability of all the states from ],0[ kj bCn −∈ as given in equation (20) below:

∑ −

== kj bC

n jjk npa0

)( …………….. (20)


In the IETF control plane model, the link’s occupancy probability )(np j is based on the

coarse bandwidth requirement Ckb of class k rather than the actual bandwidth requirement

Akb of class k. The link’s occupancy probability in given in equation (21)

101

∑ −=K

Ckj

k

jkCkj bnpbnnp )()(μλ

…………….. (21)

The link’s admissibility probability of link j for class k is given in equation (22) below:

∑ −

==

Ckj bC

n jjk npa0

)( …………….. (22)

It should be observed that the IETF link’s occupancy and admissibility probabilities are

calculated based on the coarse bandwidth requirements Ckb of class k. This is compliant with

the IETF CAC mechanism described in section 8.1.2. Another enforcement of IETF–CAC is

the total number of in-progress calls n ; which is based on class k coarse demand Ckb .

8.3.3 ITU and SPA-Dedicated control plane model

Similar to the link’s reduced load where the reduced load is computed for each network

resources partition D; in the link admissibility probability, each network resources partition D

has its separate occupancy probability )(np Dj and admissibility probability D

jka .

∑ −=K

Ak

Dj

k

DjkA

kDj bnpbnnp )()(

μλ

…………….. (23)

The link’s admissibility probability of link j for class k is given in equation (24) below:

∑ −

==

Ak

Dj bC

nDj

Djk npa

0)( …………….. (24)

It should be observed that the ITU link’s occupancy and admissibility probabilities are

calculated based on the actual bandwidth requirements Akb of class k. This is compliant with

the ITU CAC mechanism described in sections 8.1.1, 8.3.3, and 8.1.3 respectively. Another

enforcement of ITU–CAC is the total number of in-progress calls Dn in network resources

partition D; which is based on class k actual demand Akb . The link’s admissibility probability

for a class k is the weighted average of Djka multiplied by D

jC as indicated in equation (25).

j

D

Dj

Djk

jk C

Caa

∑∀=

*…………….. (25)

102

8.3.4 SPA-Shared- Static load partitioning and disabled inverse multiplexing (without

NE, without IM)

This case is when the Load Partitioning Function (LPF) is configured to static load sharing

“without Network Engineering” and the Inverse Multiplexing Function (IMF) is configured

to “disabled”. The dedicated load vDjkλ and shared load vS

jkλ from configured VPN service-v is

the load computed in section 8.2.4. Since IMF is disabled, no inverse multiplexing of the

service request flow with actual bandwidth requirement Akb into multiple flows each with

granular bandwidth requirement Gkb is performed. Thus, it should be observed that the link’s

occupancy probability )(npvDj and )(np S

j is based on the actual bandwidth requirement Akb of

class k rather than the granular bandwidth requirement Gkb of class k as given in equations

(26, 27).

∑ −=K

Ak

vDj

k

vDjkA

kvDj bnpbnnp )()(

μλ

…………….. (26)

∑ −=K

Ak

Sj

k

SjkA

kSj bnpbnnp )()(

μλ

…………….. (27)

The admissibility probability at the dedicated resources partitions D and shared resources

partition S is given in equations (28) and (29) respectively.

∑−

=

=

AkbvD

jC

n

vDj

vDjk npa

0)( …………….. (28)

∑−

=

=Ak

Sj bC

n

Sj

Sjk npa

0)( …………….. (29)

The configured VPN service-v link’s admissibility probability for a class k is the weighted

average of vDjka and S

jka multiplied by vDjC and S

jC respectively as indicated below:

Sj

vDj

Sj

Sjk

vDj

vDjkv

jk CCCaCa

a+

+=

..…………….. (30)

The physical resources link’s admissibility probability for a class k is the weighted average of

all vDjka and S

jka multiplied by vDjC and S

jC respectively as indicated below:

103

j

Sj

Sjk

D

vDj

vDjk

jk C

CaCaa

.).( +=∑∀ …………….. (31)

8.3.5 SPA-Shared- Dynamic load partitioning and disabled inverse multiplexing (with

NE, without IM)

This case is when the Load Partitioning Function (LPF) is configured to dynamic load

sharing “with Network Engineering” and the Inverse Multiplexing Function (IMF) is

configured to “disabled”. The dedicated load vDjkλ and shared load S

jkλ from configured VPN

service-v is the load computed in section 8.2.5. Since IMF is disabled, no inverse

multiplexing of the service request flow with actual bandwidth requirement Akb into multiple

flows each with granular bandwidth requirement Gkb is performed. Equations (26-31) are used

but while using dedicated load vDjkλ and shared load S

jkλ from configured VPN service-v as

computed in section 8.2.5.

8.3.6 SPA-Shared- Static load partitioning and enabled inverse multiplexing (without

NE, with IM)

This case is when the Load Partitioning Function (LPF) is configured to static load sharing

“without Network Engineering” and the Inverse Multiplexing Function (IMF) is configured

to “enabled”. The dedicated load vDjkλ and shared load S

jkλ from configured VPN service-v is

the load computed in section 8.2.4. Since IMF is enabled, inverse multiplexing of the service

request flow with actual bandwidth requirement Akb into multiple flows each with granular

bandwidth requirement Gkb is performed. Thus, it should be observed that the link’s

occupancy probability )(npvDj and )(np S

j is based on the granular bandwidth

requirement Gkb of class k rather than the actual bandwidth requirement A

kb of class k as given

in equations (26, 27). Also, it should be observed that an additional term (i) is multiplied by

the Erlang load k

vDjkG

kbμλ

to maintain the same Erlang load before and after inverse

multiplexing operation where Gk

Ak ibb = .

104

∑ −=K

Gk

vDj

k

vDjkG

kvDj bnp

ibnnp )()(

μλ

…………….. (32)

∑ −=K

Gk

Sj

k

SjkG

kSj bnp

ibnnp )()(

μλ

…………….. (33)

The admissibility probability at the dedicated resources partitions D and shared resources

partition S is the same like equations (28) and (29) respectively but with replacing Akb by G

kb .

8.3.7 SPA-Shared- Dynamic load partitioning and enabled inverse multiplexing (with

NE, with IM)

This case is when the Load Partitioning Function (LPF) is configured to dynamic load

partitioning “with Network Engineering” and the Inverse Multiplexing Function (IMF) is

configured to “enabled”. The dedicated load vDjkλ and shared load S

jkλ from configured VPN

service-v is the load computed in section 8.2.5. Since IMF is enabled, inverse multiplexing of

the service request flow with actual bandwidth requirement Akb into multiple flows each with

granular bandwidth requirement Gkb is performed. Equations (26-31) are used but while using

dedicated load vDjkλ and shared load S

jkλ as computed in section 8.2.5 and with replacing Akb

by Gkb .

8.4 Step-4: Calculating routing probability for each possible route

8.4.1 Base method

Liu and Baras in [68] introduced a mathematical model to compute the routing probability

based on the occupancy probability computed in step-3. The following equations describe the

mathematical equations used by the FPA routing component to calculate the routing

probability mDrkq

∏∑∈

−

=

=)( 0

)()](Pr[m

Dj

rj

nC

k

Djm

Dn kPrA …………….. (34)

∏ ∑∈

+−

=+ =

)(

1

01 )()](Pr[

m

Dj

rj

nC

k

Djm

Dn kPrA …………….. (35)

105

∏ ∑−∈

−

=

=−)( 0

)()](Pr[mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (36)

∏ ∑−∈

−

=

−=−)( 0

)(1)](Pr[mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (37)

∏ ∑−∈

+−

=+ =−

)(

1

01 )()](Pr[

mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (38)

∏ ∑−∈

+−

=+ −=−

)(

1

01 )(1)](Pr[

mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (39)

)](Pr[)](Pr[)](~Pr[ 1 mDnm

Dnm

Dn rArArA +−= …………….. (40)

The routing probability mDrkq that a service request of class k is routed on route mr is the

probability that all routes prior to the mth route on the ascending ordered route list

)](Pr[1

1mk

Dn

mk

k

rrA −∏−=

=

, based on number of hops between source-destination pair r, have less

free bandwidth, and that all routes following the mth route in the same list

)](Pr[ 11

mkD

n

Mk

mk

rrAr

−+

=

+=∏ have at most the same amount of free bandwidth. It should be observed

that the summation upper bound is )(min mrC to prevent the second probability to be zero when

n is bigger than )(min mrC

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq …………….. (41)


The IETF control plane model does not implement state-dependent routing as indicated in

sections 6.1 and 7.2.1; thus the routing probability mDrkq is static and does not depend on the

occupancy state of the network topology links. The routing probability is configured

manually to be either Direct Routing (DR) or Split Routing (SR).

106


Similar to the IETF control plane model, the ITU control plane model does not implement

state-dependent routing; thus the routing probability mDrkq is static and does not depend on the

occupancy state of the network topology links. For each network resources partition D, the

routing probability is configured manually to be either Direct Routing (DR) or Split Routing

(SR).

8.4.4 SPA-Dedicated control plane model

As described in sections 6.3 and 7.2.3, the SPA-Dedicated control plane model supports state-

dependent routing. A state-dependent routing capability by the control plane routing

component indicates that the routing probability mDrkq is computed based on the occupancy

state of all the links belonging to route mr , this was indicated in Figure 7-5 where the routing

probability mDrkq is computed based on the occupancy probability )(np D

j for each FPA

iteration. Equations (34-41) are used to compute the routing probability mDrkq .


As described in sections 6.3 and 7.2.3, the SPA-Shared control plane model supports state-

dependent routing on both the dedicated and shared resources partitions, this was indicated in

Figure 7-6 where the routing probabilities for the dedicated resources partition mvDrkq and the

shared resources partition mSrkq is computed based on the occupancy probability )(np D

j and

)(np Sj respectively for each FPA iteration. Equations (42,43) describe the final mathematical

equation used by the FPA routing component to calculate the routing probability mvDrkq and

mSrkq .

∑ ∏∏=

+

=

+=

−=

=

−−=)(min

01

1

1

1)](~Pr[)].(Pr[)].(Pr[

mrC

nm

vDnmk

vDn

rMk

mkmk

vDn

mk

k

mvDrk rArrArrAq …………….. (42)

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Snmk

Sn

Mk

mkmk

Sn

mk

k

mSrk rArrArrAq …………….. (43)

107

8.5 Step-5: Compute network-wide blocking probability

8.5.1 Base Methods

Based on the assumption carried by Liu and Baras in [68] to compute the route blocking

probability, the pair r blocking probability for class k is:

∑ ∏∈

−=m rj

jkmrkrk

m

aqB 1 …………….. (44)

Where 1=∑m

mrkq . If the service request cannot be admitted, it is considered blocked.


Since the IETF control plane model implements the Complete Sharing (CS) concept, the

blocking probability is computed on the physical resources capacity level only; thus the

blocking probability rkB depends on the physical link admissibility probably jka and routing

probability mrkq . The IETF control plane model uses equation (44). The network-wide

blocking probability kB for class k is the average of the per-pair r blocking probability

for Rr∈ as provided in equation (45)

][ rkRrk BAVRB∈

= …………….. (45) ; where AVR is the average function


Since the ITU and SPA-Dedicated control plane models implements the Complete

Partitioning (CP) concept, the blocking probability is computed on each dedicated resources

partition. Similar to the link’s reduced load, occupancy probability, and admissibility

probability where the reduced load is computed for each network resources partition D; the

pair blocking probability on the dedicated network resources partition D for class k is

provided in equation (46).

∑ ∏∈

−=m rj

Djk

Dmrk

Drk

m

aqB 1 …………….. (46)

The network-wide blocking probability DkB on dedicated resources partition D for class k is

the average of the per-pair r blocking probability for Rr∈ as provided in equation (47)

108

][ DrkRr

Dk BAVRB

∈= …………….. (47)

The pair r blocking probability from a link perspective is the weighted average of DrkB

multiplied by DjC . The network-wide blocking probability kB for class k is the average of the

pair r blocking probability for Rr∈

j

D

Dj

Drk

rk C

CBB

∑∀=

*…………….. (48)

][ rkRrk BAVRB∈

= …………….. (49)

8.5.4 SPA-Shared control plane models

Since the SPA-Shared control plane model implements the Virtual Partitioning (VP) concept,

the blocking probability is computed on each dedicated resources partition D and the shared

resources partition S. The pair r blocking probability on the dedicated network resources

partition D for class k is provided in equation (46). The pair blocking probability on the

shared network resources partition S for class k is provided in equation (50).

∑ ∏∈

−=m mrj

Sjk

mSrk

Srk aqB 1 …………….. (50)

The pair r blocking probability from a VPN resources partition, dedicated and shared

resources for a configured VPN service v, perspective is the weighted average of DrkB multiplied by D

jC and SrkB multiplied by S

jC , and the network-wide blocking

probability vkB for class k is the average of the pair r blocking probability for Rr∈

Sj

Dj

Sj

Srk

Dj

Drkv

rk CCCBCB

B+

+=

** …………….. (51)

][ vrkRr

vk BAVRB

∈= …………….. (52)

The pair r blocking probability from a link perspective is the weighted average of DrkB multiplied by D

jC for all dedicated resources and SrkB multiplied by S

jC , and the network-

wide blocking probability kB for class k is the average of the pair r blocking probability

for Rr ∈ as:

109

j

Sj

Srk

D

Dj

Drk

rk C

CBCBB

*)*( +=∑∀ …………….. (53)

][ rkRrk BAVRB∈

= …………….. (54)

8.6 Step-6: Compute network-wide average permissible load



permissible load kλ̂ is computed on the physical resources only. The pair r permissible load is

the sum of the permissible load on each route mrm∈ . Each route m permissible load is the

minimum permissible load on all the links mrj∈ multiplied by the routing probability mrkq on

route mr , and the network-wide average permissible load kλ̂ is the average of the per-pair

permissible load rkλ̂ for Rr∈∀ as:

)(ˆ1

jk

M

m rj

mrkrk

r

m

MINq λλ ∑=

∈= …………….. (55)

]ˆ[ˆrkRrk Avr λλ

∈= …………….. (56)



Partitioning (CP) concept, the permissible load is computed on both the dedicated resources

partitions and the physical resources levels. As provided in equation (58), the network-wide

average permissible load Dkλ̂ on the dedicated resource partition D is the average of the per-

pair permissible load Drkλ̂ for Rr∈∀ .

)(ˆ1

Djk

M

m rj

mDrk

Drk

r

m

MINq λλ ∑=

∈= …………….. (57)

]ˆ[ˆ DrkRr

Dk Avr λλ

∈= …………….. (58)

110

The per-pair r permissible load for class k from a link perspective is the weighted average of Drkλ̂ multiplied by D

jC as:

j

D

Dj

Drk

rk C

C )*ˆ(ˆ

∑∀=

λλ …………….. (59)



the permissible load is computed on the dedicated resources partitions, shared resources

partition, VPN partition, and the physical resources levels. The permissible load on the

dedicated resources partition is computed using equations (57-58).The network-wide average

permissible load on the shared resources Skλ̂ is computed in a similar manner to the dedicated

resources partition as:.

)(ˆ1

Sjk

rM

m mrj

mSrk

Srk MINq λλ ∑

= ∈= …………….. (60)

]ˆ[ˆ SrkRr

Sk Avr λλ

∈= …………….. (61)

The pair r permissible load for class k from a VPN perspective is the weighted average of Drkλ̂

multiplied by DjC and S

rkλ̂ multiplied by SjC .

Sj

Dj

Sj

Srk

Dj

Drkv

rk CCCC

+

+=

*ˆ*ˆˆ λλλ …………….. (62)

The pair r permissible load for class k from a link perspective is the weighted average of Drkλ̂

multiplied by DjC and the S

rkλ̂ multiplied by SjC .

j

Sj

Srk

D

Dj

Drk

rk C

CC *ˆ)*ˆ(ˆ

λλλ

+=∑∀ …………….. (63)

111

8.7 Step-7: Compute network-wide utilization



link’s utilization is computed on the physical resources only. As provided in equation (64),

the per link’s utilization is the sum of the link j occupancy probability )(np j where 0>n .

j

jC

nj

j C

nnpU

∑== 0

)(…………….. (64)

The network-wide utilizationU is the average of the per link’s utilization.

][ jJjUAvrU

∈= …………….. (65)



Partitioning (CP) concept, the utilization is computed on both the dedicated resources

partition and the physical resources levels. The per link’s utilization on a dedicated network

resource partition D

Dj

DjC

n

Dj

Dj C

nnpU

∑== 0

)(…………….. (66)

The link’s utilization is the weighted average of DjU multiplied by D

jC

j

D

Dj

Dj

j C

CUU

)*(∑∀= …………….. (67)

The network-wide utilization U is provided in equation (65)



the utilization is computed on the dedicated resources partitions, shared resources partition,

112

VPN partition, and the physical resources levels. The utilization on the dedicated resources

partition is computed using equations (66-67). The network-wide average utilization on the

shared resources is computed in a similar manner to the dedicated resources partition as:

Sj

SjC

n

Sj

Sj C

nnpU

∑== 0

)( …………….. (68)

The utilization vjU on the VPN resources partition v level, dedicated and shared resources, is

the weighted average of DjU multiplied by D

jC and SjU multiplied by S

jC as:

Sj

Dj

Sj

Sj

Dj

Djv

j CCCUCU

U+

+=

**…………….. (69)

The link’s utilization is the weighted average of DjU multiplied by D

jC for all dedicated

resources and SjU multiplied by S

jC as:

j

Sj

Sj

D

Dj

Dj

j C

CUCUU

*)*( +=∑∀ …………….. (70)

The network-wide utilization U is provided in equation (65)

9 Scenarios and Performance Evaluation

This section describes the specific scenarios used to study the performance of the IETF, ITU,

and SPA control plane models. This section also provides detailed view of the network

topologies analyzed, modeling environment, performance metrics, and parameters settings for

both the control plane models and the configured VPN service models.

9.1 Network topology analyzed

Two topologies were used to compare the performance of the IETF, ITU, and SPA control

plane models, a 4-node topology as illustrated in Figure 9-1 and 7-node topology as

illustrated in Figure 9-3. The 4-node topology was used as a modelling prototype to ensure

that the control plane components and their associated functionalities are performed

according to the mathematical models as expected. The 7-node topology was used to study

113

the relative performance of the IETF, ITU, SPA control plane models. The following

transport network parameters are considered in the modeling analysis:

1. The physical resources capacity jC of each link j is 24 STS-1

2. In the IETF control plane model, service requests from different configured VPN service

models are applied “multiplexed” to the 24 STS-1.

3. In the ITU control plane model, the 24 STS-1 are divided into two network resources

partition DjC , each with 12 STS-1 resources.

4. The SPA-Dedicated control plane model uses the same transport network configuration

like the ITU control plane model.

5. The SPA-Shared control plane model partitions the 24 STS-1 into three network

resources partitions; two dedicated resources partitions vDjC and one shared resources

partition SjC . Four sharing levels are considered as follows:

a. STS-1 sharing: vDjC =11 STS-1, S

jC =2 STS-1

b. STS-2 sharing: vDjC =10 STS-1, S

jC =4 STS-1

c. STS-3 sharing: vDjC =9 STS-1, S

jC =6 STS-1

d. STS-4 sharing: vDjC =8 STS-1, S

jC =8 STS-1

Figure 9-1: Modeled ITU, SPA-Dedicated Network Partitions Compared to IETF Physical

Resources “4-node topology”

Physical resources in:IETF Control Plane Model

Network resources partitions in:ITU ,SPA-Dedicated

DedicatedResource-1

DedicatedResource-2

n=1 n=2

n=3n=1

n=1 n=2

n=3n=1

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

j=1

j=2

j=3

j=4

j=1

j=2

j=3

j=4

124 −= STSC j

112 −= STSC vDj

112 −= STSC vDj


Network resources partitions in:ITU ,SPA-Dedicated

DedicatedResource-1

DedicatedResource-2

n=1 n=2

n=3n=1

n=1 n=2

n=3n=1

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

j=1

j=2

j=3

j=4

j=1

j=2

j=3

j=4

124 −= STSC j

112 −= STSC vDj

112 −= STSC vDj

114

Figure 9-2: Modeled SPA-Shared Network Partitions Compared to IETF Physical Resources

“4-node topology”- 1STS-1 Sharing Scenario

Figure 9-3: Modeled ITU, SPA-Dedicated Network Partitions Compared to IETF Physical

Resources “7-node topology”


Network resources partitions in:SPA-Shared

Resource Resource SharingSharing


DedicatedResource-1

SharedResources

DedicatedResource-2

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

124 −= STSC j

111 −= STSC vDj

111 −= STSC vDj

12 −= STSC Sj


Network resources partitions in:SPA-Shared



DedicatedResource-1

SharedResources

DedicatedResource-2

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

n=1 n=2

n=3n=1

j=1

j=2

j=3

j=4

124 −= STSC j

111 −= STSC vDj

111 −= STSC vDj

12 −= STSC Sj

DedicatedResource-1

DedicatedResources-2

Physical resources in:IETF Control Plane

Model

Network resources partitions in: ITU ,SPA-Dedicated

112 −= STSC vDj

112 −= STSC vDj

124 −= STSC j

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

DedicatedResource-1

DedicatedResources-2


Model

Network resources partitions in: ITU ,SPA-Dedicated

112 −= STSC vDj

112 −= STSC vDj

124 −= STSC j

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

115


“7-node topology”- 1 STS-1 Sharing Scenario

Figure 9-5 provides a numerical example of the FPA parameters for the 4-node topology. For

the 4-node topology, the following parameters are specified:

1. N=4 for the 4-node topology

2. J=4 for the four links of the 4-node topology

3. 3=rM to indicate that each source node is connected to three destination node.

4. mr is a matrix that lists the possible source-destination pairs.

5. 24=jC , Jj∈∀ to indicate the physical resources capacity for all links to be 24 STS-1

In addition to the network topology parameters, additional parameters are specified for the

configured VPN service model analyzed as follows:

1. 2=k to indicate a service request with actual bandwidth requirement Akb =2 STS-1.

2. ]3010[ Erlangmm rjk

rjk >−== λλ to indicate an input load ranging from [10-30] Erlangs.

3. 1=kμ to indicate an average service duration time to be 1 with exponential service time.

Network resources partitions in: SPA-Shared

DedicatedResource-1

SharedResources

DedicatedResource-2



Model


124 −= STSC j 12 −= STSC Sj

111 −= STSC vDj

111 −= STSC vDj

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

Network resources partitions in: SPA-Shared

DedicatedResource-1

SharedResources

DedicatedResource-2



Model



111 −= STSC vDj

111 −= STSC vDj

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

DedicatedResource-1

SharedResources

DedicatedResource-2



Model



111 −= STSC vDj

111 −= STSC vDj

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

j=1 j=2 j=3

j=4

j=5j=6

j=7 j=8 j=9

n=1n=2 n=3 n=4

n=5n=6n=7

116


“7-node topology”- 1 STS-1 Sharing Scenario

9.2 Modeling parameters

This section provides details on the modelling parameters used for the input loads, control

plane components configuration options, and configured VPN service models.

9.2.1 Parameters specifics of input load

This section provides details on the modelling parameters used for the input load. One input

class was evaluated with the following parameters: 2=k , =Akb 2 STS-1, 1=kμ unit time,

4=rkλ calls/unit time. Range of input load for 4-node topology is 10 to 30 Erlangs. Range

of input load for 7-node topology is 30 to 70 Erlangs.

9.2.2 Parameters specifics of control plane components

The following components parameters in the three control plane models are used to evaluate

the control plane performance under different traffic management schemes:

Service Arrivals

2

∑ ∏∈

−=m mrj



Topology Parameters

1]24,24,24,24,24,24[}]4,3{},4,2{},3,2{},4,1{},3,1{},2,1{[

]3,3,3,3,3,3[6

]4,3,2,1[]4,3,2,1[

654321

654321

654321

==============

========

==========

CCCCCCCrrrrrrr

MMMMMMMR

jjjjJnnnnN

j

m

r

)(np j



Probabilities

jkamrkq


Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

jkλ

)(np j



Probabilities

jkamrkq


Estimating Routing

Probabilities

In th

e ca

se o

f Sta

te-

Dep

ende

nt R

outin

g

jkλ

]1[

]3010[

]12[]2[

1 ==

>−==

−===

μμ

λλ

k

rjk

rjk

k

Erlang

STSbKK

mm

117

1. Control Plane Instance (CPI) Selection: CPI is used to allow the partitioning of the

incoming load into transport resources partitions based on the configured VPN service

identified number parameter from the service configuration profile layer

2. Routing Computation components: Two parameters are specified:

1.1. Routing probability: In static routing, the routing probability is configured to Direct

Routing (DR) or Split Routing (SR) independent of the network links occupancy

probability. In state-dependent routing, the FPA mechanism is used to provide the

routing component with the link’s traffic occupancy probability for all the network

topology links within each network resources partition. The links occupancy

probabilities are used to compute the state-dependent routing probabilities.

1.2. Routing granularity level: The routing component can be set to build routing tables

based on transport network coarse granularity level or fine granularity level. The

coarse granularity level is set to be STS-3; the fine granularity level is set to be STS-

1.

2. Load Partitioning Function (LPF): Allows the load partitioning of the arriving service

requests between dedicated and shared network resources partitions. Two configuration

options are available:

2.1. Static Partitioning “without network engineering w/o(NE)”: In this configuration

scenario, LPF is configured to statically partition the configured VPN service

arriving load between the dedicated and shared resources based on the resource

ratios between dedicated and shared resources

2.2. Dynamic Partitioning “with network engineering w/(NE)”: In this configuration

scenario, LPF is configured to dynamically partition the configured VPN service

arriving load between the dedicated and shared resources based on the blocking

probability on the dedicated resources partition.

3. Inverse Multiplexing Function (IMF): Allows inverse multiplexing of the arriving service

requests flow with actual bandwidth Akb into multiple flows each with granular

bandwidth requirement Gkb . Two configuration options are available:

3.1. Without Inverse Multiplexing “w/o(IM)”: IMF is disabled

118

3.2. With Inverse Multiplexing “w/(IM)”: IMF is enabled.

Table 9-1 illustrates the control plane components configuration for the IETF, ITU, and SPA

control plane models, the tick symbol indicate that this configuration option is enabled for the

corresponding control plane model. For example, the tick symbol for the static routing

probability in both the IETF and ITU control plane models indicated that the routing

probability is configured statically.

9.2.3 Parameters specifics of configured VPN service models considered

The service configuration profile layer parameters are configured as follows:

1. Configured VPN service identification number parameter is configured to enabled mode

indicating that the incoming service requests are labelled with different VPN service

identification numbers to differentiate service arrivals ownerships

2. Service demand granularity parameter is configured as 1-STS-1 granular

3. Service flow connectivity parameter is configured as fully-meshed.

9.3 Performance metrics

A key objective is to compute the following performance metrics:

1. Average network-wide blocking probability kB : the network-wide average probability

over all network links that service requests of class k is denied access to network

resources; 3.0=kB indicates that 30% of the service arrival of class K, on a network-

wide basis, is blocked and denied access to network resources.

2. Average per source-destination pair r permissible “non-blocked” load rkλ̂ : the average

offered load over all network links that service requests of class k is allowed.

3. Average network-wide resource utilizationU : the network-wide average traffic

occupancy percentage over all network’ links; %50=U for a network with 24 STS-1

capacity for each link indicates that, on a network-wide average, 12 STS-1 per link are

occupied with service request traffic.

119

Table 9-2 lists the performance metrics computed for each control plane model with their

relevant mathematical formulation provided in section 8, the numbers in parenthesis indicate

the mathematical formulas’ number provided in section 8. As illustrated in Table 9-2, since

the IETF control plane model supports the Complete Sharing (CS) concept, the IETF control

plane model computes the above performance metrics on the link (L) resources level only.

Since both the ITU and SPA-Dedicated control plane models support the Complete

Partitioning (CP) concept, the ITU and SPA-Dedicated control plane models compute the

above performance metrics on the dedicated resources partition (D) and link (L) levels. Since

the SPA-Shared control plane model supports the Virtual Partitioning (VP) concept, the SPA-

Shared computes the above performance metrics on the dedicated resources partitions (D),

shared resources partition (S), VPN resources partition (V), and link (L) levels.

120

Routing Probability Routing Granularity

Load Partitioning Function (LPF) enabled

Inverse Multiplexing Function (IMF) enabled

Component Configuration

Static State- Dependent

Coarse Granular

Control Plane Instance (CPI) Selection w/oNE w/NE w/oIM w/IM

IETF ITU SPA-Dedicated SPA-w/o(NE,IM) SPA-w/NE,w/oIM SPA-w/oNE,w/IM SPA-w/(NE,IM)

Table 9-1: Control Planes Components Configuration Options

121

Performance

Metric

Blocking

probability

Permissible

load Utilization

Network Partition Level D S V L D S V L D S V L

IETF Relevant Equations

(44-45) (55-56) (64-65)

ITU Relevant Equations

(46-47) (48-49) (57-58) (59) (66) (67)

SPA-Dedicated

Relevant Equations (46-47) (48-49) (57-58) (59) (66) (67)

SPA-Shared

Relevant Equations (46-47) (50) (51-52) (53-54) (57-58) (60-61) (62) (63) (66) (68) (69) (70)

Table 9-2: Performance Metrics for the Three Control Plane Models

122

9.4 Modeling environment

The numerical evaluation of the analytical models was implemented in a combination of

MathematicaTM, Microsoft ExcelTM, and Visual BasicTM. As illustrated in Figure 9-5, multiple

Excel spreadsheets were used to compute both the reduced load approximation vDjkλ for each

link j and class k within each network resources partition D, and the routing probability mDrkq

for each route m for source-destination pair r and class k. MathematicaTM was used to

compute the occupancy probability )(np j for each link j in the network topology. Visual

BasicTM was used to program the Fixed Point Approximation module used to compute the

blocking probability DrkB for each pair r, class k within network resources partition D, and the

permissible load Dkλ̂ for each class k within network resources partition D. It is important to

mention the scaling issues faced with both MathematicaTM and ExcelTM. MathematicaTM was

not able compute the occupancy probability when the number of resources (n) within a

resources partition is greater than 12 and the applied classes (k) are greater than 2. When

n=12 and k=2, the occupancy probability )(np j output equations provided by MathematicaTM

were 120 pages in length. Multiple recursive substitutions were carried to shorten the

MathematicaTM output equations to be able to fit the Visual BasicTM arrays limited length.

123

Figure 9-6: Modeling Environment

Occupancy Probability Computation

Occupancy Probability

Reduced Load Computation

Visual BasicTM for FPA

Routing Probability Computation

MathematicaTM

Code

124

10 Computational Cost of the Traffic Management Schemes

This section provides details on the computation cost of the traffic management schemes for

the three control plane models; the computation cost is analyzed from both FPA and

implementation perspectives.

10.1 Computed cost of FPA

This section provides details on the computation cost for the three control plane models based

on the FPA steps for both the base model and different traffic management schemes for the

three control plane models. The computation cost of the FPA depends on the iterations

required to compute the set of unknowns, the following discussion covers the computational

cost for each iteration of the FPA.

10.1.1 Base model

The first computation step involves O(J . K) operations of (2) where J is the number of links

and K is the number of service request classes, each of which has O(R . M) operations of (1),

where R is the number of node pairs and M is the average number of routes each node pair

has. The cost of (1) is also linear in the average length in hops of a route, denoted by H.

∏≠∈

∈=jiri

ikmmrkrkjk

m

mr arjIq,

][λλ …………….. (1)

∑ ∑∈ ∈

=Rr Mr

jkjkrm

mrλλ …………….. (2)

The second computation step as provided in (3) involves operations of either the Kaufman

recursion [69] or the one-dimensional approximation by Gibbens and Zachary [72,73], they

both have a cost of O(C . K) where C is the physical link capacity.

∑ −=K

kjk

jkkj bnpbnnp )()(μλ

…………….. (3)

The third computation step to compute a single mDrkq as provided in (5) involves O(R . M)

operations. The cost of a single mDrkq is based on the cost of evaluating )( mn rA as provided in

125

(4), the cost of evaluating )( mn rA for a route mr involves O(H) operations (multiplications). As

provided in (5), each route on the route list is evaluated for every value Cn∈ , which gives

O(M .C) such operations. This results in a total computation cost of O(M . C . H) operations

for each pair r and O(R . M . C . H) operations for all source-destination pairs.

∏∑∈

−

=

=)( 0

)()](Pr[m

Dj

rj

nC

k

Djm

Dn kPrA …………….. (4)

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq ……………..(5)


Since the IETF control plane model does not support state-dependent routing but rather fixed

routing, the IETF control plane model has the same exact computation cost as the base model

for the first two computations steps, the base model third computation step is not considered

in the IETF control plane model as the routing probability for any route is assigned rather

than computed.


Similar to the IETF control plane model, the ITU control plane model does not support state-

dependent routing but rather fixed routing. Hence, the ITU control plane model has the same

computation cost as the IETF control plane model for each control plane instance. As

provided earlier, the ITU control plane model supports the Complete Partitioning (CP)

concept and hence there is a FPA instance for each network partition (D). Each FPA instance

will have the first two computations steps as provided in the base model.

From a computation cost perspective, to take into consideration the possible D FPA instances,

each computation cost in the first two steps as provided in the base model will be multiplied

by D factor. The first computation step involves O(J . K. D) operations of (2), each of which

has O(R . M. D) operations of (1). The second computation step as provided in (3) involves

O(C . K) operations. It is important to note that the second computation step is not multiplied

by the D factor since each FPA instance will involve O(C/D . K) operations; thus the

computation cost for all the D FPA instances is O(C . K) operations.

126


As provided earlier, SPA-Dedicated control plane model supports state-dependent routing.

Hence, the SPA-Dedicated control plane model has the same computation cost as the base

control plane model for each control plane instance. As provided earlier, the SPA-Dedicated

control plane model supports the Complete Partitioning (CP) concept and hence there is a

FPA instance for each network partition (D). Each FPA instance will have the three

computations steps as provided in the base model.

From a computation cost perspective, the first two computation steps are exactly like the ITU

control plane model. The third computation step to compute a single mDrkq as provided in (5)

involves O(R. . M . D) operations. The cost of evaluating )( mn rA for a route mr involves O(H .

D) operations (multiplications) 10. As provided in (5), each route on the route list is evaluated

for every value Dn∈ , which gives O(M .C/D) such operations. This results in a total

computation cost of O(M . C . H) operations11 for each pair r and O(R . M . C . H) operations

for all source-destination pairs.


The SPA-Shared control plane model has the same computation cost like the SPA-Dedicated

for the three computation steps. One important aspect to consider is that the parameter D used

to define the number of network resources partitions need to include the total number of

network resources partitions including dedicated and shared partitions.

10.2 Implementation cost

This section provides details on the expected control plane messages’ overhead of the traffic

management schemes for the three control plane models. In our analysis of the control plane

messages’ overhead we will use the IETF control plane model as a reference model. The

analysis of the messages’ overhead is based on analyzing the impact of the following control

10 The D factor was included to count for the number of network partitions D. 11 It is important to note that the third computation step is not multiplied by the D factor since each

FPA instance will involve O(M .C/D) operations for each pair r; thus the computation cost for all the D

FPA instances is O(M . C . H) operations for each pair r.

127

plane traffic management capabilities on control plane routing and signaling messages’

overhead:

1. Routing update triggers: static routing vs. state-dependent routing

2. Network routing granularity: coarse vs. fine routing granularity

3. Load handling capability: Complete Sharing (CS) in IETF, Complete Partitioning (CP) in

ITU and SPA-Dedicated, and Virtual Partitioning (VP) in SPA-Shared. In SPA-Shared,

the load can be divided statically “Static Sharing (SS)” vs. dynamically “Network

Engineering (NE)” via LPF.

4. Demand inverse multiplexing via (IMF): enabled vs. disabled inverse multiplexing


The following is an analysis of the IETF traffic management configurations impact on routing

messages overhead:

The static routing configuration will eliminate the need to adjust the routing

probabilities of the routes stored in the Routing Database (RDB). This elimination of

routing probability modification will reduce the CPU time required to update the

RDB with the routing topology status of the network, the only CPU time required to

update the RDB is for updating the RDB with the coarse routing granularity of the

network topology rather than an additional CPU time to adjust the routing

probabilities of the stored routes based on the occupancy state of the network.

From a control plane perspective, each transport network granularity level is

represented by a collection of Routing Controllers (RCs) that collect the routing

topology at that transport network granularity level and store it in the corresponding

RDB of that transport network granularity level. Thus, each transport network

granularity level supported by the control plane will generate its own volume of

routing messages to capture the routing topology state at that transport network

granularity level. For example, the coarse routing granularity at the STS-3 transport

network granularity level will reduce the volume of routing messages by third

compared to the fine routing granularity, at the STS-1 transport network granularity

level, carried by both the ITU and SPA control plane models. This reduction of

128

routing messages volume will lead to reduction in bandwidth requirements on either

an in-band or out of-band channel to carry the routing messages between the RCs and

the RDB, and a reduction of RDB memory needs. The RDB memory needed in the

IETF control plane model will be one third of the memory needs requirements in

both the ITU and SPA control plane models.

Due to the IETF Complete Sharing (CS) of load arriving from N configured VPN

services, the routing messages updates via a single control plane instance will be used

to provide routing topology updates to the N configured VPN services. Both the LFP

and IMF are disabled in the IETF control plane model; thus no affect on routing

message volume and signaling messages volume is expected.


The following is an analysis of the ITU traffic management configurations impact on routing

messages overhead:

Static routing configuration will have the same impact on CPU time as provided in

section 10.2.1 on the IETF control plane messages analysis.

Since each transport network granularity level supported by the control plane will

require its own volume of routing messages to capture the routing topology state at

that transport network granularity level. For example, the fine routing granularity at

the STS-1 transport network granularity level will multiply the volume of routing

messages updates by 3 compared to STS-3 coarse routing granularity. This increase

of routing messages volume will lead to increase in bandwidth requirements on either

an in-band or out of-band channel to carry the routing messages between the RCs and

the RDB, and an increase of RDB memory needs. The RDB memory needs in the

ITU control plane model will be three times the memory needs requirements in the

IETF control plane model.

Due to ITU Complete Partitioning (CP) of load arriving from N configured VPN

services, the routing messages volume via the N control plane instances will be N

times the routing messages volume of the IETF single control plane instance. This

increase of routing messages volume will lead to the same impact on in-band or out-

of band channel bandwidth requirements and RDB memory requirements similar to

129

the fine routing granularity impact. Both the LFP and IMF are disabled in the ITU

control plane model; thus no affect on routing message volume is expected.


The following is an analysis of the SPA-Dedicated traffic management configurations impact

on routing messages overhead:

State-dependent routing configuration will require the need to adjust the routing

probabilities of the routes stored in the RDB, the routing probability modification

will increase the CPU time required to update the RDB with the routing topology

status of the network. In addition to the CPU time required to update the RDB with

the routing topology fine granularity level, additional CPU time is required to update

the routing probabilities of the routes stored in the RDB based on the occupancy state

of the network.

The fine routing granularity, e.g., STS-1 transport network granularity level, will

have the same affect on routing messages volume and the same implications on in-

band/out-of band bandwidth requirements and RDB memory as provided in the ITU

control plane model.

The Complete Partitioning (CP) of load arriving from N configured VPN services

will have the same affect on routing messages volume and the same implications on

in-band/out-of band bandwidth requirements and RDB memory as provided in the

ITU control plane model. Both the LFP and IMF are disabled in the SPA-Dedicated

control plane model; thus no affect on routing message volume is expected.


The following is an analysis of the SPA-Shared traffic management configurations impact on

routing messages overhead:

State-dependent routing configuration will have the same impact CPU time as

provided in the SPA-Dedicated control plane model.

The fine routing granularity, e.g., STS-1 transport network granularity level, will

have the same affect on routing messages volume and the same implications on in-

130

band/out-of band bandwidth requirements and RDB memory as provided in the

ITU/SPA-Dedicated control plane model.

The Virtual Partitioning (VP) of load arriving from N configured VPN services will

have an increase in routing messages volume and an increase in in-band/out-of band

bandwidth requirements and RDB memory over IETF/ITU/SPA-Dedicated control

plane models. The reason for the routing messages volume increase is due to the

addition of the shared resources partition which will have its own volume of routing

messages beyond the routing messages volume on the dedicated resources partitions.

The following is an analysis of the SPA-Shared traffic management configuration on

signaling messages overhead:

The Virtual Partitioning (VP) of load arriving from N configured VPN services will

introduce additional signaling messages between the control plane instances

controlling the dedicated and shared resources partitions. The additional signaling

messages will be used to partition the load across the dedicated and shared resources

partitions. It is important to mention that when LPF is configured as NE, the volume

of signaling messages between the dedicated and shared resources partitions will

increase over LPF when configured as (SS), this is due to the dynamic load

partitioning across the dedicated and shared resources partitions based on the

blocking probability state at the dedicated resources partitions.

When inverse multiplexing is enabled to divide the service demand with actual

bandwidth requirements Akb into N flows each with granular bandwidth

requirements Gkb , the signaling messages volume will increase by N compared to

when inverse multiplexing is disabled.

Table 10-1 summarizes the traffic management schemes impact on control plane messages.

The numbers in Table 10-1 assume a transport network coarse granularity level of 3 STS-1,

transport network fine granularity level of 1 STS-1, IMF that splits the actual service request

demand of 2 STS-1 into two granular service demands each with 1 STS-1 demand, and N=3

network resources partitions.

131

Control Plane Messages Impact on Single Control Plane Instance (CPI)

Number of Network

Partitions (N=3)

Impact on

Additional CPU

Time to Update

Routing

Probability

Impact on Routing

Messages Volume

Impact on

Signaling Messages Volume

Traffic

Management

Scheme

Capability Routing Update

Triggers

Routing

Granularity Level Load Partitioning Inverse

Multiplexing

Impact on Signaling and

Routing Messages

Volume

IETF No impact 1/3 of ITU and

SPA NA NA NA

ITU No impact 3 times of IETF NA NA N times single CPI

messages

SPA-Dedicated Increased 3 times of IETF NA NA N times single CPI

messages

SPA-Shared Increased 3 times of IETF

Increased between

control plane

instances

2 times when

IMF enabled

compared to

IMF disabled

N times single CPI

messages

Table 10-1: Traffic Management Schemes Impact on Control Plane Messages

132

11 Discussion of Model Validation and Accuracy

Section 11.1 is focused on the mathematical models validation, section 11.2 is focused on the

mathematical models computation accuracy and sanity checks carried, and section 11.3 is

focused on the performance results trends.

11.1 Discussion of model validation

11.1.1 Fixed point uniqueness

While it can be shown the existence of a fixed point under the proposed fixed point

approximation by applying Brouwer’s fixed point theorem [59], the uniqueness of this fixed

point need to be further analyzed. The possibility of bi-stability or multiple fixed points has

been analyzed in previous literature and was mainly focused on the impact of alternate

routing and connection admission control via trunk reservation factors on bi-stability or

multiple fixed points scenario, we will address the uniqueness of the fixed point

approximation for the IETF, ITU, and SPA control plane models using the same two factors

[59-72].

11.1.1.1 Alternate routing impact

Two alternate routing schemes were used for the three control plane models. In both the IETF

and ITU control plane model, fixed alternate routing was used where the routing probability

of routing traffic on a certain route for any source-destination pair is assigned statically

without consideration for the occupancy state of the links on that route, two options were

used in assigning the routing probability under fixed alternate routing; Direct Routing (DR)

and Split Routing (SR). In DR, the traffic between any source-destination pair is routed on

the direct route only with the least number of hops. In SR, the traffic between any source-

destination pair is split evenly across the possible routes between the source-destination pair.

In the SPA control plane model, state-dependent routing was used where the routing

probability of routing traffic on a certain route for any source-destination pair is assigned

dynamically based on the occupancy state of the links on that route. The state-dependent

routing used is based on the least loaded routing (LLR) scheme. In LLR scheme, a service

133

request is first tried on the direct route, if there is one. If it cannot be setup along the direct

route, then the non-direct route is chosen. LLR chooses the route that has the maximum units

of end-to-end free bandwidth (also called the residual bandwidth) among all routes. In the

state-dependent routing, each source-destination node pair is allowed a list of feasible routes,

ordered in increasing length, i.e., number of hops. A service request is then routed on the one

that has the largest amount of end-to-end residual bandwidth. In the state-dependent routing,

we will not require that the direct link always be selected with priority over all other routes,

but rather that it is selected if it has the maximum residual bandwidth.

Regarding the uniqueness of fixed point approximation under fixed routing, Kelly in [59] and

others in [60, 61, 64, 66, 67, 71] proved that blocking probability estimates of a network have

a unique solution under any of the following two modeling framework conditions:

1. When the link capacities and load are increased together, keeping the routing

probabilities fixed.

2. When the number of links and routes are increased while the link load is kept constant.

In both the IETF and ITU fixed routing, the second modeling framework condition was

considered. Under the 4-node and 7-node topologies with both two and three alternate

routing, the number of links and routes were increased while the link load is kept the same. In

other words, the same range of load was applied to the two network topologies which resulted

in similar performance of the IETF and ITU direct and split routing when compared to the

SPA control plane model.

Regarding the uniqueness of fixed point approximation under state-dependent routing which

is based on dynamic alternate routing scheme, it has been pointed out in [59] that under

dynamic alternative routing there may be more than one fixed point. This may be associated

with multiple stable states for the network. For example, in networks with random alternative

routing the system can oscillate between a low blocking state where calls are accepted readily

over the direct route with minimum number of hops, and a high blocking state where calls are

accepted over the alternate route with larger number of hops than the direct route. This is due

to the fact that calls admitted to the alternate route use more network resources and may force

more calls to be routed through their alternate route instead of their direct route. Thus, the

134

network may enter a bi-stable region where there are two equilibrium points, one stable and

one unstable.

As described in [68], there is a correlation between the existence of multiple fixed points or

bi-stability case and the possibility of oscillations at the final values of the FPA. As described

in section 8.4, the FPA with state-dependent routing for the SPA control plane model is based

on the base model as provided in [68]. In [68], no oscillations were observed on the FPA final

values for the two topologies analyzed as illustrated in Figure 11-1. In our analysis, no

oscillations were observed in the 4-node and 7-node topologies analyzed using state-

dependent routing; which eliminates the possibility of a bi-stability or multiple fixed point

case for the SPA control plane model. For each FPA, it was observed that there was no

oscillations scenario in the final values where there were multiple fixed points for a low

probability state and a high probability state. Instead, it was observed that each FPA with

state-dependent routing had a single fixed point that converged with a higher routing

probability for the direct route over the possible alternate routes due to the way the direct

route and possible alternate routes were selected.

As indicated earlier for the SPA state-dependent routing, each source-destination node pair is

allowed a list of feasible routes, ordered in increasing length, i.e., number of hops. Recall the

mathematical equation used to compute the routing probability as follows:

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq …………….. (1)

Also, recall the occupancy events as follows:

∏ ∑−∈

−

=

−=−)( 0

)(1)](Pr[mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (2)

∏ ∑−∈

+−

=+ −=−

)(

1

01 )(1)](Pr[

mk

Dj

rrj

nC

k

Djmk

Dn kPrrA …………….. (3)

135

It is observed from equations (2, 3) that the larger the number of hops (j) for a route (r), the

smaller the probabilities of events )( mkD

n rrA − and )(1 mkD

n rrA −+ and thus the smaller the

routing probability mDrkq . The routing probability mD

rkq for the direct route will be much greater

than the routing probability for route-2 and route-3 due to the smaller number of links (j). In

the 4-node topology, for each source-destination pair, there was a direct route of one hop and

an alternate route of two hops. As indicated in Table 10-1 for the 7-node topology, route-1

which is the direct route between any source-destination pair has an average number of hops

over all the source-destination pairs of 1.76 hops while route-2 and route-3 has an average

number of hops over all the source-destination pairs of 2.8 and 4 hops respectively.

Also, it was argued in [63] that if the ratio between hop numbers of any two alternative routes

is sufficiently large (e.g., greater than 0.5), then the network resources used by routing a

service request on different alternative routes do not significantly vary, and thus the blocking

probability will increase more smoothly with the increase in traffic without going into a bi-

stable region. In all our numerical experiments, our fixed point algorithms did not have a bi-

stability case due to the fact that the ratio between hop numbers of any two alternative routes

is sufficiently large. In the 4-node topology, for each source-destination pair, there was a

direct route of one hop and an alternate hop of two hops; thus the ratio between hop numbers

for the direct and alternate routes is 0.5. In the 7-node topology with 2-alternate routing case,

the ratio between hop numbers of any two alternate routes is 0.88 average and 0.5 minimum.

In the 7-node topology with 3-alternate routing case, the ratio between hop numbers of any

two alternate routes is 0.7 average and 0.4 minimum.

Gibbens and Kelly in [70] analyzed a symmetric fully connected network with N nodes and

every pair of nodes is connected by a link of capacity C, giving a total of K=N(N-1)/2 links

with r alternate routes. Gibbens and Kelly analyzed a network with parameters N=11,

C=120, and r=5 as the load v varies. It was observed that the high blocking state for alternate

routes is a lot less stable than the low blocking state for smaller values of v but becomes more

stable as v increases until finally there is one stable point. In addition, Gibbens and Kelly

analytically proved that the low blocking state using the direct route become more stable very

rapidly as the link capacity and number of links increase. x = (xo, x1,…..,xc) is a range of

136

possible fixed points of the network. Diffusion approximation was used to calculate the time

taken for the process to move from one fixed point to another fixed point, T(x1;x2) is the first

time that the diffusion hits x2 given that it starts at x2, and f(x1;x2)=E[T(x1;x2)]. So if x1<x2 are

two possible fixed points, then stability from f(x1;x2) can be assessed. Gibbens and Kelly

found that for some A1 and A2 constants that:

CKexxf

CKe CKACKA 21

);( 21 ≤≤

The above equation shows that the high blocking probability state using any of the alternate

routes becomes stable rapidly with increased number of links but more unstable as the link

capacity increases. The number of links of the topologies analyzed increased when the

analysis covered a 7-node topology with 9 links in addition to the 4-node topology with 4

links. In addition, the links’ capacities increased when SPA-shared control plane model was

used as the VPN resource partition increased in number of trunks from 13 to 16 trunks when

the sharing ratio between dedicated and shared resources was increased from 1 to 4 trunks

respectively.

Despite that the topologies analyzed in our problem are smaller than the topology analyzed in

[70], it is important to note that all the network topologies analyzed in previous literature to

study the bi-stability scenario were focused on a symmetric fully connected network where

the existence of a bi-stability scenario has a higher probability than the 7-node topology

analyzed. The reason for that is since each alternate route for a source-destination pair in the

fully connected network has 2 hops where the direct route has one hop, this would lead that

any possible two fixed points will be close in value and won’t be with a low probability state

for the direct route and a high probability state for the alternate route. That is why trunk

reservation on the alternate route is used to increase the blocking probability on the alternate

route and hence increase the blocking probability distinction between the direct and alternate

route, such distinction would lead to a faster convergence of the two fixed points to a single

fixed point. In the 7-node topology, there was a clear difference in the number of routes

between the direct and alternate routes which lead to a clear distinction in the blocking

probabilities between possible routes and hence between any possible fixed points.

137

As indicated in Table 10-1 for the 7-node topology, route-1 which is the direct route between

any source-destination pair has an average number of hops over all the source-destination

pairs of 1.76 hops while route-2 and route-3 has an average number of hops over all the

source-destination pairs of 2.8 and 4 hops respectively. This distinction in the number of hops

between different routes for each source-destination pair would lead to a faster convergence

of any possible fixed points to a single fixed point.

11.1.1.2 Connection admission control via trunk reservation

This section describes the impact of CAC with trunk reservation for alternate routes to avoid

bi-stability or multiple fixed points’ scenario. The CAC mechanism used in the three control

plane models did not use trunk reservation; thus this section is provided for completeness of

analyzing the fixed point uniqueness rather than validating the existence of single fixed point

for the three control plane models, the validation of the fixed point uniqueness for the three

control plane models is provided in section 11.1.1.1

The dynamic alternate routing used in the state-dependent routing is based on the maximum

residual bandwidth routing scheme, this scheme tries to avoid bottlenecks on a route.

However, since a route is chosen only based on the amount of free bandwidth, we may be

forced to take a longer or even the longest route in the feasible route set, using more network

resources. This may in turn force service requests arriving later to also be routed on their

longer/longest routes, which leads to increased loss/blocking probability in a network.

Therefore, using some form of admission control along with this routing scheme is a valid

choice when traffic is heavy. If the trunk reservation is used on the alternate route, the direct

route of every source-destination pair is given a higher priority, and all routes other than the

direct route will require an extra bandwidth “number of trunks” to be reserved on their links

when admitting a call. This trunk reservation scheme with CAC would increase the

possibility of unique fixed point that converges at the low probability state using the direct

route path.

11.1.2 Accuracy of mathematical models assumptions

As mentioned in section 8, the mathematical models of the IETF, ITU, and SPA control plane

models were extensions carried on the mathematical models in [68] as a base method. In

analyzing the accuracy of the mathematical models developed for the three control plane

138

models, we will first discuss the assumptions made and the mathematical models accuracy

analysis carried in [68], then we will discuss how the modeling parameters and network

topologies analyzed in our problem followed the same guidance carried in the base method

regarding the assumptions and network topologies analyzed. The mathematical models in

[68] were based on three main assumptions:

1. Link independence assumption. Under this assumption, blocking is regarded as to occur

independently from link to link. This assumption allows in computing the blocking

probability at each link separately.

2. Poisson assumption. Under this assumption, service arrivals arrive at a link as Poisson

process and the corresponding arriving load is the original external offered load thinned

by blocking on the other links, thus known as the reduced load.

3. Stationary input assumption. Under this assumption, certain time varying quantities of

interest have well-defined averages. These include the number of on-going service

requests on a link of each class, the average service request holding time, and he reduced

load on the link.

The accuracy of the mathematical models assumptions provided in [68] were validated by

comparing the analytical results of the FPA with the results of the Discrete Event Simulation

(DES) for the two topologies illustrated in Figure 10-1. One observation provided in [68]

based on the FPA and DES comparison is that the above assumptions were more accurate

when the network is better connected, routes are diverse and as the input load becomes

heavier. In addition to that, the accuracy heavily relies on the structure of the network

topology. Recall the mathematical equation used to compute the routing probability as

follows:

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq

The approximation of the routing probability would be accurate in a network when routes

between each source-destination node pair share one or more common links but are disjoint

elsewhere; thus )()( kD

nmkD

n rArrA ≈− and )()( 11 mkD

nmkD

n rrArrA −≈− ++ . This assumption

on link-disjoint between routes for a source-destination pair node would only be valid for a

network topology with minimal overlapping between routes. The routing computation in the

139

FPA used largely ignores the dependence between routes. Therefore, if we consider the case

where a network has mostly disjoint routes/paths and a second case where a network has

many routes sharing links, the algorithm will in general produce better approximation in the

first case. If routes are not all disjoint but the majority of routes between a given node pair

share the same set of links and are otherwise disjoint, then the approximation error may also

be reduced.

Figure 11-1: Network Topologies Analyzed in Base Method

The following observations were made for the fully-connected topology considered in [68]

illustrated in Figure 11-1:

1. When the input load is very light and the blocking probability is (far) below 1%, the FPA

did not generate accurate results when compared to the DES, overestimates of relative

errors were around +300%.

2. The accuracy of the FPA improves as the input load increases, and as the blocking

probability increases. Under heavier input load, the average percentage error, over all the

source-destination pairs, between the FPA and the DES for service request with

bandwidth requirement Akb = 3 STS-1 is 1.01%, and for service request with bandwidth

requirement Akb = 2 STS-1 is 2.83%.

n=1

n=2

n=3 n=4

n=5

n=0

n=1

n=2

n=3

n=4

n=5

n=6

n=7

n=8

n=9

n=10

n=11

n=12

n=13

n=14

n=15

Topology-1:Fully-Connected Topology Network

Topology-2:Random Topology Network

140

3. This accuracy of the FPA compared to DES was expected since in the fully-connected

network there is no route overlapping. The improvement in accuracy while increasing

input load is due to the fact that as input load becomes heavier, assumptions 1 and 2

become more accurate.

For the random topology, selected node pairs and classes were used to compare the FPA and

DES. The following observations were pointed in [68] for the random topology illustrated in

Figure 11-1:

1. The accuracy of the FPA improves as the input load increases, and as the blocking

probability increases. Under heavier input load, the absolute percentage error, over

selected source-destination pairs, between the FPA and the DES for service request with

bandwidth requirement Akb = 3 STS-1 is 1.32%, and for service request with bandwidth

requirement Akb = 2 STS-1 is 2.51%.

2. The accuracy of the FPA despite obvious route overlapping, this is since the random

topology consists of three distinct groups of nodes. As illustrated in Figure 11-1, the first

group of links consists of nodes 0-5 and 8-9, note that this group of nodes are very well

connected among themselves. The second group consists of nodes 12 and 15, which are

attached to the first group via a single link. Thus, all traffic between either of the two

nodes and the rest of the network will share a single link. Similarly the third group, which

consists of nodes 6-7 and 13-14, it is also attached to the first group via a single link. As a

result, most of the node pairs have routes that either do not overlap significantly and/or

share common links that are likely to be the common bottleneck links. These properties

have made the assumptions underlying the FPA more accurate.

The modeling parameters and network topologies analyzed in our problem followed the same

guidance carried in the base method [68] regarding the assumptions and network topologies

analyzed as follows:

1. Higher input loads were considered to make the first and second assumption provided

above more accurate. The higher input loads resulted in blocking probabilities ranging

from 5-25% for the 4-node topology and 5-40% for the 7-node topology. In [68], it was

validated that under higher input loads resulting blocking probabilities, FPA algorithm

average percentage error compared to DES is below 5%.

141

2. Minimal route overlapping was considered for the 4-node and 7-node topologies

analyzed; this increased the routing probability approximation accuracy as discussed

above. In the 4-node topology, the 2 possible alternate routes between any source-

destination pair with no overlapping links between the two routes. In the 7-node

topology, the links selected for the 2-alternate routing and 3-alternate routing between

each source-destination pair are listed in Table 11-1. It can be observed from Table 11-1

that in the 2-alternate routing case, route-1 and route-2 have completely distinct links,

whereas in the 3-alternate routing case, the three routes (1, 2, 3) have minimal link

overlapping between them. This will increase the accuracy of the routing probability

approximation as validated in the two topologies analyzed in [68].

Since the systems analyzed here using FPA have the properties that have previously been

shown to produce a unique solution with adequate accuracy a direct comparison between the

FPA and DES is not required here. Further since we are primarily concerned with ratio of

performance between the different control plane architectures, and not the absolute values of

the performance metrics, we do not expect the issues of uniqueness and accuracy to have an

impact on the conclusions of the analysis.

142

Source-Destination Nodes Route-1 Route-2 Route-3

{A,B} 8 9,10,11 10,11,12,16 {A,C} 8,9 10,11 8,12,16 {A,D} 11 8,9,10 8,10,12,16 {A,E} 8,12 10,11,16 10,11,13,14,15 {A,F} 8,12,13 10,11,14,15 10,11,13,16 {A,G} 10,11,15 8,12,13,14 8,9,13,14,16 {B,C} 9 8,10,11 12,13,14,15 {B,D} 9,10 8,11 10,12,16 {B,E} 12 9,16 8,10,11,16 {B,F} 12,13 9,14,15 9,13,16 {B,G} 9,15 12,13,14 8,10,11,15 {C,D} 10 8,9,11 11,12,16 {C,E} 16 9,12 13,14,15 {C,F} 13,16 14,15 9,12,13 {C,G} 15 14,16 9,12,13,14 {D,E} 10,16 8,11,12 10,13,14,15 {D,F} 8,11,12,13 10,14,15 10,13,16 {D,G} 10,15 1,8,12,13,14 8,11,12,15,16 {E,F} 13 14,15,16 9,12,14,15 {E,G} 13,14 15,16 9,12,15 {F,G} 14 13,15,16 9,12,15

Table 11-1: Routes of the 7-Node Topology

11.2 Discussion of model accuracy

11.2.1 Occupancy probabilities computation

As provided in section 8.3 focused on Calculating the link’s occupancy and admissibility

probabilities, the summation of occupancy probabilities of link j for all the states

],0[ jCn∈ has to equal 1 as provided in the following mathematical

constraint: 1)(0

=∑ =

jC

n j np . As mentioned in section 9, MathematicaTM tool was used to

compute the occupancy probability )(np j for each link j in the network topology, the

MathematicaTM code that was written for each control plane model took into consideration

the occupancy probability mathematical constraint.

143

As provided in section 9.1, the ITU and SPA-Dedicated control plane models partition the 24

STS-1 physical resources into two dedicated network resources partitions with 12 STS-1 per

dedicated network resources partition, whereas the SPA-Shared control plane model

partitions the 24 STS-1 physical resources into three network resources partitions according

to the sharing ratio between dedicated and shared network resources partitions. The following

is the MathematicaTM code written for the dedicated network resources partition with 1 STS-1

sharing for SPA-Shared:

Dedicated Network Resources Partition Occupancy Probabilities Equations:

eqns = {

p1 ==a*p0,

p2 == a/2p1+b/2p0,

p3 == a/3p2+b/3p1,

p4 == a/4p3+b/4p2,

p5 == a/5p4+b/5p3,

p6 == a/6p5+b/6p4,

p7 == a/7p6+b/7p5,

p8 == a/8p7+b/8p6,

p9 == a/9p8+b/9p7,

p10 == a/10p9+b/10p8,

p11 == a/11p10+b/11p9,

p0 == 1 - p1 - p2 - p3 - p4 - p5 - p6-p7-p8-p9-p10-p11}

As the list of equations indicate, for 1 STS-1 sharing between the dedicated and shared

network resources partitions, the dedicated network resources partition will have 11 STS-1

resources ( 11=DjC ) and 12 states (n=12). The terms a and b indicate the two classes

arrivals with 1 STS-1 and 2 STS-1 bandwidth requirements respectively, and p ranging from

0 to 11 indicating the occupancy probabilities for the 12 states (n=12). The last equation

indicating the occupancy probability when none of the link j resources is occupied, (p0) is

written to fulfil the occupancy probability constraint discussed above. It is observed from the

last equation that the summation of occupancy probabilities of link j for all the states

],0[ DjCn∈ is equal to 1 as provided in the constraint: 1)(

0=∑ =

DjC

n j np . When the output of

144

the of the occupancy probabilities equations was used in the FPA algorithm, validating that

the summation of occupancy probabilities of link j for all the states ],0[ DjCn∈ is equal to 1

was carried after each FPA convergence, the percentage of error was 0%.

Note that we do not independently calculate p0-p11 and then check to see if they add to 1;

instead, we force that by calculating p1…p11 and then find p0 = 1-sum(p1..p11); which will

always converge to 1. So this sanity check does not check the accuracy of the occupancy

probability equations solution provided by MathematicTM, rather it provides a check that the

occupancy probability computation phase of the FPA mechanism provided accurate estimates

that help in FPA convergence. If the occupancy probability computation phase provides in-

accurate estimates, the FPA will oscillate and will not converge. In [68] that was used as a

base model for problem, it was pointed out that the FPA fast convergence depends heavily on

the accurate computation of the required values. In [68], the FPA algorithm managed to

converge via heavy dampening techniques where during the iteration newly computed values

are heavily weighted by their old values to prevent drastic changes from happening and hence

allowing for the possibility of oscillations at the final values of the FPA. As discussed in

section 11.1.1.1, no oscillations scenario was observed at the final values of the FPA which

indicated the accurate computation of the occupancy probabilities.

11.2.2 Routing probabilities computation

The accuracy of the routing probability computation was validated by two methods. The first

method is based on the accuracy of the occupancy probability, as provided in section 8.4

focused on Calculating the routing probability mDrkq , the routing probability computation is

based on the computed occupancy probability as provided in equations (34-41). If we

consider equations (37, 39, 40, 41), the state probabilities )](Pr[ mkD

n rrA − , )](Pr[ mkD

n rrA − ,

, and )](~Pr[ mDn rA are all based on the occupancy probability )(kPD

j , since the accuracy of

the occupancy computation was validated as provided in section 11.2.1, the first method of

validating the accuracy of the routing probability computation was carried. The second

method of validation is based on the routing probability constraint that the summation of the

routing probability mDrkq for all the routes between a source-destination pair r has to equal 1 as

145

given in: ∑∈

=rm Mr

mDrkq 1. After each FPA convergence, the routing probability constraint was

validated. Percentage error was in the range below 3%, for the 7-node topology and 0% for

the 4-node topology.

The reason for a percentage error higher than zero for the 7-node topology is due to the

limitations of the routing probabilities computation base algorithm for larger network

topology. The mathematical formulation used in [68] to compute the state-dependent routing

probability mrkq for each route mr lacks the accuracy needed when computing routing

probability for a network topology with higher level of meshing among routes. Recall the

mathematical equation used to compute the routing probability as follows:

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq




nmkD


nmkD


on link-disjoint between routes for a source-destination pair node would only be valid for a

network topology with minimal or no overlapping between routes as in the 4-node topology

case.

11.2.3 LPF and IMF traffic management operations

When the performance of the SPA-shared control plane model was evaluated, a sanity check

was implemented to check the accuracy of the LPF and IMF traffic management operations.

The sanity check of the LPF operation made sure that the summation of the load applied to

the dedicated network resources partitions and the shared network resources partition is equal

to the total input load, this was verified in both the load partitioning without NE and with NE.

In the case of load partitioning without NE, LPF is configured to partition the configured

VPN service v total arrival load vrkλ between the dedicated resources vD

jC and the shared

resources SjC based on the resources ratios between dedicated and shared resources partitions

as given in equations (9,10), it can be concluded that the summation of vDrkλ and vS

rkλ will

146

equals vrkλ . In the case of load partitioning with NE, FPA is carried in two rounds on the

dedicated resources partitions and one round on the shared resources partition to make sure

that the summation of vDrkλ and vS

rkλ will equal vrkλ . In round-1, the configured VPN service-v

total arrival load vrkλ is applied to the dedicate resource partition vD

jC as given in equation

(14). When round-1 of the FPA on dedicated resources partitions is complete, the pair

blocking probability vDrkB is used to generate the configured VPN service-v shared

load vSrk

NEλ as provided in equation (15). In round-2, the non-blocked load from round-1 is

applied again to each dedicate resource partition vDjC as given in equation (17). The sanity

check of the IMF operation made sure that the input load before an inverse multiplexing

operation is equal to the input load after the inverse multiplexing operation. As provided in

equations (32, 33), it should be observed that an additional term (i) is multiplied by the

Erlang loadk

vDjkG

kbμλ

to maintain the same Erlang input load before and after inverse

multiplexing operation where Gk

Ak ibb = .

11.3 Discussion of trends in system performance

11.3.1 Analysis of operational space for network topologies and services

It is important to mention the following before any generalization of the performance results

is carried to predict a possible performance trend of each control plane model:

1. Limited topologies size: the 4-node and 7-node topologies analyzed were limited in both

number of nodes and nodes’ connectivity (not fully meshed). The main objective of this

research is to prove the SPA control plane model superiority compared to both the IETF

and ITU control plane models rather than analyzing the impact of the network topology

size on the performance and control plane messages scalability of the three control plane

models.

2. Network topologies specific routing attributes: the network topologies analyzed and the

routing options for each network topology were carefully selected to enforce minimal or

no link overlapping between possible routes for each source-destination pair, the 4-node

147

topology had no link overlapping between routes for each source-destination pair

whereas the 7-node topology had minimal link overlapping between routes for each

source-destination pair. The minimal link overlapping constraint between routes was

enforced to increase the computation accuracy of the routing probability using the FPA

mechanism as provided in section 11.1.2.

3. Limited classes considered: two classes were considered; class-A with actual bandwidth

requirement Akb =1-STS-1 and class-B with actual bandwidth requirement A

kb =2-STS-1.

One of the objectives of this research is to study the impact of the SPA IMF inverse

multiplexing capability on the performance of SPA control plane model when compared

to the IETF and ITU control plane models. To analyze the IMF impact, we need to run

the model using a service class with actual bandwidth requirement of 2-STS-1 or higher,

this will allow the IMF to split “inverse-multiplex” the service’s single flow with actual

bandwidth requirements Akb into multiple flows each with granular bandwidth

requirement Gkb . Thus, running the model with class-B service arrivals will be sufficient

to analyze the IMF impact.

4. Call-Oriented model: the model used is a call-oriented model. In call-oriented model,

network resources are assigned to a service request from the source to the destination

nodes before the start of the transfer, thus creating a “circuit”. The resources remain

dedicated to the circuit during the entire transfer and the entire message follows the same

path. In the packet-oriented model, the message is broken into packet, each of which can

take a different route to the destination where the packets are recompiled into the original

message.

5. Flexible Service Level Agreement (SLA) for the analyzed FSG service configuration

model: the performance analysis was carried on a single service configuration with

specific service profile parameters as indicated in section 3.2.6. The FSG configured

VPN service model allows the input load to be partitioned across dedicated and shared

resources partitions in addition to allowing a granular portion Gkb of its actual service

demand Akb to be accepted if no available resource are available to accept the actual

service demand.

148

The FSG with its service profile parameters is considered a service with flexible SLA that

does not dictates its input load and demand from being partitioned and thus accepting the

possibility of receiving a lower SLA than its optimum SLA. Other defined service models

in section 3.2 do not have the same flexible SLA like the FSG configured service model.

The FSG flexibility in partitioning its load between the dedicated and shared resources

partitions will give the SPA control plane model an advantage over the IETF and ITU

control plane models due to the Load Partitioning Function (LPF) of the SPA control

plane model affect on improving the SPA control plane performance. In addition, the

FSG flexibility in partitioning its actual demand into granular demands will give the SPA

control plane model an advantage over the IETF and ITU control plane models due to the

Inverse Multiplexing Function (IMF) of the SPA control plane model affect on improving

the FPA control plane performance.

Thus, under the specific operational space for the network topologies and flexible service

SLA specific above, a performance trend of the IETF, ITU, and SPA control plane model

can be provided.

11.3.2 7-node topology case study

The 7-node topology with its 2-alternate and 3-alternate routing cases were used to draw a

conclusion on the performance comparison of the nine traffic management schemes of the

IETF, ITU, and SPA control plane models.

In analyzing the results trend, the IETF-DR traffic management scheme was considered as a

reference model; thus the IETF-DR traffic management scheme was given a rank of zero and

the rest of the eight traffic management schemes were ranked accordingly in ascending order

based on the performance metric evaluated. For any performance metric, a traffic

management scheme with a negative rank indicates that this traffic management scheme

performs worse than the IETF-DR traffic management scheme, whereas a traffic management

scheme with a positive rank indicates that this traffic management scheme performs better

than the IETF-DR traffic management scheme.

For the blocking probability performance metric, a traffic management scheme with a lower

blocking probability than the IETF-DR is given a positive number in the blocking probability

149

reduction rank, whereas a traffic management scheme with a higher blocking probability than

the IETF-DR is given a negative number in the blocking probability reduction rank. Table 11-

2 illustrates the eight traffic management schemes rank in blocking probability compared to

the IETF-DR traffic management schemes. A consistent trend was observed for the 2-

alternate routing and 3-alternate routing case with the following observations:

1. Both the IETF-SR and ITU-SR traffic management schemes lead to higher blocking

probability, lower reduction in blocking probability, compared to the IETF-DR with

IETF-SR providing the highest blocking probability.

2. SPA-Dedicated traffic management scheme does not provide any reduction in blocking

probability compared to the IETF-DR traffic management scheme, but provides lower

blocking probability, higher reduction in blocking probability, compared to IETF-SR and

ITU-SR traffic management schemes.

3. The SPA two traffic management schemes with enabled inverse multiplexing lead to the

lowest blocking probability, the highest reduction in blocking probability, compared to

the rest of the traffic management schemes.

For the permissible load performance metric, a traffic management scheme with a lower

permissible load than the IETF-DR is given a negative number in the permissible load

increase rank, whereas a traffic management scheme with a higher permissible load than the

IETF-DR is given a positive number in the permissible load rank. Table 11-3 illustrates the

eight traffic management schemes rank in permissible load compared to the IETF-DR traffic

management schemes. A consistent trend was concluded for the 2-alternate routing and 3-

alternate routing case with the following observations:

1. The SPA-Shared control plane model with disabled inverse multiplexing leads to a

reduction in permissible load compared to the IETF-DR traffic management scheme.

2. IETF-SR and ITU-DR traffic management schemes do not provide increase or decrease

in permissible load compared to the IETF-DR traffic management scheme.

3. The SPA two traffic management schemes with enabled inverse multiplexing lead to the

highest increase in permissible load compared to the rest of the traffic management

schemes.

150

For the utilization performance metric, a traffic management scheme with a lower utilization

than the IETF-DR is given a positive number in the utilization reduction rank, whereas a

traffic management scheme with a higher utilization than the IETF-DR is given a negative

number in the utilization rank. Table 11-4 illustrates the eight traffic management schemes

rank in utilization compared to the IETF-DR traffic management schemes. A consistent trend

was concluded for the 2-alternate routing and 3-alternate routing case with the following

observations:

1. IETF-SR traffic management scheme provides the highest utilization, lowest reduction in

utilization, compared to the IETF-DR traffic management scheme.

2. For both the IETF and ITU control plane models, direct routing leads to higher reduction

in utilization compared to split routing.

3. All the traffic management schemes of the SPA control plane model provide a reduction

in utilization compared to the IETF and ITU control plane models under both direct and

split routing.

Traffic Management Scheme

7-Node Topology “2-Alternate Routing”


IETF-SR -4 -4 ITU-DR 1 1 ITU-SR -3 -3 SPA-Dedicated 0 0 SPA-w/o(NE,IM) -2 -2 SPA-w/NE,w/oIM -1 -1 SPA-w/oNE,w/IM 2 2 SPA-w/(NE,IM) 3 3

Table 11-2: Traffic Management Schemes Rank in Blocking Probability Reduction (IETF-DR as Reference Model)

151




IETF-SR 0 0 ITU-DR 0 0 ITU-SR 2 2 SPA-Dedicated 1 1 SPA-w/o(NE,IM) -1 -1 SPA-w/NE,w/oIM -2 -2 SPA-w/oNE,w/IM 4 4 SPA-w/(NE,IM) 3 3

Table 11-3: Traffic Management Schemes Rank in Permissible Load Increase (IETF-DR as Reference Model)

Traffic Management

Scheme 7-Node Topology

“2-Alternate Routing” 7-Node Topology

“2-Alternate Routing” IETF-SR -1 -1 ITU-DR 6 6 ITU-SR 2 2 SPA-Dedicated 4 4 SPA-w/o(NE,IM) 5 5 SPA-w/NE,w/oIM 7 7 SPA-w/oNE,w/IM 3 3 SPA-w/(NE,IM) 1 1

Table 11-4: Traffic Management Schemes Rank in Utilization Reduction (IETF-DR as Reference Model)

12 Summary of System Performance

This section provides a summary of the performance analysis results for the 7-node topology.

The framework of the performance comparison between the different traffic management

schemes is as follows:

1. Rank the nine traffic management schemes based on the operational complexity (more

parameters to set including enabling state-dependent routing, load partitioning, and

inverse multiplexing). The following is the rank based on ascending level of operational

complexity: IETF-DR, IETF-SR, ITU-DR, ITU-SR, SPA-Dedicated, SPA-w/o(NE,IM),

SPA-w/oNE,w/IM, SPA-w/NE,w/oIM, SPA-w/(NE,IM).

2. Use IETF-DR as a reference model to compare the rest of the eight traffic management

schemes.

152

3. Define three performance metrics (blocking probability, permissible load, and

utilization). For each performance metric, compare the rest eight traffic management

schemes to IETF-DR traffic management scheme. For each plot, the eight traffic

management schemes are plotted (x-axis) against the IETF-DR as a reference model.

The following performance metrics from a physical resources perspective were studied:

1. Network-Wide blocking probability

2. Network-Wide permissible “non-blocked” load

3. Network-Wide utilization

12.1 Average network-wide blocking probability

Table 12-1, Figure 12-1, and Figure 12-2 compare the blocking probability reduction among

the nine traffic management schemes while considering the IETF-DR as a reference model.

For Table 12-1, Figure 12-1, and Figure 12-2, it is important to mention that a negative

number for a blocking probability reduction is an increase in blocking probability over IETF-

DR control plane model. The performance analysis found the following:

1. While considering the IETF-DR as a reference control plane model, all the traffic

management schemes of the SPA control plane provide a higher reduction in blocking

probability compared to the IETF-SR and ITU-(DR,SR) control plane models. The

blocking probability reduction is 0-131% and 39-122% respectively; depending on the

SPA traffic management scheme, SPA number of alternate routes, and the IETF/ITU

static routing configuration (direct routing vs. split routing).

2. When IMF is disabled in the SPA control plane model, IETF-DR traffic management

scheme produces less blocking probability than the SPA control plane model. On the

contrary, when IMF is enabled, the SPA control plane model leads to a reduction in

blocking probability compared to IETF-DR; the reduction in blocking probability is 22-

48% depending on the SPA traffic management scheme and the number of alternate

routes. The highest reduction in blocking probability occur for “w/(NE,IM)” SPA traffic

management scheme where LPF is configured to Network Engineering (with NE) and

IMF function is configured to enabled Inverse Multiplexing (with IM); a reduction of 43-

80% of blocking probability depending on the number of alternate routes.

153

3. The SPA-Dedicated control plane model does not provide a reduction in blocking

probability compared to IETF-DR as reference model, but provides a 5-10% reduction in

blocking probability compared to SPA-Shared with static load partitioning.

Reduction in Blocking Probability Network Topology

Control Plane Model Reduction % Relevant Figure

IETF-DR 0 IETF-SR -83 ITU-DR 9 ITU-SR -74 SPA-Dedicated 0

Figure 13-1

SPA-w/o(NE,IM) -13 Figure 13-2 SPA-w/NE,w/oIM -9 Figure 13-3 SPA-w/oNE,w/IM 22 Figure 13-4

7-Node “2-aternateRoutes”

SPA-w/(NE,IM) 48 Figure 13-5 IETF-DR 0 IETF-SR -43 ITU-DR 9 ITU-SR -35 SPA-Dedicated 0

Figure 13-15



SPA-w/(NE,IM) 43 Figure 13-19

Table 12-1: Blocking Probability Reduction (IETF-DR as Reference Model)- 7-node topology

12.2 Average per source-destination pair permissible load

Table 12-2, Figure 12-3, and Figure 12-4 compare the permissible load increase among the

nine traffic management schemes while considering the IETF-DR as reference model. For

Table 12-2, Figure 12-3, and Figure 12-4, it is important to mention that a percentage

increase in permissible load that is negative is a decrease in permissible load over IETF-DR

reference model. The performance analysis found the following:

1. While considering the IETF-DR as a reference control plane model, all the traffic

management schemes of the SPA control plane, except when IMF is disabled, provide a

higher increase in permissible load compared to the IETF-SR and ITU-(DR,SR) control

plane models. The increase in permissible load is 120-134% and 110-120% respectively;

154

depending on the SPA traffic management scheme, SPA number of alternate routes, and

the IETF/ITU static routing configuration (direct routing vs. split routing).

2. The highest increase in permissible load occurs for SPA-“w/oNE,w/IM” traffic

management scheme where LPF is configured to static load partitioning (without NE)

and IMF function is configured to enabled Inverse Multiplexing (with IM). The increase

in permissible load is 120-134% compared to IETF-DR control plane model; depending

on the number of alternate routes.

3. While enabling IM, performing load partitioning statically “without Network

Engineering” or dynamically “with Network Engineering” does not provide a significant

impact on the percentage gain in permissible load.

4. While disabling IM and regardless of static or dynamic load partitioning for SPA-Shared

control plane model, the SPA control plane model provides less permissible load than

IETF-DR control plane model.

Increase in Permissible Load Network Topology

Control Plane Model Increase % Relevant Figure

IETF-DR 0 IETF-SR 0 ITU-DR 0 ITU-SR 4 SPA-Dedicated 3

Figure 13-6



SPA-w/(NE,IM) 127 Figure 13-10 IETF-DR 0 IETF-SR 0 ITU-DR 0 ITU-SR 1 SPA-Dedicated 2

Figure 13-20




Table 12-2: Permissible Load Increase (IETF-DR as Reference Model) - 7-node topology

155

12.3 Average network-wide resource utilization

Table 12-3, Figure 12-5, and Figure 12-6 compare the utilization reduction among the nine

traffic management schemes while considering the IETF-DR as reference model. For Table

12-3, Figure 12-5, and Figure 12-6, it is important to mention that a percentage reduction in

utilization that is negative is an increase in utilization over IETF-DR reference model. The

performance analysis found the following:

1. Compared to IETF-DR, all the traffic management schemes of the SPA control plane

model provide a reduction in utilization; the reduction in utilization is 7-31% depending

on the SPA traffic management scheme and number of alternate routes.

2. Compared to IETF-DR, the lowest reduction in utilization occur for “w/(NE,IM)” and

“w/oNE,w/IM” SPA traffic management schemes when IMF is configured to enabled

Inverse Multiplexing (with IM) and regardless of LPF configuration as static or dynamic

partitioning; a reduction of 7-25% in utilization over the IETF-DR control plane model

depending on the number of alternate routes.

Reduction in Utilization Network Topology

Control Plane Model Increase % Relevant Figure

IETF-DR 0 IETF-SR -21 ITU-DR 25 ITU-SR 7 SPA-Dedicated 23 SPA-w/o(NE,IM) 25

Figure 13-11

SPA-w/NE,w/oIM 30 Figure 13-12 SPA-w/oNE,w/IM 10 Figure 13-13


SPA-w/(NE,IM) 7 Figure 13-14 IETF-DR 0 IETF-SR -16 ITU-DR 27 ITU-SR 13 SPA-Dedicated 20 SPA-w/o(NE,IM) 27

Figure 13-25

SPA-w/NE,w/oIM 31 Figure 13-26 SPA-w/oNE,w/IM 25 Figure 13-27



Table 12-3: Utilization Reduction (IETF-DR as Reference Model) - 7-node topology

156

While considering the operational space of the network topologies and the service analyzed

as provided in section 11.3.1, the SPA control plane demonstrates its superiority over IETF

and ITU control plane models as follows:

1. All the traffic management schemes of the SPA control plane provide a higher reduction

in blocking probability compared to the IETF-SR and ITU-SR control plane models. The

SPA control plane model provides a higher reduction in blocking probability over ITU-

DR when IMF is enabled to allow inverse multiplexing.

2. All the traffic management schemes of the SPA control plane, except when IMF is

disabled, provide a higher increase in permissible load compared to the IETF-SR and

ITU-(DR,SR) control plane models.


in utilization compared to the IETF-(DR, SR) and ITU-(DR,SR) traffic management

schemes.

The consistent performance analysis results carried on the 7-node topologies for both two and

three alternate routes validated the hypotheses of this work and indicated a common trend of

the superiority of the SPA control plane model over the IETF and ITU control plane models

under specific operational space as provided in section 11.3.1; this consistent performance for

the 7-node topology for both two and three alternate routes can be used to generalize the

superiority of the SPA control plane model over both IETF and ITU control plane models

under specific operational space as provided in section 11.3.1.

157

Figure 12-1: Network-Wide Blocking Probability Percentage Reduction (IETF-DR as Reference Model)- 7-node with 2-Alternate Routing

Network-Wide Reduction in Blocking Probability (Physical Resources Level)- IETF-DR as reference control plnae model

7-Node Topology (2- Alternate Routing)

0%

-83%

9%

-74%

0%

-13%-9%

22%

48%

-100%

-80%

-60%

-40%

-20%

0%

20%

40%

60%

IETF-DR IETF-SR ITU-DR ITU-SR SPA-Dedicated

SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

158

Figure 12-2: Network-Wide Blocking Probability Percentage Reduction (IETF-DR as Reference Model)- 7-node with 3-Alternate Routing

Network-Wide Reduction in Blocking Probability (Physical Resources Level)- IETF-DR as reference control plnae model


0%

-43%

9%

-35%

0%

-9%-5%

26%

43%

-50%

-40%

-30%

-20%

-10%

0%

10%

20%

30%

40%

50%


SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

159

Figure 12-3: Network-Wide Permissible Load Percentage Difference (IETF-DR as Reference Model) - 7-node with 2-Alternate Routing

Network-Wide Increase in Permissible Load (Physical Resources Level)- IETF-DR as reference control plnae model


0% 0% 0% 4% 3%

-2%-11%

134%127%

-20%

0%

20%

40%

60%

80%

100%

120%

140%

160%


SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

160

Figure 12-4: Network-Wide Permissible Load Percentage Difference (IETF-DR as Reference Model) - 7-node with 3-Alternate Routing

Network-Wide Increase in Permissible Load (Physical Resources Level)- IETF-DR as reference control plnae model


0% 0% 0% 1% 2%

-1%-11%

120%111%

-20%

0%

20%

40%

60%

80%

100%

120%

140%


SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

161

Figure 12-5: Network-Wide Utilization Percentage Reduction (IETF-DR as Reference Model) - 7-node with 2-Alternate Routing

Network-Wide Reduction in Utilization (Physical Resources Level)- IETF-DR as reference control plnae model


0%

-21%

25%

7%

23%25%

30%

10%7%

-30%

-20%

-10%

0%

10%

20%

30%

40%


SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

162

Figure 12-6: Network-Wide Utilization Percentage Reduction (IETF-DR as Reference Model) - 7-node with 3-Alternate Routing

Network-Wide Reduction in Utilization (Physical Resources Level)- IETF-DR as reference control plnae model


0%

-16%

27%

13%

20%

27%

31%

25%

14%

-20%

-10%

0%

10%

20%

30%

40%


SPA-w/o(NE,IM)

SPA-w/NE,w/oIM

SPA-w/oNE,w/IM

SPA-w/(NE,IM)


% R

educ

tion

in B

lock

ing

Prob

abili

ty

163

13 Discussion of the Impact of SPA Functionality on System

Performance

This section provides detailed analysis of the impact of the five traffic management schemes

of the SPA control plane model on blocking probability, permissible load, and utilization.

The five SPA traffic management schemes are as follows:

1. State-dependent routing traffic management scheme when the routing component is

enabled to perform state-dependent routing.

2. “w/o(NE,IM) traffic management scheme is when configuring LPF to partition the input

load statically (without Network Engineering “w/oNE”) and configuring IMF to disabled

Inverse Multiplexing (without Inverse Multiplexing “w/oIM”) across dedicated and

shared resources.

3. “w/NE,w/oIM” traffic management scheme is when configuring LPF to partition the

input load dynamically (with Network Engineering “w/NE”) and configuring IMF to

disabled Inverse Multiplexing (without Inverse Multiplexing “w/oIM”) across dedicated

and shared resources.

4. “w/oNE,w/IM” traffic management scheme is when configuring LPF to partition the

input load statically (without Network Engineering “w/oNE”) and configuring IMF to

enabled Inverse Multiplexing (with Inverse Multiplexing “w/IM”) across dedicated and

shared resources.

5. “w/(NE,IM) traffic management scheme is when configuring LPF to partition the input

load dynamically (with Network Engineering “w/NE”) and configuring IMF to enabled

Inverse Multiplexing (with Inverse Multiplexing “w/IM”) across dedicated and shared

resources.

13.1 State-Dependent routing impact on blocking probability

As illustrated in Figure 13-1 and Figure 13-15, the state-dependent routing in the SPA control

plane leads to higher reduction in physical resources blocking probability compared to IETF

and ITU static routing. This is related to the state-dependent nature of the SPA routing

component; which would distribute the input load across all the identified routes between a

source-destination pair based on the traffic occupancy of each identified route between a

164

source-destination pair. In both DR and SR, the input traffic between a source-destination

pair is applied to routes regardless of their traffic occupancy state. This would lead to higher

blocking probability and hence lower permissible load if the traffic is applied to routes with

higher occupancy state.

13.2 State-Dependent routing impact on permissible load

As illustrated in Figure 13-6 and Figure 13-20, the state-dependent routing in the SPA control

plane leads to comparable physical resources permissible load to IETF and ITU control plane

models.

13.3 State-Dependent routing impact on utilization

As illustrated in Figure 13-11 and Figure 13-25, the state-dependent routing in the SPA

control plane leads to higher reduction in physical resources utilization compared to IETF-

(DR) and ITU-(DR,SR) control plane models. This is related to the state-dependent nature of

the SPA routing component; which would distribute the input traffic load across all the

identified routes between a source-destination pair based on the traffic occupancy of each

identified route between a source-destination pair, this would lead that the network-wide

occupancy and hence the utilization is less under the same input load. In both IETF and ITU

control plane models, the input load between a source-destination pair is applied to routes

regardless of their traffic occupancy state; this would lead to higher utilization if the load is

applied to routes with higher occupancy state.

13.4 w/o(NE,IM) traffic management scheme impact on blocking probability

As illustrated in Figure 13-2 and Figure 13-16, this traffic management scheme leads to

higher reduction in physical resources blocking probability compared to IETF-SR and ITU-

SR control plane models but lower reduction in physical resources blocking probability

compared to IETF-DR and ITU-DR control plane models. It is important to note that the

reduction in blocking probability using the “w/o(NE,IM)” traffic management scheme is

lower than that achieved by Dedicated traffic management scheme of the SPA control plane

model. This is expected since static load partitioning partitions the load across the dedicated

and shared resources partitions without considering the occupancy state on both partitions.

Thus, a higher load could be applied to network resource partition with higher occupancy

165

state which will lead to a higher blocking probability on the physical resources-level. No

direct affect of increasing sharing ratio on blocking probability was observed for the 7-node

topology.

13.5 w/o(NE,IM) traffic management scheme impact on permissible load

As illustrated in Figure 13-7 and Figure 21, this traffic management scheme leads to

reduction in physical resources permissible load compared to IETF-SR and ITU-(DR,SR)

control plane models. It is important to note that this traffic management scheme provides a

higher permissible load on the VPN resources level compared to the ITU-SR and ITU-

(DR,SR) control plane models as illustrated in Figure 20-23 for the 7-node topology with two

alternate routing, and Figure 21-23 for the 7-node topology with three alternate routing. The


control plane models can be explained be analyzing the permissible load on the dedicated and

shared resources partitions by the “w/o(NE,IM)” traffic management scheme. The

“w/o(NE,IM)” traffic management scheme leads to lowest permissible load on the dedicated

resources partitions compared to other SPA traffic management schemes; this is due to the

static load partitioning and disabled inverse multiplexing features. This is illustrated in the

permissible load plots on the dedicated resources as provided in Appendix-C, D, and E for the

two topologies. Taking into consideration the weighted average formula used to compute the

physical resources permissible load, it is observed that the dedicated resources partition

permissible load has a higher load than the shared resources partition permissible load; thus

the weighted average permissible load on the physical resources will be lowest among the

SPA traffic management schemes. No direct affect of increasing sharing ratio on permissible

load was observed.

13.6 w/o(NE,IM) traffic management scheme impact on utilization


higher reduction in physical resources utilization over IETF-(DR,SR) and ITU-SR control

plane models. It is important to note that the reduction in utilization using the “w/o(NE,IM)

traffic management scheme is higher than that achieved by Dedicated traffic management

scheme. This is expected since each configured VPN service will have higher resources, than

166

IETF and ITU control plane models, by combining dedicated and shared network resources

partitions used by each configured VPN service.

13.7 (w/NE,w/oIM) traffic management scheme impact on blocking probability



SR control plane models but lower reduction in physical resources blocking probability

compared to IETF-DR and ITU-DR control plane models. It is important to note that the

reduction in blocking probability using the “w/NE,w/oIM” traffic management scheme is

higher than that achieved by “w/o(NE,IM)” traffic management scheme. The “w/NE,w/oIM”

traffic management scheme higher reduction in blocking probability than “w/o(NE,IM)”

traffic management scheme is due to the dynamic allocation of input load between dedicated

and shared resources based on dedicated resources blocking probability rather than splitting

the input load statically across dedicated and shared resources based on sharing ratio between

dedicated and shared resources. There is no direct relation between increasing the sharing

ratio and the physical resources blocking probability for the 7-node topology.

13.8 (w/NE,w/oIM) traffic management scheme impact on permissible load



control plane models. This can be explained by analyzing the permissible load on the

dedicated and shared resources partitions, this is illustrated in the permissible load plots on

the dedicated resources as provided in Appendix-C, D, and E for the two topologies. The

“w/NE,w/oIM” traffic management scheme led to lowest permissible load on the dedicated

resources partition and second from lowest on shared resources partition compared to other

SPA traffic management schemes.

Increasing sharing ratio lowers the permissible load on both the 3-alternate and 3-alternate

routing for the 7-node topologies.

13.9 (w/NE,w/oIM) traffic management scheme impact on utilization


higher reduction in physical resources blocking probability compared to IETF-(DR,SR) and

167

ITU-(DR,SR) control plane models. This traffic management scheme leads to the highest

reduction in physical resources utilization. It is important to note that the reduction in

utilization using the “w/NE,w/oIM” traffic management scheme is higher than that achieved

by Dedicated and “w/o(NE,IM)” traffic management schemes. This is expected due to the

dynamic allocation of traffic between dedicated and shared resources based on dedicated

resources blocking probability rather than splitting the input load statically across dedicated

and shared resources based on sharing ratio between dedicated and shared resources.

13.10 (w/oNE,w/IM) traffic management scheme impact on blocking

probability



(DR,SR) control plane models. It is important to note that the reduction in blocking

probability using the “w/oNE,w/IM” traffic management scheme is higher than Dedicated,

“w/o(NE,IM)”, and “w/NE,w/oIM” traffic management schemes. The reason for a higher

reduction in blocking probability when IM is enabled is due to the fact that the incoming

service request flows between a source-destination pair with an actual bandwidth

requirements Akb are split “inverse-multiplexed” into multiple flows each with granular

bandwidth requirement Gkb , each granular flow is routed independently across the available

routes, this leads to lower blocking probability due to the highly probability to grant resources

to service with granular bandwidth requirements than coarse bandwidth requirements.

13.11 (w/oNE,w/IM) traffic management scheme impact on permissible load

As illustrated in Figure 13-9 and Figure 13-23, this traffic management scheme leads to an

increase permissible load over IETF-SR and ITU-(DR,SR) control plane models. This can be

explained due to the lower blocking probability when IM is enabled.

13.12 (w/oNE,w/IM) traffic management scheme impact on utilization

As illustrated in Figure 13-13 and Figure 13-27, this traffic management scheme leads to a

reduction in physical resources utilization over IETF-(DR,SR) and ITU-SR control plane

models. It is important to note that the reduction in utilization using the “w/oNE,w/IM”

traffic management scheme is less than that achieved by Dedicated, “w/o(NE,IM)”, and

168

“w/NE,w/oIM” traffic management schemes. The reason for a higher utilization and hence

lower utilization reduction over IETF and ITU control plane models when IM is enabled is

due to the same reason provided in section 13.10.

13.13 w/(NE,IM) traffic management scheme impact on blocking probability



(DR,SR) control plane models. It is important to note that the reduction in blocking

probability using the “w/(NE,IM)” traffic management scheme is the highest compared to all

other SPA traffic management schemes, this is due to the dynamic allocation of traffic

between dedicated and shared resources, based on the traffic occupancy state, in addition to

enabling Inverse Multiplexing (IM).

13.14 w/(NE,IM) traffic management scheme impact on permissible load

As illustrated in Figure 13-10 and Figure 13-24, this traffic management scheme leads to an

increase in permissible load over IETF-SR and ITU-(DR,SR) control plane models. It is

important to note that the increase in permissible load using the “w/(NE,IM)” traffic

management scheme is less than that achieved by “w/oNE,w/IM” traffic management

scheme. This can be explained by analyzing the permissible load on the dedicated and shared

resources partitions for both the “w/oNE,w/IM” and “w/(NE,IM)” traffic management

schemes. As illustrated in Figure 18-14 and Figure 19-14 for the 7-node topology with 2-

alternate routing and 3-alternate routing respectively, the permissible load is higher in the

“w/(NE,IM)” traffic management scheme than the “w/oNE,w/IM” traffic management

scheme on the dedicated resources partition, but lower in the “w/(NE,IM)” traffic

management scheme than the “w/oNE,w/IM” on the shared resources partition. Using the

weighted average permissible load on the physical resources level, the “w/oNE,w/IM” traffic

management scheme provides higher permissible load than the “w/(NE,IM)” traffic

management scheme. Increasing sharing ratio leads to lower permissible load on the physical

resource level for both 2-alternate and 3-alternate routing for the 7-node topology. This is due

to the higher blocking probability on the physical resources level with increasing the sharing

ratio.

169

13.15 w/(NE,IM) traffic management scheme impact on utilization


reduction in physical resources utilization compared to IETF-(DR,SR) and ITU-SR but lower

reduction in physical resources utilization compared to ITU-DR control plane model. It is

important to note that the reduction in utilization using the “w/(NE,/IM)” traffic management

scheme is less than that achieved by Dedicated, “w/o(NE,IM)”, “w/NE,w/oIM”, and

“w/oNE,w/IM” traffic management schemes. The reason for a higher utilization and hence

lower utilization reduction over ITU control plane model is due to enabled dynamic load

partitioning and inverse multiplexing which will lead to lowest blocking probability and

hence highest utilization among the SPA traffic management schemes.

13.16 Generalizing the performance analysis results

13.16.1 SPA superiority trend based on 4-node and 7-node topologies

In section 11.3, it was proved that both 2-alternate and 3-alternate routing cases for the 7-

node topology gave the same consistent trends for the SPA superiority under specific

operational space as provided in section 11.3.1. In this section, we compare the SPA

superiority trend for both the 4-node and 7-node topologies under the same specific

operational space as provided in section 11.3.1. The following consistent trends were

observed for the blocking probability performance metric:

1. In the 4-node topology, all the five SPA traffic management schemes provide a lower

blocking probability than IETF-DR, IETF-SR, ITU-DR, and ITU-SR.

2. In the 7-node topology and for both 2 and 3 alternate routing, all the five SPA traffic

management schemes provide a lower blocking probability than IETF-SR and ITU-SR.

When IMF is enabled in SPA control plane model to allow inverse multiplexing, the two

related SPA traffic management schemes provide a lower blocking probability than

IETF-DR and ITU-DR.

170

The following consistent trends were observed for the permissible load performance metric:

1. In the 4-node topology, all the five SPA traffic management schemes provide a

comparable permissible load to IETF-DR and ITU-DR. When IMF is enabled to allow

inverse multiplexing, the two related SPA traffic management schemes provide a higher

permissible load than IETF-SR and ITU-SR.

2. In the 7-node topology and for both 2 and 3 alternate routing, the same trend in point 3

was concluded.

The following consistent trends were observed for the utilization performance metric:

1. In the 4-node topology, when IMF is disabled for SPA control plane model, the two

related SPA traffic management schemes provide lower utilization than IETF and ITU

models for both direct and split routing. When IMF is enabled for the SPA control plane

model, the two related SPA traffic management schemes provide higher utilization than

IETF and ITU models except IETF-SR control plane model. SPA-Dedicated control

plane model provides lower utilization than IETF and ITU models except ITU-DR.

2. In the 7-node topology and for both 2 and 3 alternate routing, the same trend in point 5

was concluded.

13.16.2 SPA superiority trend justification based on the performance impact of the SPA

control plane model components

In this section, we justify the SPA superiority trend for other possible topologies than the 4-

node and 7-node topologies that were analyzed in this research, the trend is justified based on

the expected consistent impact of the SPA control plane components on the blocking

probability, permissible load, and utilization performance metrics under specific operational

space as provided in section 11.3.1. As provided below, the SPA control plane components

that were analyzed to justify the SPA control plane model superiority trend are the state-

dependent routing, LPF, and IMF.

1. State-dependent routing component impact on SPA superiority trend:

Blocking probability impact: the state-dependent routing in the SPA control plane

will lead to higher reduction in physical resources blocking probability compared to

IETF and ITU static routing. This is related to the state-dependent nature of the SPA

routing component; which would distribute the input load across all the identified

171

routes between a source-destination pair based on the traffic occupancy of each

identified route between a source-destination pair. In IETF and ITU direct and split

routing, the input load between a source-destination pair is applied to routes

regardless of their traffic occupancy state; this would lead to higher blocking

probability if the traffic is applied to routes with higher occupancy state.

Permissible load impact: the state-dependent routing in the SPA control plane will

lead to comparable or slightly higher physical resources permissible load than the

IETF and ITU control plane models; this is related to the higher blocking probability

reduction by the SPA state-dependent routing component than IETF and ITU static

routing component.

Utilization impact: the state-dependent routing in the SPA control plane will lead to

higher reduction in physical resources utilization compared to IETF-SR and ITU-SR

control plane models, but lower reduction in utilization, higher utilization, compared

to ITU-DR control plane model. This is related to the state-dependent nature of the

SPA routing component; which would distribute the input load across all the

identified routes between a source-destination pair based on the traffic occupancy of

each identified route between a source-destination pair, this would lead that the

network-wide occupancy and hence the utilization is less under the same input load.

In both IETF and ITU control plane models, the input load between a source-

destination pair is applied to routes regardless of their traffic occupancy state; this

would lead to higher utilization if the load is applied to routes with higher occupancy

state.

2. Inverse Multiplexing Function (IMF) impact on SPA superiority trend:

Blocking probability impact: Enabling inverse multiplexing will lead to higher

reduction in blocking probability compared to IETF and ITU control plane models

under both direct and split routing. The reason for a higher reduction in blocking

probability when inverse multiplexing is enabled is due to the fact that the incoming

service request flows between a source-destination pair with an actual bandwidth

requirements Akb are split “inverse-multiplexed” into multiple flows each with

granular bandwidth requirement Gkb , each granular flow is routed independently

172

across the available routes, this leads to lower blocking probability due to the highly

probability to grant resources to service with granular bandwidth requirements than

coarse bandwidth requirements.

Permissible load impact: Enabling inverse multiplexing will lead to higher

permissible load compared to IETF and ITU control plane models under both direct

and split routing. This can be explained due to the lower blocking probability when

inverse multiplexing is enabled.

Utilization impact: Similar to the other SPA traffic management schemes, enabling

inverse multiplexing leads to a reduction in utilization compared to the IETF-(DR,

SR) and ITU-SR traffic management schemes. It is important to note that enabling

inverse multiplexing will lead to a lower reduction in utilization compared to the

other SPA-Shared control plane model with disabled inverse multiplexing. The

reason for a higher utilization and hence lower utilization reduction compared to

IETF and ITU control plane models when inverse multiplexing is enabled is due to

the same reason provided for the blocking probability reduction when inverse

multiplexing is enabled.

173

Figure 13-1: Average Network-Wide Blocking Probability (Physical Resources)-7 Node-2 Alternate Route- IETF (DR, SR), ITU (DR, SR), SPA-Dedicated

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Blocking Probability (Physcial Resources)

2-Alternate Routing, Class-B Arrivals, IETF(DR,SR), ITU(DR,SR), SPA-Dedicated

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3.SPA- Dedicated4. ITU-SR5. IETF-SR

Blocking Key Takeaways: Enabling direct routing for both IETF and ITU control plane models leads to lower blocking probability than SPA-Dedicated.

174

Figure 13-2: Average Network-Wide Blocking Probability (Physical Resources)-7 Node –2 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Blocking Probability (Physical Resources)

2-Alternate Routing, Class-B Arrivals, IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility

SPA-w/o(NE,IM )-4S ITU-DR ITU-SR IETF-DRIETF-SR SPA-w/o(NE,IM )-1S SPA-w/o(NE,IM )-2S SPA-w/o(NE,IM )-3S

Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3. SPA- w/o(NE,/IM)-1S4. SPA- w/o(NE,/IM)-3S5. SPA- w/o(NE,/IM)-4S6. SPA- w/o(NE,/IM)-2S7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Disabling NE & IM under any sharing ratio leads to higher blocking probability than both IETF-DR and ITU-DR, but lower blocking probability that IETF-SR and ITU-SR2. Increasing sharing ratio leads to higher blocking probability on the SPA-w/o(NE,IM)

175

Figure 13-3: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)


2-Alternate Routing, Class-B Arrivals, IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,w/oIM)-4S ITU-DR ITU-SR IETF-DRIETF-SR SPA-(w/ NE,w/oIM)-1 S SPA-(w/ NE,w/oIM)-2S SPA-(w/ NE,w/oIM)-3S

Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3. SPA- (w/NE,w/o/IM)-1S4. SPA- (w/NE,w/o/IM)-3S5. SPA- (w/NE,w/o/IM)-2S6. SPA- (w/NE,w/o/IM)-4S7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling NE only under any sharing ratio leads to higher blocking probability than both IETF-DR and ITU-DR, but lower blocking probability that IETF-SR and ITU-SR2. Increasing sharing ratio has no direct effect on blocking probability on the SPA-(w/NE,w/oIM)

176

Figure 13-4: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)


2-Alternate Routing, Class-B Arrivals, IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility

SPA-(w/o NE,w/IM)-4S ITU-DR ITU-SR IETF-DRIETF-SR SPA-(w/o NE,w/IM)-1S SPA-(w/o NE,w/IM)-2S SPA-(w/o NE,w/IM)-3S

Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- (w/oNE,w//IM)-4S2. SPA- (w/oNE,w//IM)-3S3. SPA- (w/oNE,w//IM)-2S4. SPA- (w/oNE,w//IM)-1S5. ITU-DR6. IETF-DR7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling IM under any sharing ratio leads to lower blocking probability than IETF-DR, ITU-DR, IETF-SR, and ITU-SR2. Under lower input loads, Increasing sharing ratio leads to lower bocking probability on the SPA-(w/oNE,w/IM)

177

Figure 13-5: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 2 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)


2-Alternate Routing, Class-B Arrivals, IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,IM)-4S ITU-DR ITU-SR IETF-DRIETF-SR SPA-(w/ NE,IM)-1S SPA-(w/ NE,IM)-2S SPA-(w/ NE,IM)-3S

Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- w/(NE,IM)-1S2. SPA- w/(NE,IM)-2S3. SPA- w/(NE,IM)-3S4. SPA- w/(NE,IM)-4S5. ITU-DR6. IETF-DR7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling both NE & IM under any sharing ratio leads to lower blocking probability than IETF-DR, ITU-DR, IETF-SR, and ITU-SR2. Enabling NE in addition to IM leads to lower blocking probability.

178

Figure 13-6: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-Dedicated

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (Physcial Resources)


0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. SPA-Dedicated4. IETF-SR5. ITU-DRUnder any given input load:1. No significant permissable load advantage of the SPA-Dedicated over both IETF-DR and ITU-DR2. ITU-DR & IETF-DR provides a lower permissable load than (IETF-SR,ITU-SR, and SPA-Dedicated

Permissible load Key Takeaways: 1. Split routing provides higher PL than direct routing for both IETF and ITU control plane models.

179

Figure 13-7: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2 Alternate Route- IETF(DR,SR), ITU(DR,SR),

SPA-w/o(NE,IM)

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (Physical Resources)


0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-w/o(NE,IM)-2S2. SPA-w/o(NE,IM)-4S3. SPA-w/o(NE,IM)-3S4. SPA-w/o(NE,IM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-DR

Permissible load Key Takeaways: 1. SPA-w/o(NE,IM) provides lower permissable loadcompred to IETF and ITU models under both direct and split routing.

180

Figure 13-8: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 2 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

Per-

Pair

Perm

issi

ble

Load

SPA-(w/ NE,w/oIM)-4S ITU-DR ITU-SR IETF-SRIETF-SR SPA-(w/ NE,w/oIM)-1 S SPA-(w/ NE,w/oIM)-2S SPA-(w/ NE,w/oIM)-3S

Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-(w/NE,w/oIM)-4S2. SPA-(w/NE,w/oIM)-2S3. SPA-(w/NE,w/oIM)-3S4. SPA-(w/NE,w/oIM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-DR

Permissible load Key Takeaways: 1. SPA-(w/NE,w/oIM) provides a lower permissable load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/NE,w/oIM) model, increasing sharing ratio leads to lower permissable load

181

Figure 13-9: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 2 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. ITU-DR5. SPA-(w/oNE,w/IM)-1S6. SPA-(w/oNE,w/IM)-2S7. SPA-(w/oNE,w/IM)-3S8. SPA-(w/o/NE,w/IM)-4S

Permissible load Key Takeaways: 1. SPA-(w/oNE,w/IM) provides a higher permissable load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/oNE,w/IM) model, increasing sharing ratio leads to higher permissable load3. The significane of sharing ratio of SPA-(w/oNE,w/IM) on permissable load is not major when sharing is above 2 STS.

182

Figure 13-10: Average Network-Wide Permissible Load (Physical Resources)-7 Node –2 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. IETF-SR5. SPA-w/(NE,IM)-4S6. SPA-w/(NE,IM)-3S7. SPA-w/(NE,IM)-2S8. SPA-w/(NE,IM)-1S

Load Key Takeaways: 1. SPA-w/(NE,IM) provides a higher permissable load compred to IETF and ITU models under both direct and split routing.2. For SPA-w/(NE,IM) model, increasing sharing ratio leads to lower permissable load3. The significane of sharing ratio of SPA-w/(NE,IM) on permissable load is higher than SPA-(w/oNE,w/IM) model

183

Figure 13-11: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM)

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Utilization (Physical Resources)

2-Alternate Routing, Class-B Arrivals, IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM)

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n

IETF-DR IETF-SR ITU-DR ITU-SR SPA-DedicatedSPA-w/o(NE,IM )-1S SPA-w/o(NE,IM )-2S SPA-w/o(NE,IM )-3S SPA-w/o(NE,IM )-4S

Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-w/o(NE,IM)3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-w/o(NE,IM) and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-SR, and SO-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

184

Figure 13-12: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM


2-Alternate Routing, Class-B Arrivals, IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n

IETF-DR IETF-SR ITU-DRITU-SR SPA-Dedicated SPA-(w/ NE,w/oIM)-1 SSPA-(w/ NE,w/oIM)-2S SPA-(w/ NE,w/oIM)-3S SPA-(w/ NE,w/oIM)-4S

Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-(w/NE,w/oIM)3. SPA-Dedicated4. ITU-SR5. IETF-DR6 IETF-SR

Utilization Key Takeaways: Under SPA-(w/NE,w/oIM) and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-SR, and SO-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

185

Figure 13-13: Average Network-Wide Utilization (Physical Resources)-7 Node –2 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM


2-Alternate Routing, Class-B Arrivals, IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load

Phys

ical

Res

ourc

es U

tiliz

atio

n

IETF-DR IETF-SR ITU-DRITU-SR SPA-Dedicated SPA-(w/o NE,w/IM)-1SSPA-(w/o NE,w/IM)-2S SPA-(w/o NE,w/IM)-3S SPA-(w/o NE,w/IM)-4S

Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-Dedicated3. SPA-(w/oNE,w/IM)4. ITU-SR5. IETF-DR6 IETF-SR

Utilization Key Takeaways: Under SPA-(w/oNE,w/IM) and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-SR, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

186

Figure 13-14: Average Network-Wide Utilization (Physical Resources)-7 Node – 2 Alternate Route-IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM)


2-Alternate Routing, Class-B Arrivals, IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM)

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n

IETF-DR IETF-SR ITU-DR ITU-SR SPA-DedicatedSPA-(w/ NE,IM)-1S SPA-(w/ NE,IM)-2S SPA-(w/ NE,IM)-3S SPA-(w/ NE,IM)-4S

Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-Dedicated3. ITU-SR4. SPA-w/(NE,IM)5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-w/(NE,IM) and same input load:1. All sharing ratios provide higher utilization than ITU-(DR,SR) and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR, and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

187

Figure 13-15: Average Network-Wide Blocking Probability (Physical Resources)-7 Node-3 Alternate Route- IETF (DR, SR), ITU (DR, SR), SPA-Dedicated



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3. SPA- Dedicated4. ITU-SR5. IETF-SR

Blocking Key Takeaways: Enabling direct routing for both IETF and ITU control plane models leads to lower blocking probability than SPA-Dedicated.

188

Figure 13-16: Average Network-Wide Blocking Probability (Physical Resources)-7 Node –3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3. SPA- w/o(NE,/IM)-1S4. SPA- w/o(NE,/IM)-3S5. SPA- w/o(NE,/IM)-4S6. SPA- w/o(NE,/IM)-2S7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Disabling NE & IM under any sharing ratio leads to higher blocking probability than both IETF-DR and ITU-DR, but lower blocking probability that IETF-SR and ITU-SR2. Increasing sharing ratio leads to higher blocking probability on the SPA-w/o(NE,IM)

189

Figure 13-17: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. ITU-DR2. IETF-DR3. SPA- (w/NE,w/o/IM)-3S4. SPA- (w/NE,w/o/IM)-1S5. SPA- (w/NE,w/o/IM)-4S6. SPA- (w/NE,w/o/IM)-2S7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling NE only under any sharing ratio leads to higher blocking probability than both IETF-DR and ITU-DR, but lower blocking probability that IETF-SR and ITU-SR2. Increasing sharing ratio has no direct effect on blocking probability on the SPA-(w/NE,w/oIM)

190

Figure 13-18: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- (w/oNE,w//IM)-4S2. SPA- (w/oNE,w//IM)-3S3. SPA- (w/oNE,w//IM)-2S4. SPA- (w/oNE,w//IM)-1S5. ITU-DR6. IETF-DR7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling IM under any sharing ratio leads to lower blocking probability than IETF-DR, ITU-DR, IETF-SR, and ITU-SR2. Under lower input loads, Increasing sharing ratio leads to lower bocking probability on the SPA-(w/oNE,w/IM)

191

Figure 13-19: Average Network-Wide Blocking Probability (Physical Resources)-7 Node – 3 Alternate Route-IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- w/(NE,/IM)-1S2. SPA- w/(NE,/IM)-2S3. SPA- w/(NE,/IM)-3S4. SPA- w/(NE,/IM)-4S5. ITU-DR6. IETF-DR7. ITU-SR8. IETF-SR

Blocking Key Takeaways: 1. Enabling both NE & IM under any sharing ratio leads to lower blocking probability than IETF-DR, ITU-DR, IETF-SR, and ITU-SR2. Enabling NE in addition to IM leads to lower blocking probability.3. Under lower input loads, Increasing sharing ratio leads to higher bocking probability on the SPA-w/(NE,IM)

192

Figure 13-20: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-Dedicated

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (Physcial Resources)


0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. SPA-Dedicated4. IETF-SR5. ITU-DRUnder any given input load:1. No significant permissible load advantage of the SPA-Dedicated over both IETF-DR and ITU-DR2. ITU-DR & IETF-DR provides a higher permissible load than (IETF-SR,ITU-SR, and SPA-Dedicated

Permissible Load Key Takeaway:1. Split routing provides higher permissible load than direct routing for both IETF and ITU control plane models.

193

Figure 13-21: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-w/o(NE,IM)-2S2. SPA-w/o(NE,IM)-4S3. SPA-w/o(NE,IM)-3S4. SPA-w/o(NE,IM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-DR

Permissible Load Key Takeaway:1. SPA-w/o(NE,IM) provides lower permissible load compred to IETF and ITU models under both direct and split routing.

194

Figure 13-22: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-(w/NE,w/oIM)-4S2. SPA-(w/NE,w/oIM)-2S3. SPA-(w/NE,w/oIM)-3S4. SPA-(w/NE,w/oIM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-DR

Permissible Load Key Takeaway:1. SPA-(w/NE,w/oIM) provides a lower permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/NE,w/oIM) model, increasing sharing ratio leads to lower permissible load

195

Figure 13-23: Average Network-Wide Permissible Load (Physical Resources)-7 Node – 3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. ITU-DR5. SPA-(w/oNE,w/IM)-1S6. SPA-(w/oNE,w/IM)-2S7. SPA-(w/oNE,w/IM)-3S8. SPA-(w/o/NE,w/IM)-4S

Permissible Load Key Takeaway:1. SPA-(w/oNE,w/IM) provides a higher permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/oNE,w/IM) model, increasing sharing ratio leads to higher permissible load 3. The significane of sharing ratio of SPA-(w/oNE,w/IM) on permissible load is not major when sharing is above 2 STS.

196

Figure 13-24: Average Network-Wide Permissible Load (Physical Resources)-7 Node –3 Alternate Route- IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. IETF-SR5. SPA-w/(NE,IM)-4S6. SPA-w/(NE,IM)-3S7. SPA-w/(NE,IM)-2S8. SPA-w/(NE,IM)-1S

Permissible Load Key Takeaway:1. SPA-w/(NE,IM) provides a higher permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-w/(NE,IM) model, increasing sharing ratio leads to lower permissible load 3. The significane of sharing ratio of SPA-w/(NE,IM) on permissible load is higher than SPA-(w/oNE,w/IM) model

197

Figure 13-25: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM)



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-w/o(NE,IM)3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-w/o(NE,IM) and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-SR, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

198

Figure 13-26: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. SPA-(w/NE,w/oIM)2. ITU-DR3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-(w/NE,w/oIM) with higher sharing ratio and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-(DR,SR), and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

199

Figure 13-27: Average Network-Wide Utilization (Physical Resources)-7 Node –3 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM



10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-Dedicated3. SPA-(w/oNE,w/IM)4. ITU-SR5. IETF-DR6 IETF-SR

Utilization Key Takeaways: Under SPA-(w/oNE,w/IM) and same input load:1. All sharing ratios provide lower utilization than IETF-(DR,SR), ITU-SR, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

200

Figure 13-28: Average Network-Wide Utilization (Physical Resources)-7 Node – 3 Alternate Route-IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM)



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-Dedicated3. ITU-SR4. SPA-w/(NE,IM)5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-w/(NE,IM) and same input load:1. All sharing ratios provide higher utilization than IETF-(DR,SR) models.2. SPA-Dedicated provides lower utilization than IETF-(DR,SR) and ITU-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

201

14 Conclusions

The performance analysis of the proposed Service Profile-Aware control plane model proved

its superiority compared to the IETF and ITU control plane models under specific operational

space as provided in section 11.3.1. Through its accurate realization of both service profile

layer parameters and network infrastructure multi-granularity detailed resources

representation, the architectures and functional operation of the Service-Profile Aware control

plane components provide significant harmony between the network infrastructure resources

and service profile parameters. This harmony resulted in the SPA control plane model

superiority, under specific operational space as provided in section 11.3.1, in the following

aspects while considering the IETF-DR as a reference control plane model:


in blocking probability compared to the IETF-SR and ITU-(DR,SR) control plane

models. The increase in blocking probability reduction is 0-131% and 39-122%

respectively; depending on the SPA traffic management scheme, SPA number of

alternate routes, and the IETF/ITU static routing configuration (direct routing vs. split

routing).

2. All the traffic management schemes of the SPA control plane, except when IMF is

disabled, provide a higher increase in permissible load compared to the IETF-SR and

ITU-(DR,SR) control plane models. The increase in permissible load is 120-134% and

110-120% respectively; depending on the SPA traffic management scheme, SPA number

of alternate routes, and the IETF/ITU static routing configuration (direct routing vs. split

routing).


in utilization compared to the IETF-(DR,SR) and ITU-(DR,SR) traffic management

schemes; the increase in utilization reduction is 7-31% depending on the SPA traffic

management scheme, and SPA number of alternate routes.

It was observed that since the architectures and functional operation of the control plane

components for existing IETF and ITU control plane models lack the service profile layer

parameters consideration, this led to a lack of harmony between the service profile layer,

202

control plane layer, and network infrastructure layer. This lack of harmony led to inefficient

utilization of network resources especially under operation scenarios requiring dynamic

allocation of network resources for differentiated services.

Clearly the need to establish network connections in a service profile-aware fashion is

beneficial and will become increasingly important for future wired and wireless client

networks. The architectures and functional operation of future control plane models will have

to take into account a number of service profile parameters and network constraints to

efficiently utilize network resources, this will play a key role under a networking scenario

where a multi-service operation in common network infrastructure is assumed. Under such

scenario, efficient algorithms and protocols for service profile-differentiation and dynamic

allocation of network resources by the control plane is a must.

15 Next Steps - Future Related Work

The most potential next step related to this dissertation is analyzing the advantages of the

SPA traffic management schemes over IETF and ITU control plane models for multi-domain

network topologies. Two possible approaches for multi-domain analysis are possible; a

mathematical and simulation approach.

Regarding the mathematical approach, a new routing architecture needs to be proposed to

overcome the limitations of the routing probability approximation as used in [68]. As

described in the dissertation, the routing component in the SPA control plane model is state-

dependent in its computation of the routing probability for each identified route in the

network topology. The mathematical formulation used in [68] to compute the state-

dependent routing probability mrkq for each route mr lacks the accuracy needed when

computing routing probability under large network topologies with higher level of meshing

among routes. Recall the mathematical equation used to compute the routing probability as

follows:

∑ ∏∏=

+

=

+=

−=

=

−−=)(

01

1

1

1

min

)](~Pr[)].(Pr[)].(Pr[m rrC

nm

Dnmk

Dn

Mk

mkmk

Dn

mk

k

mDrk rArrArrAq

203




nmkD


nmkD


on link-disjoint between routes for a source-destination pair node would limit the flexibility

of selecting link-disjoint routes under a large network topology especially for non-meshed

network topologies.

The current routing architecture assumed in the SPA control plane model is a flat routing

architecture; a hierarchal routing architecture is a proposed alternative to overcome the link-

disjoint route limitation. The hierarchal routing architecture by the control plane is another

logical representation of the network infrastructure layer compared to the flat routing

architecture. In other words, the same infrastructure layer topology can be represented

logically by two different flat vs. hierarchal routing architectures. As described in details in

section 5.1 on horizontal view of the network topology from a multi-domain realization, the

large network topology can be segmented into sub-networks or network domains. From a

routing architecture perspective, network topology segmenting into sub-networks results into

routing architecture segmenting in Routing Areas (RAs). A hierarchal routing architecture

can be used to connect multiple routing areas in a hierarchical architecture.

A routing architecture is a logical representation of the transport network, the routing

architecture can be flat or hierarchal based on the scale of the transport network, geographic

and administrative constraints, or technological boundaries. Thus, the decision to implement

a hierarchal vs. flat routing architecture for a control plane instance is not based on the

transport topology granularity levels controlled by the control plane instance. For an N

control plane instances, we can have N control plane routing architecture instances, each one

of the routing architecture instances can be hierarchically or flat represented.

Building on the Control Plane Instance (CPI) concept described in section 5 for the three

control plane models; from a hierarchal routing architecture perspective, a control plane

instance can be described as a collection of Routing Areas (RAs) and Routing Levels (RLs),

204

in the case of hierarchical routing architecture. Figure 15-1 illustrates two transport network

subnetworks represented by two routing areas; the boundaries of the routing areas are

connected by a connection link. A physical network topology can be recursively partitioned

into subnetworks. Partitioning in the transport plane leads to multiplicity of routing areas in

the control plane. Recursive partitioning principles leads to hierarchical organization of

routing areas into multiple levels. Routing Areas follow the organization of subnetworks.

The internal topology of a sub-network is completely opaque to the outside. For routing

purposes, the sub-network may appear as a node (reachability only), or may be transformed

to appear as some set of nodes and links, in which case the sub-network is not visible as a

distinct entity. Methods of transforming sub-network structure to improve routing

performance will likely depend on sub-network topology.

Figure 15-1: Hierarchical Routing Architecture

205


As described in sections 5.3 5.3.1 and 6.1, the IETF control plane model represents the

transport network multiple partitions by one control plane instance. Figure 15-2 illustrates the

IETF control plane representation of transport network multiple partitions.

Figure 15-2: IETF Control Plane Representation for Multi-Domain Network Architecture


As described in sections 5.3.2 and 6.2, the ITU and SPA-Dedicated control plane models

represents the transport network multiple partitions by multiple control plane instances.

Figure 15-3 illustrates the two models representation of transport network multiple partitions.

Each control plane instance is a group of RAs that can be represented by a hierarchal routing

architecture. It is important to note that both models routing and capacity allocation decisions

made by the multiple control plane instances are not correlated. In other words, the multiple

control plane instances function independently of each other and hence no topology exchange

across the parallel control plane instances takes place; thus no Load Partitioning Function

(LPF) is implemented.

15.3 SPA control plane model

The SPA-Dedicated control plane model builds on the ITU control plane model but with

state-dependent routing for each control plane instance with its hierarchal routing

One Control Plane Instance with one Hierarchal Routing Instance for the Three Transport Network PartitionsIETF Control Plane Model




206

architecture. In the SPA-Shared control plane model, a LPF is implemented between the

control plane instances as illustrated in Figure 15-4.

Figure 15-3: ITU & SPA-Dedicated Control Plane Models Representation for Multi-Domain

Network Architecture

Three Control Plane Instance with Three Hierarchal Routing Instances for the Three Transport Network PartitionsNo inter-control plane instances resource sharing via Load Partitioning Function (LPF)

ITU/SPA-Dedicated Control Plane Models




207

Figure 15-4: SPA-Shared Control Plane Representation of Multi-Domain Network

Architecture

SPA-Shared Control Plane ModelThree Control Plane Instance with Three Hierarchal Routing Instances for the Three Transport Network Partitions


CPICPI--AA

CPICPI--CC

CPICPI--BB

Resource Sharing via LPFResource Sharing via LPF

Resource Sharing via LPFResource Sharing via LPF




208

16 References

16.1 Journals & papers

16.1.1 Single-Domain control plane function analysis

[1] Jong-Moon Chung; Khan, H.K.; Hooi Miin Soo; Reyes, J.S.; Cho, G.Y.; Analysis of

GMPLS architectures, MWSCAS-2002. The 2002 45th Midwest Symposium on topologies

and algorithms, Volume: 3 , 4-7 Aug. 2002 , Page(s): III-284 -III-287 vol.3

[2] Pin-Han Ho; Mouftah, H.T.; Path selection with tunnel allocation in the optical Internet

based on generalized MPLS architecture, ICC 2002. IEEE International Conference on

Communications, 2002 , Volume: 5 , 28 April-2 May 2002, Page(s): 2697 -2701 vol.5

[3] Jong-Moon Chung; Hooi Miin Soo; Jitter analysis of homogeneous traffic in

differentiated services networks, IEEE Communications Letters, Volume: 7 Issue: 3 , March

2003, Page(s): 130 -132

[4] Ozugur, T.; Verchere, D; Congestion control mechanism using LSP differentiation for

label-switched optical burst networks, IP Operations and Management, 2002 IEEE Workshop

on , 2002 Page(s): 31 -36

[5] Tomic, S.; Jukan, A.; GMPLS-based exchange points: architecture and functionality, .

Workshop on High Performance Switching and Routing, 2003, June 24-27, 2003, Page(s):

245 -249

16.1.2 Next-Generation SONET

[6] M. Simcoe, A layered Architecture for Metro optical Networks, National Fiber Optic

Engineers Conference (NFOEC) 2000, Denver, CO, August 2000

[7] F. Moore, Extending the LAN to the Transport Network, National Fiber Optic Engineers

Conference (NFOEC) 2000, Denver, CO, August 2000

[8] Optical Edge Networks: Market Opportunities for Integrated Optical Network Solutions

in Metro Networks, Pioneer Consulting Report, July 2000

[9] B. Rajagopapaln, et al., IP over Optical Networks: Architectural Aspects, IEEE

Communications Magazine, Vol. 39, No. 1, January 2001, pp. 144-150

[10] S. Wilkinson, Metropolitan Area Transport Requirements, National Fiber Optic

Engineers Conference (NFOEC) 2000, Denver, CO, August 2000

209

[11] L. Castellon, T., Rado, The Future of SONET, National Fiver Optic Engineers

Conference (NFOEC), Denver, CO, August 2000

[12] N. Golmi, T. Ndousse, D. Su, A Differentiated Optical Services Model for WDM

Networks, IEEE Communications Magazine, Vol. 38, No. 2, February 2000, pp. 68-73.

[13] Metro Optical Networks: Metro DWDM and the New Public Network”, Pioneer

Consulting Report, 1999

[14] G. A. Young, Planning SONET Architecture for Improved Capacity Utilization,

National Fiber optic Engineers Conference (NFOEC) 1998, Orlando, FL, September 1998.

16.2 Standards recommendations

16.2.1 ITU-T optical control building blocks generic architecture

[15] ITU-T Rec. G.8080/Y.1304, Architecture for the Automatic Switched Optical Network

(ASON)

[16] ITU-T G.8080/Y.1304 Incorporating Amendment.

[17] ITU-T Rec. G.7713/Y.1704, Distributed call and connection management

[18] ITU-T Rec. G.7714/Y.1705, Generalized automatic discovery techniques

[19] ITU-T Rec. G.7715, Architecture and Requirements for routing the ASON

[20] ITU-T Rec. G.7042/Y.1305, Link capacity adjustment scheme (LCAS) for virtual

concatenated signals.

[21] ITU-T Rec. G.707, Virtual Concatenation

16.2.2 ITU-T protocol specific implementations

[22] ITU-T Rec. G.7713.2, ASON distributed call and connection management signaling

mechanism using GMPLS RSVP-TE

[23] ITU-T Rec. G.7713.3, ASON distributed call and connection management signaling

mechanism using GMPLS CR-LDP

[24] ITU-T Rec. G.7715.1, ASON routing architecture and requirements for links state

protocols

[25] ITU-T Rec. G.7714.1, Protocol for automatic discovery in SDH and OTN networks.

[26] Framework for Layer 1 Virtual Private Networks, draft-takeda-l1vpn-framework-03

210

16.2.3 ITU-T optical transport standards

[27] ITU-T Rec. G.872, “Architecture of Optical Transport Networks” (OTN)

[28] ITU-T Rec. G.8070/Y.1301, Requirements for Automatic Switched Transport Networks

(ASTN)

[29] ITU-T Rec. G.7714, Generalized Automatic Discovery Techniques

[30] ITU-T Rec. G.7712/Y.1703, Data Communications Network

[31] ITU-T Rec. G.798, “Characteristics of Optical Transport Network (OTN) Hierarchy

Equipment functional Blocks”

[32] ITU-T Rec. G.874, “Management Aspects of the Optical Transport Network Element”

[33] ITU-T Rec. G.693, “Optical Interfaces for Intra-Office Systems”

16.2.4 IETF GMPLS building blocks specific protocols

[34] IETF RFC 3945- Generalized Multi-Protocol Label Switching Architecture

[35] IETF RFC 3471, Generalized Multi-Protocol Label Switching (GMPLS) Signaling

Functional Description.


Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions.


Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions

[38] IETF draft-Routing Extensions in Support of Generalized MPLS, draft-ietf-ccamp-

gmpls-routing-09

[39] IETF OSPF Extensions in Support of Generalized MPLS, draft-ietf-ccamp-ospf-gmpls-

extensions-11, October 2003

[40] IETF draft, Generalized MPLS Signaling Extensions for G.709 Optical Transport

Networks Control, draft-ietf-ccamp-gmpls-g709-09

[41] IETF draft, Framework for GMPLS-based Control of SDH/SONET Networks, draft-ietf-

ccamp-sdhsonet-control-02

[42] G.Berstein, E. Mannie, V.Sharma, Framework for MPLS-based Control of Optical

SDH/SONET Networks, IETF Draft, Draft-bms-optical-sdhsonet-mpls-contro-frmwrk-00,

November 2000

211

[43] IETF Requirements for Generalized MPLS (GMPLS) Usage and Extensions for

Automatically Switched Optical Network (ASON), draft-ietf-ccamp-gmpls-ason-reqts-05,

October 2004

16.3 Traffic allocation and resource partitioning schemes

[44] FOSCHINI, G.J., GOPINATH, B. AND HAYES, J.F. (1981) Optimum allocation of

servers to two types of competing customers. IEEE Trans. Comm. COM-29, 1051-1055.

[45] GOPAL, 1.S. AND STERN, T.E. (1983) optimal call blocking policies in an integrated

services environment. Proceedings of the Conference on Information Sciences and Systems,

Johns Hopkins University, 383-388.

[46] KRAIMECHE, B. AND SCHWARTZ, M. (1984) Traffic access control strategies in

integrated digital networks. Proceedings of Infocom '84, 230-235.

[47] FLOYD, S. AND JACOBSON, V. (1995) Link-sharing and resource management

models for packet networks. IEEE/ACM Trans. Networking 3(4), 365-386.

[48] ASH, G.R., CHEN, J.S., FREY, A.E. AND HUANG, B.D. (1991) Real-time network

routing in an integrated network. Proceedings of the International Teletraffic Congress (ITC-

13), Copenhagen.

[49] BORST, S. AND MITRA, D. (1997) Virtual partitioning for resource sharing by state-

dependent priorities: analysis, approximations, and performance for heterogeneous traffic. In

Teletraffic Contributions for the Information Age, Proc. ITC-15, ed. V. Ramaswami and P. E.

Wirth, Elsevier, 1457-1468.

[50] KELLY, F.P. (1991) Loss networks. Ann. Appl. Prob. 1, 319378.

[51] MITRA, D., REIMAN, M. 1. AND WANG, J. (1997) Robust admission control for

heterogeneous ATM systems with both cell and call QoS requirements, In Teletraffic

Contributions for the Information Age, Proc. ITC-15, ed. V. Ramaswami and P. E. Wirth,

Elsevier, 1421-1432.

[52] KUMARAN, K. AND MITRA, D. (1997) Performance and fluid simulations of a novel

shared buffer management system. Submitted to INFO COM 98.

[53] MITRA, D. AND ZIEDINS, 1. (1997) Hierarchical virtual partitioning: Algorithms for

virtual private networking. Bell Labs Tech. J. 2(2), 68-81.

[54] KAUFMAN, J.S. (1981) Blocking in a shared resource environment. IEEE Trans.

Commun. 29, 1471-1481.

212

[55] ROBERTS, J. W. (1981) A service system with heterogeneous service requirements. In:

Performance of Data Communications Systems and their Applications. (ed. G. Pujolle)

North-Holland, Amsterdam. 423-431.

[56] ROBERTS, J.W. (1983) Teletraffic models for the Telecom 1 integrated services

network. In: Proc. ITC-l 0, session 1.1. Ross, K. (1995) Multirate Loss Models for Broadband

Telecommunications Networks. Springer.

[57] BEAN, N.G., GIBBENS, R.G. AND ZACHARY, S. (1995) Asymptotic analysis of

single resource loss systems in heavy traffic, with applications to integrated networks. Adv.

Appl. Prob. 27, 273-292.

[58] BORST, S. AND MITRA, D. (1997) Virtual partitioning for resource sharing by state-

dependent priorities: analysis, approximations, and performance for heterogeneous traffic. In

Teletraffic Contributions for the Information Age, Proc. ITC-15, ed. V. Ramaswami and P. E.

Wirth, Elsevier, 1457-1468.

16.4 Fixed point approximation for multi-rate loss networks

[59] KELLY, F.P. (1991) Loss networks. Ann. Appl. Prob. 1, 319-378.

[60] “Blocking probabilities in large circuit switched networks,” Adv. Applied. Probabilities,

vol. 18, pp. 473–505, 1986.

[61] S. Chung and K. W. Ross, “Reduced load approximations for multirate loss networks,”

IEEE Trans. Commun., vol. 41, pp. 1222–1231, Aug. 1993.

[62] D. Mitra, R. Gibbens, and B. D. Huang, “State-dependent routing on symmetric loss

networks with trunk reservations I,” IEEE Trans. Commun., vol. 41, pp. 400–411, Feb. 1993.

[63] A. G. Greenberg and R. Srikant, “Computational techniques for accurate performance

evaluation of multirate, multihop communication networks,” IEEE/ACM Trans. Networking,

vol. 5, pp. 266–277, Feb. 1997.

[64] W. Whitt, “Blocking when service is required from several facilities simultaneously,”

AT&T Tech. J., vol. 64, no. 8, pp. 1807–1857, 1985.

[65] A. Girard and M. A. Bell, “Blocking evaluation for networks with residual capacity

adaptive routing,” IEEE Trans. Commun., vol. 37, pp.1372–1380, Dec. 1989.

[66] P. J. Hunt, “Implied costs in loss networks,” Adv. Applied. Probabilities, vol.21, pp.

661–680, 1989.

213

[67] F. P. Kelly, “Routing and capacity allocation in networks with trunk reservation,” Math.

Oper. Res., vol. 15, pp. 771–793, 1990.

[68] Mingyan Liu, John S. Baras, " Fixed Point Approximation for Multirate Multihop Loss

Networks With State-Dependent Routing ", IEEE/ACM Transactions on Networking, no. 2,

March 2004

[69] J. S. Kaufman, “Blocking in a shared resource environment,” IEEE Trans. Commun.,

vol. 29, pp. 1474–1481, Aug. 1981.

[70] Gibbens, R.J., Hunt, P.J. and Kelly, F.P. (1990) Bi-stability in communications

networks, Oxford University Press, Oxford, 113-127

[71] I. Ziedins and F. Kelly. Limit theorems for loss networks with diverse routing. Adv.

Applied Probabilities. 21, 804–830, 1989.

[72] N. G. Bean, R. J. Gibbens, and S. Zachary, “The performance of single resource loss

systems in multiservice networks,” in The Fundamental Role of Teletraffic in the Evolutionof

Telecommunications Networks, Proceedings of the 14th International Teletraffic Congress

ITC 14, J. Labetoulle and J. W. Roberts, Eds. New York: Elsevier Science B.V., June 1994,

vol. 1a, Teletraffic Science and Engineering, pp. 13–21.

[73] N. B. Bean, R. J. Gibbens, and S. Zachary, “Asymptotic analysis of single resource loss

systems in heavy traffic, with applications to integrated networks,” Adv. Appl. Probabil., pp.

273–292, Mar. 1995.

16.5 Optical networking market analysis

[74] R. Boncek, et al., “Fiber and Systems for Metropolitan Optical Networks,” National

Fiber Optic Engineers Conference (NFOEC), Orlando, FL, September 1998

[75] Optical Edge Networks: Market Opportunities for Integrated Optical Network Solutions

in Metro Networks,” Poineer Consulting Report, July 2000

[76] B. S. Arnuad, “Current Optical Network Designs May Be Flawed,”, Optical Networks

Magazine, Vol. 2, No. 2, March/April 2000, pp. 21-28

[77] B. St. Arnuad, “Overview of Latest Development in Optical Internets,” Optical

Networks Magazine, Vol. 1, No. 4, October 2000, pp. 51-54

[78] P.V. Hatton, F. Cheston, “WDM Deployment in the Local Exchange Networks,” IEEE

Communications Magazine, Vol. 36, No. 2, February 1998, pp. 56-61

214

17 Appendix-A: List of Acronyms

Term Description

CAC Connection Admission Control

CC Connection Controller

CP Complete Partitioning

CPI Control Plane Instance

CS Complete Sharing

DR Direct Routing

FDA Fully-meshed Dedicated Actual

FPA Fixed Point Approximation

FSA Fully-mesh Shared Actual

FSG Fully-meshed Shared Granular

IETF Internet Engineering Task Force

IM Inverse Multiplexing

IMF Inverse Multiplexing Function

ITU International Telecommunications Union

LPF Load Partitioning Function

LRM Link Resource Manager

NE Network Engineering

PC Protocol Controller

PDA Point Dedicated Actual

PSA Point Shared Actual

PSG Point Shared Granular

QoS Quality of Service

RA Routing Area

RC Routing Controller

RDB Routing Database

RL Routing Level

SDA Semi-meshed Dedicated Actual

SNC Sub-Network Connection

SNP Sub-Network Point

215

SNPP Sub-Network Point Pool

SONET Synchronous Optical Network

SPA Service Profile-Aware

SR Split Routing

SS Static Sharing

SSA Semi-meshed Shared Actual

SSG Semi-meshed Shared Granular

TP Traffic Policy

VP Virtual Partitioning

VPN Virtual Private Network

216

18 Appendix-B: Pseudo-Code generic algorithms


Define Topology Parameters:

• N=Set of Nodes • J=Set of Links • R= Total number of node pair • Mr= Set of routes allowed between source-destination pair r. • Rm= mth route of the source-destination pair r • Cj= Links j capacity (number of resource units)

Define Arriving Services Parameters:

• K= Classes of service requests • J=Bandwidth demands of service requests • rkλ = Arriving rate of class k on source-destination pair r • kμ = Service rate of class k

Initialize: link admissibility probability jka for all topology links

If IETF Direct Routing Selected:

Set: Routing probability mrkq of direct path for each source-destination pair=1

If IETF Split Routing Selected:

Set: Routing probability mrkq of each path for each source-destination pair=1/Number of

possible paths between source-destination pair

Start Fixed Point Approximation (FPA) Mechanism

Compute: (Per link j, Per class k) arriving rate mrjkλ based routing probability m

rkq

Compute: (Per link j, Per class k) arriving rate jkλ based on all possible rm

Perform: IETF-CAC Mechanism based on initial jka and jkλ

217

Compute: Occupancy probability )(np j for each link j

Compute: New jka based on )(np j for each link j

Loop FPA until jka converges


Define Topology Parameters Per Network Resources Partition:

• N=Set of Nodes • J=Set of Links • R= Total number of node pair • Mr= Set of routes allowed between source-destination pair r. • Rm= mth route of the source-destination pair r • D

jC = Links j capacity (number of resource units)Per Network Resources Partition


• K= Classes of service requests • J=Bandwidth demands of service requests • D

rkλ Arrival rate of class k calls between node pair r for configured VPN service v. • kμ = Service rate of class k

Initialize: link admissibility probability Djka for all topology links

If ITU Direct Routing Selected:

Set: Routing probability mDrkq of direct path for each source-destination pair=1

“Per Network Resources Partition”

If ITU Split Routing Selected:

Set: Routing probability mDrkq of each path for each source-destination pair=1/Number of

possible paths between source-destination pair

“Per Network Resources Partition”

Per Control Plane Instance “FPA Instance”:

218


Compute: (Per link j, Per class k) arriving rate mrDjkλ based routing probability mD

rkq

Compute: (Per link j, Per class k) arriving rate Djkλ based on all possible rm

Perform: ITU-CAC Mechanism based on initial Djka and D

jkλ

Compute: Occupancy probability )(npDj for each link j

Compute: New Djka based on )(npD

j for each link j

Loop FPA until Djka converges

18.3 SPA-Dedicated control plane model





• K= Classes of service requests • J=Bandwidth demands of service requests • D


Initialize: link admissibility probability Djka and mD

rkq for all topology links

Per Control Plane Instance “FPA Instance”:



rkq

219


Perform: ITU-CAC Mechanism based on initial Djka and D

jkλ



j for each link j

Compute: New mDrkq based on new )(npD

j

Loop FPA until Djka and )(npD

j converges

18.4 SPA-Shared control plane model





• K= Classes of service requests • J=Bandwidth demands of service requests • v


Initialize: link admissibility probability Djka and mD

rkq for all topology links

Round1: Per Control Plane Instance “FPA Instance” of the dedicated resources:

Set: Load Partitioning Function (LPF) policy (Static vs. NE)

Set: Inverse Multiplexing Function (IMF) policy (actual Akb vs. granular G

kb )


220


rkq


Perform: SPA-Shared-CAC Mechanism based on initial Djka and D

jkλ



j for each link j


j


j converges

Round2: Per Control Plane Instance “FPA Instance” of the dedicated resources:


Compute: (Per link j, Per class k) arriving rate mrDjkλ based routing probability D

rkB


rkq



jkλ



j for each link j


j


j converges

221

Start Fixed Point Approximation (FPA) Mechanism for Shared Resources


rkq



jkλ



j for each link j


j

Loop FPA until Djka and )(np D

j converges

222

19 Appendix-C: Detailed Modeling Results- 4-Node Topology

19.1 Blocking probability

19.1.1 Dedicated resources

This section provides detailed performance analysis of the network-wide blocking probability

on the dedicated network resources partition for the 4-node topology. The configured VPN

service evaluated is the Fully-meshed Shared Granular (FSF) with the following service

profile layer parameters:

a. Service flow connectivity: configured as “fully-meshed”.

b. Service demand granularity: configured as “granular” with 1 STS-1 granularity level.

c. Load partitioning flexibility: configured as “enabled”.

One input class was evaluated with the following parameters: 2=k , =Akb 2 STS-1,

1=kμ unit time, 4=rkλ calls/unit time. Range of input load for 4-node topology is 10 to 30

Erlangs. The five traffic management schemes of the SPA control plane model are evaluated

as provided in Table 9-1. Four sharing levels are considered as follows:


jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

223

Figure 19-1: Average Network-Wide Blocking Probability (Dedicated Resources)-4 Node – 2 Alternate Route-STS-1 Sharing

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Blocking Probability (Dedicated Resources)

2-Alternate Routing, Class-B Arrivals, STS-1 Sharing

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.02

0.04

0.06

0.08

0.10

0.12

0.14

0.16

0.18

0.20

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,w/oIM)-1 S SPA-w/o(NE,IM )-1S SPA-(w/o NE,w/IM)-1S SPA-(w/ NE,IM)-1S

Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/(NE, IM)3. SPA- w/o (NE,IM)4. SPA- (w/NE, w/o IM)Under 1% network-wide blocking probability at the dedicated resources level:1. SPA-(w/oNE, w/IM) operates with 20 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane

d l t t ith 15 t E l

Blocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reduces the blocking probability2. Enabling Network Engineering (NE) increases the blocking probability3. Enabling NE and disabling IM produces the highest blocking probability. 4. Enabling IM and disabling NE produces the lowest blocking probability.

224




0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.02

0.04

0.06

0.08

0.10

0.12

0.14

0.16

0.18

0.20

Blo

ckin

g Pr

obab

ility

SPA-w/o(NE,IM )-2S SPA-(w/ NE,w/oIM)-2S SPA-(w/o NE,w/IM)-2S SPA-(w/ NE,IM)-2S

Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/(NE, IM)3. SPA- w/o (NE,IM)4. SPA- (w/NE, w/o IM)Under 1% network-wide blocking probability at the dedicated resources level:1. SPA-(w/oNE, w/IM) operates with 25 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 20 extra


225




0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/o (NE,IM)3. SPA- w/(NE, IM) Order swap from previous sharing ratio4. SPA- (w/NE, w/o IM)

Under 1% network-wide blocking probability at the dedicated resources level:1. SPA-(w/oNE, w/IM) operates with 20 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 10 extra Erlangs.


226




0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/o (NE,IM) 3. SPA- w/(NE, IM) 4. SPA- (w/NE, w/o IM)Under 5% network-wide blocking probability at the dedicated resources level:1. SPA-(w/oNE, w/IM) operates with 25 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 15 extra Erlangs.


227

19.1.2 Shared resources


on the shared network resources partition for the 4-node topology. The configured VPN

service evaluated is the Fully-meshed Shared Granular (FSF) with the following service

profile layer parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

228

Figure 19-5: Average Network-Wide Blocking Probability (Shared Resources)-4 Node – 2 Alternate Route-STS-1 Sharing

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Blocking Probability (Shared Resources)


0 5 10 15 20 25 30 35 40Input Load

0.00

0.10

0.20

0.30

0.40

0.50

0.60

Blo

ckin

g Pr

obab

ility

SPA-(w/o NE,w/IM)-1S SPA-w/o(NE,IM )-1S SPA-(w/ NE,w/oIM)-1 S SPA-(w/ NE,IM)-1S

Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM)3. SPA- (w/o NE, w/IM)4. SPA- w/o (NE,IM) Under 1% network-wide blocking probability at the shared resources level:1. SPA-w/(NE, IM) operates with 30 extra Erlangs (input load) than SPA-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 20 extra Erlangs.

Blocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reduces the blocking probability2. Enabling Network Engineering (NE) reduces the blocking probability3. Disabling NE and IM produces the highest blocking probability.4. Enabling NE and IM produces the lowest blocking probability.

229




0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-0.10

0.00

0.10

0.20

0.30

0.40

0.50


Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM)3. SPA- (w/o NE, w/IM)4. SPA- w/o (NE,IM) Under 1% network-wide blocking probability at theShared Resources level:1. SPA-w/(NE, IM) operates with 25 extra Erlangs (input load) than SPA-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 20 extra Erlangs


230




0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

SPA-(w/o NE,w/IM)-3S SPA-w/o(NE,IM )-3S SPA-(w/ NE,w/oIM)-3S SPA-(w/ NE,IM)-3S

Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM)3. SPA- (w/o NE, w/IM)4. SPA- w/o (NE,IM) Under 1% network-wide blocking probability at the Shared Resources level:1. SPA-w/(NE, IM) operates with 40 extra Erlangs (input load) than SPA-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 20 extra Erlangs.


231




0 5 10 15 20 25 30 35 40

Input Load (Erlang"

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,w/oIM)-4S SPA-w/o(NE,IM )-4S SPA-(w/o NE,w/IM)-4S SPA-(w/ NE,IM)-4S



232

19.1.3 VPN resources


on the VPN network resources partition for the 4-node topology. The configured VPN service

evaluated is the Fully-meshed Shared Granular (FSF) with the following service profile layer

parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

233

Figure 19-9: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2 Alternate Route-ITU (DR,SR), SPA-Dedicated

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Blocking Probability (VPN Resources)

2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-Dedicated

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility

SPA-Dedicated ITU-DR ITU-SR

Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- Dedicated2. ITU-SR3. ITU-DRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA-Dedicated operates with 7 extra Erlangs (input load) than ITU-SR.2. SPA-Dedicated operates with 10 extra Erlangs (input load) than ITU-Dedicated.

234

Figure 19-10: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2 Alternate Route- ITU (DR,SR), SPA-w/o(NE,IM)


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-w/o(NE,IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility

ITU-SR SPA-w/o(NE,IM )-3S ITU-DR SPA-w/o(NE,IM )-1S SPA-w/o(NE,IM )-2S SPA-w/o(NE,IM )-4S

Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- w/o(NE,IM)-4S 2. SPA- w/o(NE,IM)-3S3. ITU-SR4. ITU-DR5. SPA- w/o(NE,IM)-2S6. SPA- w/o(NE,IM)-1SUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA-w/o(NE,IM) under 3 & 4 STS sharing operates with 5 extra Erlangs (input load) than ITU-SR & ITU-DR. 2. ITU-SR operate with at least 5 extra Erlangs than SPA-w/o(NE,IM) 1&2.Blocking Key Takeaways: 1. Disabling NE and IM leads to higher blocking probability than both ITU-DR & ITU-SR2. Increasing sharing ratio on SPA-w/o(NE,IM) produces lower blocking at the VPN level.

235

Figure 19-11: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2 Alternate Route-- ITU (DR,SR), SPA-w/NE,w/oIM


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-(w/NE, w/o IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,w/oIM)-3S ITU-DR ITU-SRSPA-(w/ NE,w/oIM)-1 S SPA-(w/ NE,w/oIM)-2S SPA-(w/ NE,w/oIM)-4S

Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- (w/NE,w/oIM)-1S 2. SPA- (w/NE,w/oIM)-3S3. SPA- (w/NE,w/oIM)-2S4. SPA- (w/NE,w/oIM)-4S5. ITU-SR6. ITU-DRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/NE,w/oIM)-1S operates with 10 extra Erlangs (input load) than both ITU-DR & ITU-SR.

Blocking Key Takeaways: 1. Enabling NE only leads to lower blocking probability than both ITU-DR & ITU-SR2. Increasing sharing ratio increases the blocking probability of the SPA-(w/NE,w/oIM) blocking probability.

236

Figure 19-12: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2 Alternate Route-- ITU (DR,SR), SPA-w/oNE,w/IM


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-(w/oNE, w/IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility

SPA-(w/o NE,w/IM)-3S ITU-DR ITU-SRSPA-(w/o NE,w/IM)-1S SPA-(w/o NE,w/IM)-2S SPA-(w/o NE,w/IM)-4S

Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- (w/oNE,w/IM)-4S2. SPA- (w/oNE,w/IM)-3S 3. SPA- (w/oNE,w/IM)-2S4. SPA- (w/oNE,w/IM)-1S5. ITU-SR6. ITU-DRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/oNE,w/IM)-operates with 5-10 extra Erlangs (input load) than the ITU-DR & ITU-SR Blocking Key Takeaways: 1. Enabling IM leads to lower blocking probability than both ITU-DR and ITU-SR2. Increasing sharing ratio leads to lower blocking probability on the SPA-(w/oNE,w/IM)

237

Figure 19-13: Average Network-Wide Blocking Probability (VPN Resources)-4 Node – 2 Alternate Route-- ITU (DR,SR), SPA-w/(NE,IM)


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-w/ (NE,IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility

SPA-(w/ NE,IM)-4S ITU-DR ITU-SR SPA-(w/ NE,IM)-1S SPA-(w/ NE,IM)-2S SPA-(w/ NE,IM)-3S

Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- w/(NE,/IM)-1S2. SPA- w/(NE,/IM)-2S3. SPA- w/(NE,/IM)-3S4. SO- w/(NE,/IM)-4S5. ITU-SR6. ITU-DRUnder 5% network-wide blocking probability at the VPN Resources level:1. SPA- w/(NE,IM) operates with 5-20 extra Erlangs (input load) than the ITU-DR & ITU-SR

Blocking Key Takeaways: 1. Enabling NE & IM underany sharing ratio leads to lower blocking probability than both ITU-DR and ITU-SR2. Increasing sharing ratio leads to higher blocking probability on the SPA-w/(NE,IM)

238

19.1.4 Physical resources


on the physical resource level for the 4-node topology. The configured VPN service


parameters:







as provided in Table 9-1.

239

Figure 19-14: Average Network-Wide Blocking Probability (Physical Resources)-4 Node- IETF (DR, SR), ITU (DR, SR), SPA-Dedicated



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- Dedicated2. ITU-SR3. ITU-DR4. IETF-SR5. IETF-DR

Blocking Key Takeaways: SPA-Dedicated leads to lower blocking probability than IETF & ITU control plane models.

240

Figure 19-15: Average Network-Wide Blocking Probability (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- w/o(NE,/IM)-4S2. SPA- w/o(NE,/IM)-3S3. SPA- w/o(NE,/IM)-1S4. SPA- w/o(NE,/IM)-2S5. ITU-SR6. ITU-DR7. IETF-SR8. IETF-DR

Blocking Key Takeaways: 1. At higher input loads, disabling NE & IM under any sharing ratio leads to lower blocking probability than both IETF and ITU models.2. Increasing sharing ratio leads to lower blocking probability on the SPA-w/o(NE,IM)

241

Figure 19-16: Average Network-Wide Blocking Probability (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-(w/NE,w/oIM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- (w/NE,w/o/IM)-1S2. SPA- (w/NE,w/o/IM)-3S3. SPA- (w/NE,w/o/IM)-2S4. SPA- (w/NE,w/o/IM)-4S5. ITU-SR6. ITU-DR7. IETF-SR8. IETF-DR

Blocking Key Takeaways: 1. Under high input loads, enabling NE only leads to lower blocking probability than IETFand ITU control plane models2. Increasing sharing ratio has no direct effect on blocking probability on the SPA-(w/NE,w/oIM)

242

Figure 19-17: Average Network-Wide Blocking Probability (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility

ITU-DR ITU-SR IETF-DR IETF-SRSPA-(w/o NE,w/IM)-1S SPA-(w/o NE,w/IM)-2S SPA-(w/o NE,w/IM)-3S SPA-(w/o NE,w/IM)-4S

Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- (w/oNE,w//IM)-4S2. SPA- (w/oNE,w//IM)-3S3. SPA- (w/oNE,w//IM)-2S4. SPA- (w/oNE,w//IM)-1S5. ITU-SR6. ITU-DR7. IETF-SR8. IETF-DR

Blocking Key Takeaways: 1. Enabling IM under any sharing ratio leads to lower blocking probability than IETF & ITU control plane models2. Increasing sharing ratio leads to lower bocking probability on the SPA-(w/oNE,w/IM)

243

Figure 19-18: Average Network-Wide Blocking Probability (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the Physical Resources blocking probability:1. SPA- w/(NE,/IM)-1S2. SPA- w/(NE,/IM)-2S3. SPA- w/(NE,/IM)-3S4. SPA- w/(NE,/IM)-4S5. ITU-SR6. ITU-DR7. IETF-SR8. IETF-DR

Blocking Key Takeaways: 1. Enabling both NE & IM under any sharing ratio leads to lower blocking probability than IETF-DR, ITU-DR, IETF-SR, and ITU-SR2. Enabling NE in addition to IM leads to lower blocking probability.3. Increasing sharing ratio leads to higher bocking probability on the SPA-w/(NE,IM)

244

19.2 Permissible load


This section provides detailed performance analysis of network-wide permissible load on the

dedicated network resources partition for the 4-node topology. The configured VPN service


parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

245

Figure 19-19: Average Network-Wide Permissible Load (Dedicated Resources)-4 Node – 2 Alternate Route-STS-1 Sharing

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (Dedicated Resources)


0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)

SPA-w/o(NE,IM )-1S SPA-(w/ NE,w/oIM)-1 S SPA-(w/o NE,w/IM)-1S SPA-(w/ NE,IM)-1S

Summary: The following control plane models are listed in ascending order of the Dedicated Resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 20 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 200% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 160% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 15 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling both NE and IM produces the highest permissible load

246




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the Dedicated Resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 20 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 213% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 240% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 15 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 30 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling both NE and IM produces the highest permissible load

247




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the Dedicated Resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 20 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 200% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 243% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 20 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 20 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the Assured Load.2. Enabling Network Engineering (NE) leads to higher Assured Rate. 3. Enabling both NE and IM produces the highest Dedicated Load.

248




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the Dedicated Resources permissible load:1.SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 20 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 215% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 270% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 15 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same AR under 70 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to higher permissible load3. Enabling both NE and IM produces the highest permissible load

249


This section provides detailed performance analysis of the network-wide permissible load on

the shared network resources partition for the 4-node topology. The configured VPN service


parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

250

Figure 19-23: Average Network-Wide Permissible Load (Shared Resources)-4 Node – 2 Alternate Route-STS-1 Sharing

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (Shared Resources)


0.00

1.00

2.00

3.00

4.00

5.00

6.00

0 5 10 15 20 25 30 35 40Input Load

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the Shared Resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 20 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 220% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 200% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 20 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 30 Erlangs less input load than SPA-w//NE,w/oIM).

Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the Shared Load.2. Enabling Network Engineering (NE) leads to lower permissible load3. Disabling NE and enabling IM produces the highest permissible load

251




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)



Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load2. Enabling Network Engineering (NE) leads to lower permissible load3. Disabling NE and enabling IMproduces the highest permissible load

252




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)



Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load2. Enabling Network Engineering (NE) leads to lower permissible load3. Disabling NE and enabling IM produces the highest permissible load

253




0.00

2.00

4.00

6.00

8.00

10.00

12.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang"

Per P

air P

erm

issi

ble

Load

(Erla

ng)



Permissible load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to lower permissible load3. Disabling NE and enabling IM produces the highest permissible load

254



the VPN network resources partition for the 4-node topology. The configured VPN service


parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

255

Figure 19-27: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2 Alternate Route-ITU(DR,SR),SPA-Dedicated

4-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load (VPN Resources)


0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

Per-

Pair

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. SPA- Dedicated2. ITU-DR3. ITU-SR

Permissible load Key Takeaways: 1. ITU-DR and SPA-Dedicated have produce very close VPN permissible load especially under higher input loads.

2. ITU-SR produces higher permissible load than both SPA-Dedicated and ITU-DR

256

Figure 19-28: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2 Alternate Route-ITU(DR,SR),SPA-w/o(NE,IM)


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- w/o(NE,IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

Per-

Pair

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. ITU-SR3. SPA- w/o(NE,IM)-1S 4. SPA- w/o(NE,IM)-2S5. SPA- w/o(NE,IM)-3S6. SPA- w/o(NE,IM)-4SUnder any given input load:1. SPA-w/o(NE,IM), under any sharing ratio, provides higher permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the SPA-w/o(NE,IM) leads to higher permissible load

Permissible load Key Takeaways: 1. For SPA- w/o(NE,IM), under the same input load, increasing sharing resources across multiple bandwidth pools (VPNs) leads to permissible load

257

Figure 19-29: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2 Alternate Route-ITU(DR,SR),SPA-w/NE,w/oIM


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- (w/NE, w/o IM)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Per-

Pair

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. SPA- (w/NE,w/oIM)-4S 2. ITU-DR3. SPA- (w/NE,w/oIM)-2S4. SPA- (w/NE,w/oIM)-3S5. SPA- (w/NE,w/oIM)-1S6. ITU-SRUnder any given input load:1. For (w/NE,w/oIM), under any sharing ratio, provides lower permissible load than both ITU-DR and ITU-SR. 2. Under higher input loads, SPA- (w/NE,w/oIM)-4S produces lower permissible load than ITU-DR3. Increasing the sharing ratio of the SPA-w/(NE,w/oIM) leads to lower permissible load

Permissible load Key Takeaways: 1. Under the same input load, increasing sharing resources across multiple bandwidth pools (VPNs) leads to lower permissible load2. Under lower input load, split routing in ITU model leads to higher permissible load than direct routing.

258

Figure 19-30: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2 Alternate Route--ITU(DR,SR),SPA-w/oNE,w/IM


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- (w/oNE, w/IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-1.00

1.00

3.00

5.00

7.00

9.00

11.00

Per-

Pair

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. ITU-SR3. SPA- (w/oNE,w/IM)-1S 4. SPA- (w/oNE,w/IM)-2S5. SPA- (w/oNE,w/IM)-3S6. SPA- (w/oNE,w/IM)-4S

Under any given input load:1. For (w/oNE,w/IM), under any sharing ratio, provides higher permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the (w/oNE,w/IM) leads to higher permissible load

Permissible load Key Takeaways: 1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to higher permissible load2. Split routing in ITU model leads to higher permissible load than direct routing.

259

Figure 19-31: Average Network-Wide Permissible Load (VPN Resources)-4 Node – 2 Alternate Route--ITU(DR,SR),SPA-w/(NE,IM)


2-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- w/(NE,IM)

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

Per-

Pair

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. ITU-SR3. SPA-w/(NE,IM)-4S 4. SPA- w/(NE,IM)-3S5. SPA- w/(NE,IM)-2S6. SPA- w/(NE,IM)-1S

Under any given input load:1. For w/(NE,IM), under any sharing ratio, provides higher permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the w/(NE,IM) leads to lower permissible load

Permissible load Key Takeaways: 1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to lower permissible load2. Split routing in ITU model leads to higher permissible load than direct routing.

260

19.2.4 Physical resources


the physical resource level for the 4-node topology. The configured VPN service evaluated is

the Fully-meshed Shared Granular (FSF) with the following service profile layer parameters:








261

Figure 19-32: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-Dedicated



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

-1.00

1.00

3.00

5.00

7.00

9.00

11.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-Dedicated2. IETF-DR3. ITU-DR4. IETF-SR5. ITU-SRUnder any given input load:1. No significant permissible load advantage of the SPA-Dedicated over both IETF-DR and ITU-DR2. ITU-SR& IETF-SR provides a higher permissible load than (IETF-DR,ITU-DR, and SPA-Dedicated

Permissible load Key Takeaways: 1. Split routing provides higher permissible load than direct routing for both IETF and ITU control plane models.

262

Figure 19-33: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-w/o(NE,IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-w/o(NE,IM)-2S2. SPA-w/o(NE,IM)-4S3. SPA-w/o(NE,IM)-3S4. SPA-w/o(NE,IM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-SR

Permissible load Key Takeaways: 1. SPA-w/o(NE,IM) provides lower permissible load compred to IETF and ITU models under both direct and split routing.

263

Figure 19-34: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF (DR, SR), ITU(DR,SR), SPA-(w/NE,w/oIM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. SPA-(w/NE,w/oIM)-4S2. SPA-(w/NE,w/oIM)-2S3. SPA-(w/NE,w/oIM)-3S4. SPA-(w/NE,w/oIM)-1S5. IETF-DR6. ITU-DR7. IETF-SR8. ITU-SRPermissible load Key Takeaways: 1. SPA-(w/NE,w/oIM) provides a lower permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/NE,w/oIM) model, increasing sharing ratio leads to lower permissible load.

264

Figure 19-35: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-(w/oNE,w/IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

PPer

-Pai

r Per

mis

sibl

e Lo

ad


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. ITU-SR5. SPA-(w/oNE,w/IM)-1S6. SPA-(w/oNE,w/IM)-2S7. SPA-(w/oNE,w/IM)-3S8. SPA-(w/o/NE,w/IM)-4S

Permissible load Key Takeaways: 1. SPA-(w/oNE,w/IM) provides a higher permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-(w/oNE,w/IM) model, increasing sharing ratio leads to higher permissible load

265

Figure 19-36: Average Network-Wide Permissible Load (Physical Resources)-4 Node – IETF(DR,SR), ITU(DR,SR), SPA-w/(NE,IM)



0 5 10 15 20 25 30 35 40

Input Load (Erlang)

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

16.00

Per-

Pair

Perm

issi

ble

Load


Summary: The following control plane models are listed in ascending order of the physical resources permissible load:1. IETF-DR2. ITU-DR3. IETF-SR4. ITU-SR5. SPA-w/(NE,IM)-4S6. SPA-w/(NE,IM)-3S7. SPA-w/(NE,IM)-2S8. SPA-w/(NE,IM)-1S

Permissible load Key Takeaways: 1. SPA-w/(NE,IM) provides a higher permissible load compred to IETF and ITU models under both direct and split routing.2. For SPA-w/(NE,IM) model, increasing sharing ratio leads to lower permissible load3. The significane of sharing ratio of SPA-w/(NE,IM) on permissible load is higher than SPA-(w/oNE,w/IM) model

266

19.3 Utilization

This section provides detailed performance analysis of the network-wide utilization on the

physical resource level for the 4-node topology. The configured VPN service evaluated is the

Fully-meshed Shared Granular (FSF) with the following service profile layer parameters:








267

Figure 19-37: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU, SPA-Dedicated, SPA-w/o(NE,IM)



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. SPA-w/o(NE,IM)2. ITU-DR3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-w/o(NE,IM) and same input load:1. All sharing ratios provide lower utilization than IETF,ITU, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-DR,ITU-SR, and IETF-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

268

Figure 19-38: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU, SPA-Dedicated, SPA-w/NE,w/oIM



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-(w/NE,w/oIM)3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-(w/NE,w/oIM) and same input load:1. All sharing ratios provide lower utilization than IETF,ITU-SR, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-DR,ITU-SR, and IETF-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

269

Figure 19-39: Average Network-Wide Utilization (Physical Resources)-4 Node – IETF,ITU, SPA-Dedicated, SPA-w/oNE,w/IM



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40

Input Load

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. SPA-(w/oNE,w/IM)2. ITU-DR3. SPA-Dedicated4. ITU-SR5. IETF-DR6. IETF-SR

Utilization Key Takeaways: Under SPA-(w/oNE,w/IM) and same input load:1. All sharing ratios provide lower utilization than IETF, ITU, and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-DR,ITU-SR, and IETF-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

270

Figure 19-40: Average Network-Wide Blocking Probability (Physical Resources)-4 Node-2 Alternate Route- IETF,ITU, SPA-Dedicated, SPA-w/(NE,IM)



0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40

Input Load (Erlang)

Phys

ical

Res

ourc

es U

tiliz

atio

n


Summary: Based on the physical resources utilization, the following control plane models are listed in ascending order based on the physical resources utlization under the same input load1. ITU-DR2. SPA-Dedicated3. ITU-SR4. IETF-DR5. SPA-w/(NE,IM)6. IETF-SR

Utilization Key Takeaways: Under SPA-w/(NE,IM) and same input load:1. All sharing ratios provide higher utilization than IETF-DR, ITU-(DR,SR), and SPA-Dedicated models.2. SPA-Dedicated provides lower utilization than IETF-DR,ITU-SR, and IETF-SR models.3. Direct Routing (DR) povides lower utlization than Split Routing (SR) for both IETF and ITU models

271

20 Appendix-D: Detailed Modeling Results- 7-Node Topology with 2-Alternate Routing




on the dedicated network resources partition for the 7-node topology with two-alternate

routing. The configured VPN service evaluated is the Fully-meshed Shared Granular (FSF)

with the following service profile layer parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

272




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.02

0.04

0.06

0.08

0.10

0.12

0.14

0.16

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/(NE, IM)3. SPA- w/o (NE,IM)4. SPA- (w/NE, w/o IM)

Under 5% network-wide blocking probability at the Dedicated Resources level:1. SPA-(w/oNE, w/IM) operates with 25 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 30 extra Erlangs.

Blocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reducesthe blocking probability2. Enabling Network Engineering (NE) increases the blocking probability3. Enabling NE and disabling IM produces the highest blocking probability. 4. Enabling IM and disabling NE produces the lowest blocking probability.

273




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility



Under 5% network-wide blocking probability at the Dedicate Resources level:1. SPA-(w/oNE, w/IM) operates with 50 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 30 extra Erlangs.


274




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility





275




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/(NE, IM) 3. SPA- w/o (NE,IM) Order swap 4. SPA- (w/NE, w/o IM)Under 5% network-wide blocking probability at the Dedicated Resources level:1. SPA-(w/oNE, w/IM) operates with 70 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 40 extra Erlangs.


276



on the shared network resources partition for the 7-node topology with two-alternate routing.

The configured VPN service evaluated is the Fully-meshed Shared Granular (FSF) with the

following service profile layer parameters:









jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

277




0 10 20 30 40 50 60 70 80 90Input Load

-0.10

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM)3. SPA- (w/o NE, w/IM)4. SPA- w/o (NE,IM) Under 10% network-wide blocking probability at the Shared Resources level:1. SPA-w/(NE, IM) operates with 60 extra Erlangs (input load) than SO-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 10 extra Erlangs.

Blocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reduces the blocking probability2. Enabling Network Engineering (NE) reduces the blocking probability3. Disabling NE and IM produces the highest blocking probability.4. Enabling NE and IM produces the lowestblocking probability.

278




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

-0.10

0.00

0.10

0.20

0.30

0.40

0.50


Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM) Order swap 3. SPA- (w/o NE, w/IM) at high load4. SPA- w/o (NE,IM) Under 10% network-wide blocking probability at the Shared Resources level:1. SPA-w/(NE, IM) operates with 50 extra Erlangs (input load) than SPA-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 15 extra Erlangs


279




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility




280




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang"

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility




281



on the VPN network resources partition for the 7-node topology with two-alternate routing.











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

282

Figure 20-9: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-Dedicated



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- Dedicated3. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA-Dedicated operates with 20 extra Erlangs (input load) than ITU-SR.2. ITU-DR operates with 5 extra Erlangs (input load) than SPA-Dedicated.

283

Figure 20-10: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- w/o(NE,IM)-4S 3. ITU-SR4. SPA- w/o(NE,IM)-3S5. SPA- w/o(NE,IM)-1S6. SPA- w/o(NE,IM)-2SUnder 10% network-wide blocking probability at the VPN Resources level:1. ITU-DR operates with 15 extra Erlangs (input load) than the best performing SPA-w/o(NE,IM) under 4 STS sharing.2. ITU-SR operate with at least 10 extra Erlangs than SPA-w/o(NE,IM) under all sharing ratios except 4 STS sharing.

Blocking Key Takeaways: 1. Disabling NE and IM leads to higher blocking probability than ITU-DR 2. Increasing sharing ratio on SPA-w/o(NE,IM) produces lower blocking at the VPN level.

284

Figure 20-11: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- (w/NE,w/oIM)-3S 3. SPA- (w/NE,w/oIM)-1S4. SPA- (w/NE,w/oIM)-4S5. SPA- (w/NE,w/oIM)-2S6. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. ITU-DR operates with 5 extra Erlangs (input load) than the best performing SPA-(w/NE,w/oIM) under 1 STS sharing.

Blocking Key Takeaways: 1. Enabling NE only leads to higher blocking probability than ITU-DR but not ITU-SR2. Increasing sharing ratio has no direct effect on the SPA-(w/NE,w/oIM) blocking probability

285

Figure 20-12: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- (w/oNE,w/IM)-4S2. SPA- (w/oNE,w/IM)-3S 3. ITU-DR4. SPA- (w/oNE,w/IM)-2S5. SPA- (w/oNE,w/IM)-1S6. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/oNE,w/IM)-4S operates with 10 extra Erlangs (input load) than the ITU-DR and 20 extra Erlangs than ITU-SR.

Blocking Key Takeaways: 1. Enabling IM with higher than 2 STS sharing leads to lower blocking probability than both ITU-DR and ITU-SR2. Increasing sharing ratio leads to lower blocking probability on the SPA-(w/oNE,w/IM)

286

Figure 20-13: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- w/(NE,/IM)-1S2. SPA- w/(NE,/IM)-2S3. SPA- w/(NE,/IM)-3S4. SPA- w/(NE,/IM)-4S5. ITU-DR6. ITU-SR

Under 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/oNE,w/IM) operates with 15 extra Erlangs (input load) than the ITU-DR and 35 extra Erlangs than ITU-SR


287


20.2.1 Dedicated resources This section provides detailed performance analysis of the network-wide permissible load on

the dedicated network resources partition for the 7-node topology with two-alternate routing.











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

288




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the dedicated resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 50 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 230% extra Erlangs (per pair dedicated load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 260% extra Erlangs (per pair dedicated load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 40 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 50 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load 2. Enabling Network Engineering (NE) leads to higher permissible load 3. Enabling both NE and IM produces the highest permissible load

289




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the dedicated resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 50 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 230% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 285% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 40 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 50 Erlangs less input load than SPA-w/o(/NE,IM).


290




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)




291




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the dedicated resources permissible load:1. SPA- w/o (NE, IM)2. SPA- (w/NE, w/oIM)3. SPA- (w/oNE,w/IM)4. SPA- w/(NE, IM)Under 50 Erlangs input load:1. SPA-(w/oNE, w/IM) operates with 230% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 290% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 40 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 70 Erlangs less input load than SO-w/o(/NE,IM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load 2. Enabling Network Engineering (NE) leads to higher permissible load 3. Enabling both NE and IM produces the highest permissible load .

292



the shared network resources partition for the 7-node topology with two-alternate routing.











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

293




0.00

0.50

1.00

1.50

2.00

2.50

3.00

0 10 20 30 40 50 60 70 80 90Input Load

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 230% extra Erlangs (per pair permissible load ) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 23% extra Erlangs (per pair permissible load ) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 80 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load 2. Enabling Network Engineering (NE) leads to lower permissible load 3. Disabling NE and enabling IM produces the highest permissible load

294




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 235% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 33% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same SR under 50 Erlangs less input load than SPA-w/o(/NE,IM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load2. Enabling Network Engineering (NE) leads to lower permissible load3. Disabling NE and enabling IM produces the highest permissible load.

295




0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listedin ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 245% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 55% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 60 Erlangs less input load than SPA-w/o(/NE,IM).Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load 2. Enabling Network Engineering (NE) leads to lower permissible load 3. Disabling NE and enabling IM produces the highest permissible load

296




0.00

1.00

2.00

3.00

4.00

5.00

6.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang"

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 260% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 71% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 80 Erlangs less input load than SPA-w/o(/NE,IM).Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load 2. Enabling Network Engineering (NE) leads to lower permissible load 3. Disabling NE and enabling IM produces the highest permissible load

297



the VPN network resources partition for the 7-node topology with two-alternate routing. The

configured VPN service evaluated is the Fully-meshed Shared Granular (FSF) with the










jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

298

Figure 20-22: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-Dedicated



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. SPA- Dedicated3. ITU-SR

Permissible load Key Takeaways: SPA-Dedicated produces higher permissable load than both ITU-DR and ITU-SR especially under higher input loads.

299

Figure 20-23: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. ITU-SR3. SPA- w/o(NE,IM)-1S 4. SPA- w/o(NE,IM)-2S5. SPA- w/o(NE,IM)-3S6. SPA- w/o(NE,IM)-4SUnder any given input load:1. SPA-w/o(NE,IM), under any sharing ratio, provides higher permissable load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the SPA-w/o(NE,IM) leads to higher permissable load

Permissible load Key Takeaways: 1. For SPA- w/o(NE,IM), under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to higher permissable load2. Under lower input load, split routing in ITU model leads to higher permissable load than direct routing.

300

Figure 20-24: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM



0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Per P

air P

erm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. SPA- (w/NE,w/oIM)-4S 2. SPA- (w/NE,w/oIM)-2S3. SPA- (w/NE,w/oIM)-3S4. SPA- (w/NE,w/oIM)-1S5. ITU-DR6. ITU-SRUnder any given input load:1. For (w/NE,w/oIM), under any sharing ratio, provides lower permissable load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the SPA-w/(NE,w/oIM) leads to lower permissable load

Permissible load Key Takeaways: 1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to lower permissable load2. Under lower input load, split routing in ITU model leads to higher permissable load than direct routing.

301

Figure 20-25: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

Per P

air P

erm

issi

ble

Load

(Erla

ng)



Under any given input load:1. For (w/oNE,w/IM), under any sharing ratio, provides higher permissable load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the (w/oNE,w/IM) leads to higher permissable

Permissible load Key Takeaways: 1. Under the same input load, incresing sharing resourcres across multiple bandwidth pools (VPNs) leads to higher permissable load2. Under lower input load, split routing in ITU model leads to higher permissable load than direct routing.

302

Figure 20-26: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 2 Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

Per P

air P

erm

issi

ble

Load

(Erla

ng)



Under any given input load:1. For w/(NE,IM), under any sharing ratio, provides higher permissable load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the w/(NE,IM) leads to lower permissable load

Permissible load Key Takeaways: 1. Under the same input load, incresing sharing resourcres across multiple bandwidth pools (VPNs) leads to lower permissable load2. Under lower input load, split routing in ITU model leads to higher permissable load than direct routing.

303

21 Appendix-E: Detailed Modeling Results- 7-Node Topology with 3-Alternate Routing




on the dedicated network resources partition for the 7-node topology with three-alternate











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

304




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.02

0.04

0.06

0.08

0.10

0.12

0.14

0.16

Blo

ckin

g Pr

obab

ility



Under 5% network-wide blocking probability at the Dedicated Resources level:1. SPA-(w/oNE, w/IM) operates with 30 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane

d l t t ith 20 t E lBlocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reducesthe blocking probability2. Enabling Network Engineering (NE) increases the blocking probability3. Enabling NE and disabling IM produces the highest blocking probability. 4. Enabling IM and disabling NE produces the lowest blocking probability.

305




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

Blo

ckin

g Pr

obab

ility



Under 5% network-wide blocking probability at the Dedicated Resources level:1. SPA-(w/oNE, w/IM) operates with 50 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 35 extra ErlangsBlocking Key Takeaways: 1. Enabling Inverse Multiplexing (IM) reduces the blocking probability2. Enabling Network Engineering (NE) increases the blocking probability3. Enabling NE and disabling IM produces the highest blocking probability. 4. Enabling IM and disabling NE produces the lowest blocking probability.

306




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

Blo

ckin

g Pr

obab

ility





307




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the dedicated resources blocking probability:1. SPA- (w/o NE, w/IM)2. SPA- w/(NE, IM) 3. SPA- w/o (NE,IM) Order swap 4. SPA- (w/NE, w/o IM)Under 5% network-wide blocking probability at the Dedicated Resources level:1. SPA-(w/oNE, w/IM) operates with 60 extra Erlangs (input load) than SPA-(w/NE,w/oIM).2. While disabling NE, enabling IM allows SPA control plane model to operate with 40 extra Erlangs.


308



on the shared network resources partition for the 7-node topology with three-alternate











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

309




0 10 20 30 40 50 60 70 80 90Input Load

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

Blo

ckin

g Pr

obab

ility




310




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70


Summary: The following control plane models are listed in ascending order of the shared resources blocking probability:1. SPA- w/(NE, IM)2. SPA- (w/NE, w/o IM) Order swap 3. SPA- (w/o NE, w/IM) at high load4. SPA- w/o (NE,IM) Under 10% network-wide blocking probability at the Shared Resources level:1. SPA-w/(NE, IM) operates with 50 extra Erlangs (input load) than SPA-w/o(NE,IM).2. While enabling NE, enabling IM allows SPA control plane model to operate with 28 extra Erlangs.


311




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

Blo

ckin

g Pr

obab

ility




312




0 10 20 30 40 50 60 70 80 90

Input Load (Erlang"

-0.05

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility




313



on the VPN network resources partition for the 7-node topology with three-alternate routing.











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

314

Figure 21-9: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-Dedicated



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- Dedicated3. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA-Dedicated operates with 10 extra Erlangs (input load) than ITU-SR.2. ITU-DR operates with 10 extra Erlangs (input load) than SPA-Dedicated.

315

Figure 21-10: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)


3-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA-w/o(NE,IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- w/o(NE,IM)-4S 3. ITU-SR4. SPA- w/o(NE,IM)-3S5. SPA- w/o(NE,IM)-1S6. SPA- w/o(NE,IM)-2SUnder 10% network-wide blocking probability at the VPN Resources level:1. ITU-DR operates with 10 extra Erlangs (input load) than the best performing SPA-w/o(NE,IM) under 4 STS sharing.2. ITU-SR operate with at leasr 10 extra Erlangs than SPA-w/o(NE,IM) under all sharing ratios

Blocking Key Takeaways: 1. Disabling NE and IM leads to higher blocking probability than both ITU-DR & ITU-SR2. Increasing sharing ratio on SPA-w/o(NE,IM) produces lower blocking at the VPN level.

316

Figure 21-11: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM


3-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- (w/NE, w/o IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. ITU-DR2. SPA- (w/NE,w/oIM)-3S 3. SPA- (w/NE,w/oIM)-1S4. SPA- (w/NE,w/oIM)-4S5. SPA- (w/NE,w/oIM)-2S6. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. ITU-DR operates with 2 extra Erlangs (input load) than the best performing SPA-(w/NE,w/oIM) under 3 STS sharing.2. ITU-SR operate with at the same Erlangs like the SPA-(w/NE,w/oIM) under all sharing ratios except 4 STS sharing.

Blocking Key Takeaways: 1. Enabling NE only leads to higher blocking probability than ITU-DR &but not ITU-SR2. Increasing sharing ratio has no direct effect on the SPA-(w/NE,w/oIM) blocking probability

317

Figure 21-12: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM


3-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- (w/oNE, w/IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- (w/oNE,w/IM)-4S2. SPA- (w/oNE,w/IM)-3S 3. ITU-DR4. SPA- (w/oNE,w/IM)-2S5. SPA- (w/oNE,w/IM)-1S6. ITU-SRUnder 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/oNE,w/IM)-4S operates with 10 extra Erlangs (input load) than the ITU-DR and 20 extra Erlangs than ITU-SR

Blocking Key Takeaways: 1. Enabling IM with higher than 2 STS sharing leads to lower blocking probability than both ITU-DR and ITU-SR2. Increasing sharing ratio leads to lower blocking probability on the SPA-(w/oNE,w/IM)

318

Figure 21-13: Average Network-Wide Blocking Probability (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)


3-Alternate Routing, Class-B Arrivals, ITU(DR,SR), SPA- w/ (NE,IM)

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

Blo

ckin

g Pr

obab

ility


Summary: The following control plane models are listed in ascending order of the VPN resources blocking probability:1. SPA- w/(NE,/IM)-1S2. SPA- w/(NE,/IM)-2S3. SPA- w/(NE,/IM)-3S4. SPA- w/(NE,/IM)-4S5. ITU-DR6. ITU-SR

Under 10% network-wide blocking probability at the VPN Resources level:1. SPA- (w/oNE,w/IM)-4S operates with 20 extra Erlangs (input load) than the ITU-DR and 30 extra Erlangs than ITU-SR


319




the dedicated network resources partition for the 7-node topology with three-alternate











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

320




0.00

1.00

2.00

3.00

4.00

5.00

6.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)



Permissible Load Key Takeaways:1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to higher permissible load.3. Enabling both NE and IM produces the highest permissible load.

321




0.00

1.00

2.00

3.00

4.00

5.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)



Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to higher permissible load.3. Enabling both NE and IM produces the highest permissible load.

322




0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)




323




0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)




324



the shared network resources partition for the 7-node topology with three-alternate routing.











jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

325




0.00

0.50

1.00

1.50

2.00

2.50

0 10 20 30 40 50 60 70 80 90Input Load

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 250% extra Erlangs (per pair permissible load) than SO-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 30% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 80 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 15 Erlangs less input load than SPA-w//NE,w/oIM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to lower permissible load.3. Disabling NE and enabling IMproduces the highest permissible load.

326




0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 230% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 35% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 60 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 15 Erlangs less input load than SPA-w//NE,w/oIM).

Permissible Load Key Takeaways: 1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to lower permissible load.3. Disabling NE and enabling IMproduces the highest permissible load.

327




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 220% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 55% extra Erlangs (per pair permissible load) thanSPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 80 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 15 Erlangs less input load than SPA-w//NE,w/oIM).

Permissible Load Key Takeaways:1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to lower permissible load.3. Disabling NE and enabling IM produces the highest permissible load.

328




0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang"

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the shared resources permissible load:1. SPA- (w/NE, w/oIM)2. SPA- w/(NE, IM)3. SPA- w/o (NE, IM)4. SPA- (w/oNE,w/IM)Under 50 Erlangs input load (IM Perspective):1. SPA-(w/oNE, w/IM) operates with 220% extra Erlangs (per pair permissible load) than SPA-w/o(/NE,IM).2. SPA-w/(NE, IM) operates with 66% extra Erlangs (per pair permissible load) than SPA-(w//NE,w/oIM).Under the range input load:1. SPA-(w/oNE,w/IM) achives the same permissible load under 80 Erlangs less input load than SPA-w/o(/NE,IM).2. SPA-w(/NE,IM) achives the same permissible load under 30 Erlangs less input load than SPA-w//NE,w/oIM).

Permissible Load Key Takeaways:1. At any input load, enabling Inverse Multiplexing (IM) increases the permissible load.2. Enabling Network Engineering (NE) leads to lower permissible load.3. Disabling NE and enabling IM produces the highest permissible load.

329



the VPN network resources partition for the 7-node topology with three-alternate routing. The

configured VPN service evaluated is the Fully-meshed Shared Granular (FSF) with the










jC =2 STS-1


jC =4 STS-1


jC =6 STS-1


jC =8 STS-1

330

Figure 21-22: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-Dedicated

7-node Topology (Fully-meshed Service Configuration)Average Network-Wide Permissible Load(VPN Resources)


0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. SPA- Dedicated3. ITU-SR

Permissible Load Key Takeaway:ITU-DR, ITU-SR, and SPA-Dedicated have produce very close VPN permissible load especially under higher input loads.

331

Figure 21-23: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/o(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. ITU-DR2. ITU-SR3. SPA- w/o(NE,IM)-1S 4. SPA- w/o(NE,IM)-2S5. SPA- w/o(NE,IM)-3S6. SPA- w/o(NE,IM)-4SUnder any given input load:1. SPA-w/o(NE,IM), under any sharing ratio, provides higher VPN permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the SPA-w/o(NE,IM) leads to higher permissible load

Permissible Load Key Takeaway:1. For SPA- w/o(NE,IM), under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to higher permissible load 2. Under lower input load, split routing in ITU model leads to higher permissible load than direct routing.

332

Figure 21-24: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/NE,w/oIM



0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

Perm

issi

ble

Load

(Erla

ng)


Summary: The following control plane models are listed in ascending order of the VPN resources permissible load:1. SPA- (w/NE,w/oIM)-4S 2. SPA- (w/NE,w/oIM)-2S3. SPA- (w/NE,w/oIM)-3S4. SPA- (w/NE,w/oIM)-1S5. ITU-DR6. ITU-SRUnder any given input load:1. For (w/NE,w/oIM), under any sharing ratio, provides lower VPN permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the SPA-w/(NE,w/oIM) leads to lower VPN permissible load

Permissible Load Key Takeaway:1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to lower VPN permissible load 2. Under lower input load, split routing in ITU model leads to higher permissible load than direct routing.

333

Figure 21-25: Average Network-Wide Permissible Load (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/oNE,w/IM



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

Perm

issi

ble

Load

(Erla

ng)



Under any given input load:1. For (w/oNE,w/IM), under any sharing ratio, provides higher VPN permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the (w/oNE,w/IM) leads to higher VPN permissible load

Permissible Load Key Takeaway:1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to higher VPN permissible load 2. Under lower input load, split routing in ITU model leads to higher permissible load than direct routing.

334

Figure 21-26: Average Network-Wide Blocking Permissible Load (VPN Resources)-7 Node – 3 Alternate Route-ITU(DR,SR), SPA-w/(NE,IM)



0 10 20 30 40 50 60 70 80 90

Input Load (Erlang)

0.00

1.00

2.00

3.00

4.00

5.00

6.00

Perm

issi

ble

Load

(Erla

ng)



Under any given input load:1. For w/(NE,IM), under any sharing ratio, provides higher VPN permissible load than both ITU-DR and ITU-SR.2. Increasing the sharing ratio of the w/(NE,IM) leads to lower VPN permissible load

Permissible Load Key Takeaway:1. Under the same input load, increasing sharing resourcres across multiple bandwidth pools (VPNs) leads to lower VPN permissible load 2. Under lower input load, split routing in ITU model leads to higher permissible load than direct routing.

service profile-aware control plane - ku ittc · 2005-07-07 · wesam alanqar b.s.e.e., uae...

Documents