spirent journal of core routing and tunneling pass … traffic, routing, and mpls protocols (e.g.,...

PASS

Spirent Journal of Core

Routing and Tunneling

PASS Test Methodologies February 2011 Edition

Spirent Journal of Core Routing and Tunneling PASS Test Methodologies | © Spirent Communications 2011

1

Introduction

Today’s Devices Under Test (DUT) represent complex, multi-protocol network elements with an emphasis

on Quality of Service (QoS) and Quality of Experience (QoE) that scale to terabits of bandwidth across the

switch fabric. The Spirent Catalogue of Test Methodologies represents an element of the Spirent test

ecosystem that helps answer the most critical Performance, Availability, Security and Scale Tests (PASS)

test cases. The Spirent Test ecosystem and Spirent Catalogue of Test Methodologies are intended to help

development engineers and product verification engineers to rapidly develop and test complex test

scenarios.

How to use this Journal

This provides test engineers with a battery of test cases for the Spirent Test Ecosystem. The journal is

divided into sections by technology. Each test case has a unique Test Case ID (Ex. TC_MBH_001) that is

universally unique across the ecosystem.

Tester Requirements

To determine the true capabilities and limitations of a DUT, the tests in this journal require a test tool that

can measure router performance under realistic Internet conditions. It must be able to simultaneously

generate wire-speed traffic, emulate the requisite protocols, and make real-time comparative

performance measurements. High port density for cost-effective performance and stress testing is

important to fully load switching fabrics and determine device and network scalability limits.

In addition to these features, some tests require more advanced capabilities, such as

Integrated traffic, routing, and MPLS protocols (e.g., BGP, OSPF, IS-IS, RSVP-TE, LDP/CR-LDP) to

advertise route topologies for large simulated networks with LSP tunnels while simultaneously

sending traffic over those tunnels. Further, the tester should emulate the interrelationships

between protocol s through a topology.

Emulation of service protocols (e.g., IGMPv3, PIM-SM, MP-iBGP) with diminution.

Correct single-pass testing with measurement of 41+ metrics per pass of a packet.

Tunneling protocol emulation (L2TP) and protocol stacking.

True stateful layer 2-7 traffic.

Ability to over-subscribe traffic dynamically and observe the effects.

Finally, the tester should provide conformance test suites for ensuring protocol conformance and

interoperability, and automated applications for rapidly executing the test cases in this journal.

Further Resources

Additional resources are available on our website at http://www.spirent.com

http://www.spirent.com/


2

Table of Contents

Testing Core Routing and Tunneling .......................................................................................3

ROUTE_001 MPLS-tunneled service traffic failover verification ............................................. 4

ROUTE_002 Verify that the DUT conforms to the RSVP-TE P2MP make-before-break

standard ............................................................................................................... 9

ROUTE_003 Verify that the DUT supports multi-topology IS-IS ............................................. 12

ROUTE_004 BGP peer, route, and AS capacity test .............................................................. 15

ROUTE_005 OSPF adjacency and route capacity test ........................................................... 19

ROUTE_006 mVPN test ......................................................................................................... 22

ROUTE_007 MPLS IP VPN test ............................................................................................... 26

ROUTE_008 Determine whether the DUT supports LSP Ping (MPLS OAM) ........................... 29

Appendix A – Telecommunications Definitions ..................................................................... 33

Appendix B – Layer 2 802.1q CoS .......................................................................................... 40

Appendix C – RFC 2474 Layer 3 QoS ...................................................................................... 41

Appendix D – RFC 2474 Layer 3 QoS Definitions .................................................................... 42


3

Testing Core Routing and Tunneling

A core router forwards packets to computer hosts

within a network, but not between networks). A

core router is sometimes contrasted with an edge

router, which routes packets between a self-

contained network and other outside networks

along a network backbone. In addition,

Multiprotocol Label Switching (MPLS) is a Layer-2

data-carrying mechanism, operating at a layer below

IP. It was designed to provide a unified data-carrying

service for both circuit-based clients and packet-

switching clients, which provide a datagram service

model. It can be used to carry many different kinds

of traffic, including voice telephone traffic and IP

packets. These elements form a basis for the Next

Generation Network (NGN).

The NGN network is a mix of very high performance, QoS-enabled IPv4 and IPv6 routing IPv4 and IPv6.

Scale and performance is generationally denser than in previous routing paradigms. The NGN also mixes

in network intelligence and numerous access technologies, including wireless. The network is complex,

with protocols stacked and interlinked. This presents a testing challenge because older paradigms of

testing routing, such as treating each protocol as an independent stack, no long applies.

Testing core routing and tunneling for the next generation network evolves test and measurement

instrumentation to allow for real-world, object based modeling of network infrastructures. In addition,

the ability to simulate actions over time the converged core and tunneling has become a critical part of

testing.


4

ROUTE_001 MPLS-tunneled service traffic failover verification

Abstract

In a service provider metro core, the flexibility provided the carrier to dynamically heal MPLS-

tunneled traffic in the event of a major core routing failure is a critical feature in the design,

deployment and offering provided to their customers. This test case simulates a catastrophic BGP

failure and measures the ability of the DUT to coordinate a response at the routing, tunneling

and SLA service levels for loaded traffic. Without verification, the user risks deploying a DUT

without understanding how the DUT will react in emergency scenarios.

Description

A Metro Ethernet is a communications network that covers a metropolitan area, based on the

Ethernet standard. It is commonly used as a metropolitan access network to connect subscribers

and businesses to a larger service network or the Internet. Businesses can also use Metro

Ethernet to connect branch offices to their Intranet.

Ethernet has been a well-known technology for decades. An Ethernet interface is much less

expensive than a SONET/SDH or PDH interface of the same bandwidth. Ethernet also supports

high bandwidths with fine granularity, which is not available with traditional SDH connections.

Another distinct advantage of an Ethernet-based access network is that it can be easily

connected to the customer network, due to the prevalent use of Ethernet in corporate and, more

recently, residential networks. Therefore, bringing Ethernet in to the Metropolitan Area Network

(MAN) introduces a lot of advantages to both the service provider and the customer.

With typical service provider Metro Ethernet network is a collection of Layer 2 or/and Layer 3

switches or/and routers connected through optical fiber. The topology could be a ring, hub-and-

spoke (star), or full or partial mesh. The network will also have a hierarchy: core, distribution

(aggregation) and access. The core in most cases is an existing IP/MPLS backbone, but may

migrate to newer forms of Ethernet Transport in the form of 10G or 100G speeds.

Ethernet on the MAN can be used as pure Ethernet, Ethernet over SDH, Ethernet over MPLS or

Ethernet over DWDM. Pure Ethernet-based deployments are cheap but less reliable and scalable,

and thus are usually limited to small scale or experimental deployments. SDH-based deployments

are useful when there is an existing SDH infrastructure already in place, its main shortcoming

being the loss of flexibility in bandwidth management due to the rigid hierarchy imposed by the

SDH network. MPLS based deployments are costly but highly reliable and scalable, and are

typically used by large service providers.

In this test, a Service Provider network will be created based on Layer 3 routed BGP, with LDP

MPLS transporting stateful customer traffic. Primary BGP AS path and Secondary AS Paths will be

created in the network and all control and data plane traffic will be converged. Then,

catastrophic primary AS path events will cause the Device Under Test (DUT) to failover traffic to

secondary Routes, cause MPLS to repath, and cause potential disruptions in customer traffic. This

test will measure if repathing occurs correctly and that QoS and QoE is maintained across the

backup MPLS paths.


5

The test case will use the following QoS ACL schedule:

Target Users

Functionally, Scale and Performance Engineers

Target Device Under Test (DUT)

The DUT is a Metro Ethernet core router switch capable of high-scale BGP, MPLS LDP, and QoS.

Reference

RFC 4271, RFC 5036. RFC 793

Relevance

Once of the core functions of a Metro Ethernet core border router is to protect the integrity of

the network. This tests, under high load, the ability of BGP/MPLS router to ensure service under

extreme failure conditions.

Version

1.0

Test Category


PASS

[x] Performance [x] Availability [ ] Security [ ] Scale

Required Tester Capabilities

The tester must have the ability to emulate a topology by placing emulated devices behind

devices. This must be done in a stateful manner such that when one event happens at the object

nearest to the DUT, the effects are cascaded through the device statefully and in real time. The

tester must have the ability to add and remove object content in real-time, not just frame size

and load. The tester must have the ability to custom configure layer 4-7 services alongside Layer

2-3 traffic. On the analysis side, the user must be able to detect QoS violations and QoE loss of

quality in real time, coordinated with change events

Codepoint Max Jitter (uSec)

Max Latency (uSec)

Max Loss (Frames)

Max Duplicate (Frames)

Max Reordered (Frames)

Max Late (Frames)

EF 0 >=1 0 0 0 0

AF31 0 2 0 0 0 0

AF21 2 5 0 1 1 1

AF11 3 5 1 1 1 1

BE ANY ANY ANY ANY ANY ANY


6

Topology Diagram

Test Procedure

1. Reserve 4 test interfaces, named NA1, SA1, E1, A1. Connect interfaces to the DUT and bring

up the link.

2. On the DUT, setup 7K BGP peers and establish BGP:

a. NA1, Emulated AS 00010-7000.

b. SA, Emulated AS 10001-17000.

c. E1, Emulated AS 20001-27000.

d. A1, Emulated AS 30001-37000.

3. On the DUT, establish QoS according to Table 1. Setup all physical ports to participate in LDP,

with NA1 and E1 being primary paths and A1 and SA1 being failover paths.

4. On the emulated routers, advertise the following primary networks:

a. On port NA1, advertise networks x.y.0.0/24, where x represents the first two digits of

the AS, and y represents the two last digits of the peer AS.

b. On Port E1, advertise networks x.y.0.0/28, where x represents the first two digits of the

AS, and y represents the two last digits of the peer AS.


7

c. On Port SA1, advertise networks x.y.0.0/28, where x represents the first two digits of

the AS, and y represents the two last digits of the peer AS.

d. On Port A1, advertise networks x.y.0.0/28, where x represents the first two digits of the

AS, and y represents the two last digits of the peer AS.

5. On port A1, advertise the network on port E1 with a secondary AS path of AS=(A1 Path,E1

Path).

6. On port AA1, advertise the network on port E1 with a secondary AS path of AS=(A1

Path,1000,E1 Path).

7. On each AS, setup 254 hosts per AS.

8. Establish an LDP tunnel from each host on each AS from port NA1 to each host on each AS

on Port A1.

9. Bring up LDP.

10. On each host, setup pair traffic to the far end LDP host with respective addressing. Generate

all of the DiffServ codepoints in Table 1. Set traffic to bi-directional with standard iMIX

pattern frame size. Set the port rate to 90% of load on each port.

11. On each port, setup a dynamic view according to Table 1. Only show flows that do not meet

the criteria in table 1.

12. Start traffic.

13. On the same hosts per LDP tunnel, create HTTP servers with a 64-byte return object size.

Setup HTTP clients on both sides of each LDP tunnel (HTTP tunneled through topology

emulation through LDP).

14. On both hosts per LDP tunnel, create video and voice endpoints. Configure video as a looped

MPEG2-TS clip. Configure voice as SIP with signaling and a WAV file as RTP content, looped.

15. For HTTP, video, and voice, set the specification to bandwidth, ramp up in the first 30

seconds and sustain for a long duration of time.

16. Chart HTTP minimum Goodput, video minimum MOS-AV, and voice minimum MOS-LQ

scores alongside active BGP routes and active LDP sessions.

17. Start stateful traffic.

18. Measure the traffic quality score as a baseline.

19. On the E1 interface, stop BGP on all odd-numbered AS peers.

20. Watch as LDP repaths to secondary interfaces.

21. Note whether all LDP tunnels come up on the new interfaces.


8

22. Note whether the DUT forwards traffic to the old interfaces.

23. Measure the QoE and QoS scores during the transition.

24. Reverse the process, measure BGP, LDP and QoE and QoS Metrics.

25. Repeat Steps 19-24 ten times. Record the results.

26. End.

Control Variables & Relevance

Variable Relevance Default Value

BGP AS Paths Advertise unique Peers per port to stress the DUT. See Test Plan

QoS Traffic Add differentiated traffic. See Table 1

QoE Traffic Add multiplay across LDP over BGP. See Test Plan

Key Measured Metrics

Metric Relevance Metric Unit

BGP Peers Base routing element Count per port

LDP Primary and Secondary Path

Customer tunneled traffic Count and state per port

QoS Traffic Differentiated traffic to load the DUT queues

Compliant to Table 1

QoS Goodput, video and voice quality-of-experience metrics

Score, MOS score

Desired Result

When BGP primary paths fail, traffic should fail over to backup LDP paths and be rerouted in 100

ms or less to avoid TCP timeout and windowing issues on customer traffic. Non-failed traffic

should continue to forward with no loss in quality or count.

Analysis

For each test and reversal of test, plot the QoS and QoE metrics as a function of LDP tunnel

count. Measure and report how long it takes for HTTP goodput, minimum MOS-AV and MOS-LQ

and Table 1 QoS compliance to occur. This time should be 100 ms or less to avoid TCP timeout

and windowing issues. Also report non-failover traffic performance as fail over occurs. Is there an

effect on QoS/QoS when the DUT fails over traffic?


9

ROUTE_002 Verify that the DUT conforms to the RSVP-TE P2MP

make-before-break standard

Abstract

This test determines whether the DUT obeys the P2MP RSVP-TE make-before-break command

and builds a new tunnel with an optimized LSP and then tears down the old path. In this test

case, test ports establish P2MP RSVP-TE tunnels to multiple destinations through the DUT, create

an optimized path and issue the make-before-break command at the tunnel level. A new tunnel

LSP should be built, LSP ID should be incremented by one and then the existing tunnel path

should be removed. This whole process shouldn’t interrupt traffic flow.

Description

Some major service providers across the world have adopted the RSVP-TE P2MP technology for

reliable multicast delivery and achieve a high level of QoE. The make-before-break feature

ensures that backup resources are always allocated in case some of the delivery paths become

sub-optimized or cut-off, due to various reasons like topology changes, hardware issues etc.,

assuring that there is no service disruption for the end user.

Target Users

Anyone running RSVP-TE P2MP Tunneling tests.


Core Routers with RSVP-TE P2MP support

Reference

RFC 4875

Relevance

This test case shows that the DUT conforms to the P2MP RSVP-TE make-before-break feature as

described in RFC 4875.

Version

1.0

Test Category

Testing core routing and tunneling

PASS

[x] Performance [ ] Availability [ ] Security [ ] Scale


10


The tester needs to support:

RSVP-TE P2MP emulation

Make-before-break feature

Real-time LSP results display showing the change in the tunnel state and LSP ID

A sequencer within the GUI which can be configured to build and loop the desired test

Ability to change the parameters on the fly without interrupting the test

Dynamic label binding capability

Sequencing counters to verify no traffic is dropped

Ability to emulate a real network

Topology Diagram

Test Procedure

1. Create a RSVP-TE P2MP configuration using a wizard (if available) or manually.

a. Configure more than one LSPs per tunnel. The number of EROs at the sub-LSP

level should match the number of LSPs/tunnel count.

2. Enable make-before-break.

3. Bring up RSVP-TE and the IGP.

4. See the LSP real-time results for the tunnel state machine and other info (i.e. LSP ID).

5. Start traffic.


11

6. Initiate the make-before-break command.

7. Verify that the paths come up and bind normally.

8. The LSP ID of the Ingress/Egress tunnels should increment by 1.

9. The labels should increment by .1

10. Traffic shouldn’t be interrupted and there should be no dropped frames.

11. Optionally, increase the number of tunnels and EROs to scale up the configuration and

perform Step 2 thru 9.

12. Optionally repeat the make-before-break command and observe the effect. The LSP ID

should increment by 1 each time.

13. End test.



Number of LSPs per Tunnel

Must be more than one for the make-before-break feature to work. Increase the number of LSPs/Tunnel for scaled testing.

2

Number of EROs Number of EROs at the sub-LSP should match the number of LSPs/tunnel count.

2


Matric Relevance Metric Unit

LSP ID LSP ID should increment by one every time the make-before-break command is initiated.

LSP ID number per tunnel

Tunnel State Shouldn’t be affected by initiating the make-before-break command.

Up/Down

Desired Result

Initiating the make-before-break command should build a new LSP path to the destination and

the LSP ID should be incremented by one. This process should be seamless and there should be

no traffic loss.

Analysis

Initiating the make-before-break command should build a new LSP path to the destination and

then tear down the original path. The LSP ID should be incremented by one. This process should

be seamless and there should be no traffic loss.


12

ROUTE_003 Verify that the DUT supports multi-topology IS-IS

Abstract

This test case determines whether the DUT can support multi-topology IS-IS. In this test case, we

build an IS-IS topology with both IPv4 and IPv6 routers in the same area and bring up the

adjacencies.

Description

There are a number of emerging, competing technology/proposals to interconnect the islands of LAN (LAN interconnects) in the data center and service provider segments by leading NEMS. Most of the proposals involve using IS-IS as the control protocol. These emerging technologies are alternatives to L2VPN and MPLS/VPLS. The one proposed by Cisco is called OTV (Overlay Transport Virtualization) and Nortel/Avaya has proposed PBB/PBT/PLSB (Provider Link State Bridging). Both the technologies make use of MT-IS-IS as a foundation for distributing the LAN topology between different LAN domains. Hence, it becomes increasingly important to support and test this feature on the DUT. In this test case, test ports emulate IS-IS v4 and v6 routers within the same domain and establish adjacencies with the DUT. The DUT should be able to successfully establish these adjacencies and maintain them for an extended period of time.

Target Users

Engineering, Product Verification, Integration Testers


Any ISIS supported deployment where both IPv4 and IPv6 are configured together.

Reference

RFC 5120

Relevance

This test case shows that the DUT conforms to the multi-topology IS-IS standards.

Version

1.0

Test Category


PASS

[x] Performance [ ] Availability [ ] Security [ ] Scale


13


The tester needs to support:

Multi-topology IS-IS emulation

Real-time counters showing the IS-IS control plane state diagram

Topology Diagram

Test Procedure

1. Create an emulated IS-ISv4 and IS-ISv6 device in the same level/domain.

2. Bring up the adjacencies.

3. Using the real-time counters, verify that the adjacencies come up.

4. Scale the number of v4 and v6 IS-IS routers up to the DUT limit and verify that it can stay

up.

5. End test.



Number of IS-IS v4/v6 routers

Number of IS-IS v4 and v6 routers configured per device 1


14



Router State Should go from down to full when the adjacency is established.

Down/Full

Desired Result

The DUT should be able to establish and maintain IS-IS v4/v6 adjacencies.

Analysis

The DUT should be able to establish and maintain IS- IS v4/v6 adjacencies.

If it does not, troubleshoot the issue using the real-time control plane counters to isolate the

problem. Also use control plane captures to determine whether the protocol exchange messages

comply with RFC 5120.


15

ROUTE_004 BGP peer, route, and AS capacity test

Abstract

BGP peer performance is a critical attribute of a service routers performance. In this test, the

number of peers, routes, and autonomous systems scale until failure. Finding the upper limits is a

critical requirement for router planning and deployment.

Description

BGP routing performance is based on many factors including route scale, peer scale, and AS

scale. The device under test must have the ability to scale to a high number of BGP peers without

loss of performance on the control plane and the data plane. This test enables the user to

determine the upper boundaries of BGP performance on the device under test across multiple

vectors, including peer, route, and AS. Configure routing on the DUT to the upper limits of the

DUT. The test scales the number of BGP peers, routes and emulated AS connected to the DUT.

This test case also sets up data plane traffic over routing. The data plane is inspected for a peak

of 20 uSec latency. The test results include the peak number of routes, peers, and AS of the DUT.

Target Users

Performance test, scale test, and engineering.


The intended device under test for this test case includes core BGP router, distribution routers,

virtualized routers, and edge PE routers.

Reference

RFC 1771, RFC 4271, RFC 4193

Relevance

This test case determines not only the upper low performance limits of the DUT, but also the true

real-world routing performance with traffic. This demonstrates that the DUT has the ability to

establish a high rate of peers, AS, and routes and to actively use those networking structures

while maintaining service quality levels in a real-world production network.

Version

1.0

Test Category

Core routing and tunneling

PASS

[ ] Performance [ ] Availability [ ] Security [x] Scale


16


The tester must have the ability to emulate BGP routing protocols that scale to high-performance

across multiple vectors including BGP peers, routes, and AS. The tester must have the ability to

add control plane traffic while the existing control plane is up. This is critical because the user

needs the ability to test new control plane relationships while existing BGP peers are up and

providing stress against the DUT control fabric. The tester must have the ability to emulate

advanced BGP route attributes that change from peer-to-peer as in a production network. This is

important because the majority of the control plane processing by the DUT is for BGP route

attributes. On the traffic side, the tester must have the ability to align traffic to routes, create

true QoS, and analyze QOS without tearing down traffic. This is important because high rate

traffic can provide high degrees of instantaneous QoS stress on the DUT switch fabric.

Topology Diagram

Test Procedure

1. Reserve two test interfaces. Connect them to the DUT and name them East and West.

2. Configure the DUT for IP Routing for BGP.

3. Select IBGP or EBGP, the percentage of IPv4 routes advertised and the percentage of IPv6

routes advertised. Configure the DUT AS number and type (2-bytes or 4-byte) and the

beginning emulated AS numbers for each test interface.

4. Configure the initial number if BGP peers, evenly divided between the East and West test

interfaces.

5. Use binary search to scale up the number for BGP peers from the starting BGP peer count

until failure is detected. If EBGP was selected, then set the DUT AS and an incrementing AS

on both East and West test interfaces, otherwise set the emulated BGP peers to the DUT AS.


17

6. Report the peak number of BGP peers achieved by the DUT. If EBGP was selected, report the

range of successful AS emulated.

7. With the peak number of BGP peers emulated and running, add route blocks. Set the AS

Path to <DUT AS>,<Emulated Peer AS>. Create one route block for IPv4 routes and, if IPv6

routes are desired, add a second block for IPv6 Routes.

8. Select binary search to determine the peak number of routes using the following procedure:

a. Choose total routes.

b. Divide the total number of routes across each emulated BGP peer on both interfaces.

c. Sub-divide each allocated number of routes as a percentage of IPv4 and IPv6 routes.

d. Generate pair-based traffic between IPv4 routes and IPv6 routes respectively.

e. To pass, the DUT must pass traffic across any traffic pair within 20 usec or less of

maximum latency.

9. Report the peak number of routes achieved by the DUT.

10. End.


18



EBGP or IBGP Test interior or exterior BGP session EBGP

% of IPv4 Routes Percentage of IPv4 routes to emulate 100%

% of IPv6 Routes Percentage of IPv6 routes to emulate 0%

2-Byte or 4-Byte AS BGP AS class 2-bytes starting at AS2

East Interface Starting IPv4 Route

Beginning IPv4 route for BGP on the East interface

1.0.1.0 /24

West Interface Starting IPv4 Route

Beginning IPv4 route for BGP on the West Interface

100.0.1.0/24

East Interface Starting IPv6 Route

Beginning IPv6 route for BGP on the East interface

2001::0 /64

West Interface Starting IPv6 Route

Beginning IPv6 route for BGP on the West Interface

2400::0/64



Peak BGP Peers Maximum number of BGP peers achievable in the DUT RIB (Routing Information Base)

Count

Peak EBGP AS Total number of external BGP peers achievable by the DUT

Count

Peak IPv4 verified Routes

Number of IPv4 Routes achievable Count

Peak Verified IPv6 Routes

Number of IPv6 Routes achievable Count

Desired Result

A modern BGP router should cache approximately 4000-5000 EBGP peers and over 2 million

routes.

Analysis

Examine the number of BGP peers that are routable in the RIB and the time it takes per peer to

setup the RIB database entry. Look at the number of advertised routes and the peak latency

across routes while new peers are added. Pay special attention to loss of forwarding or routing

performance as peers are added.


19

ROUTE_005 OSPF adjacency and route capacity test

Abstract

The OSPF network capacity test is a critical measure of a service router’s ability to perform key

network interchanges. This test scales the number of OSPF adjacencies and attached network

routers while actively transmitting traffic. Finding real-world performance is a critical

requirement for OSPF topology network planning.

Description

Open Shortest Path First (OSPF) is a resource intensive interior gateway protocol that can be a

bottleneck to the DUT. The management of OSPF adjacencies in the OSPF RIB can take

substantial switch fabric resources and tax the memory and queuing to abilities of the DUT. This

test case determines the peak OSPF adjacency capacity of the DUT. Beginning with the desired

number of emulated test interfaces and the initial starting point for a number of OSPF

adjacencies, the test scales the number of adjacencies until OSPF can no longer be established.

Once the peak number of OSPF adjacencies is determined, the system scales the number of

attached networks advertised through those adjacencies as routes. After a route is advertised

into the network, the system places traffic the connection, stimulating the OSPF RIB database.

Target Users

Functional test, system test, engineering, and marketing.


A high performance IGP enabled router with OSPF support.

Reference

RFC 2338

Relevance

The scalability performance of both adjacencies and emulated routes is an important attribute

of OSPF enabled routers. The number of emulated OSPF adjacencies determines how many

physical routers must be deployed in the core of the network to maintain a minimum degree of

QoS and QoE within the network. The scalability performance of routes reveals how scalable the

DUT truly is for future deployment.

Version

1.0

Test Category



20

PASS

[ ] Performance [ ] Availability [ ] Security [x] Scale


The tester must be able to emulate OSPF on every port even in large port densities. The

emulated protocol has the ability to bring up adjacencies while other adjacencies are in play, in

addition to advertising changing route blocks. The tester must be able to generate traffic from

OSPF routes live while other traffic is in place.

Topology Diagram

Test Procedure

1. Reserve the desired number of test interfaces, connect them to their respective device

under test ports, and bring up the link.

2. Configure the starting point for the number of adjacencies to be emulated to the DUT.

Evenly divide the number of provided adjacencies across the selected test interfaces. This is

the number of beginning OSPF adjacencies to emulate per port.

3. Begin a linear search starting at the recommended beginning number of OSPF adjacencies

per port.

a. Add an adjacency per port and increment the host device source IP.

b. Determine whether the OSPF adjacency came up.

c. If the adjacency was established, loop back to number one within the section.

d. If the adjacency was not established, the peak number of OSPF adjacencies per port has

been reached. Total the number of estimated OSPF adjacencies across all emulated test

interfaces to determine the peak number of OSPF adjacencies that may be established

against the DUT.

4. Once the peak OSPF adjacency capacity has been determined, the peak advertised route

capacity is determined. A successfully processed route within the OSPF RIB in the DUT means


21

that not only can the DUT accept the emulated route but can also pass bidirectional traffic

from that route to a foreign route learned from another adjacency within the OSPF RIB.

5. Configure the starting point number of OSPF routes to be advertised globally.

6. Begin a linear search for the total OSPF route capacity:

a. Advertise the selected number of OSPF routes. The first route on the first port on the

first adjacency should be 1.0.0.0.

b. Create a full mesh of traffic from all routes to all routes across the DUT switch fabric.

c. Burst exactly one packet across each route.

d. If no packet loss occurs, add one route per adjacency and loop to step one.

e. If packet loss occurs then the peak capacity of advertised routes across the OSPF RIB has

been reached.

7. End of test.



Beginning Number of OSPF Adjacencies Capacity metric of DUT 100 per port

Beginning Number of Routes w/ traffic Capacity metric of DUT 5,000 router LSAs



Measured number of OSPF Adjacencies Capacity metric of the DUT Count of adjacencies

Measured Peak Routes w/ Traffic Capacity metric of the DUT Number of router LSAs

Desired Result

The DUT should be able to maintain at least 150 adjacencies, double if in a virtual network

environment, and at least 20,000 network LSAs.

Analysis

Examine the number of adjacencies and routes advertised and stored within the DUT. If a route

experiences sequencing errors such as packet loss, reorder, or duplication, or latency in excess of

10 uSec across the DUT, then the traffic path fails. Report the number of adjacencies and routes

learnable by the DUT.


22

ROUTE_006 mVPN test

Abstract

This test determines whether the DUT has the ability to support multicast VPN and pass labeled

multicast traffic. In this test case, the tester emulates CE, P and PE devices and customer and

provider side VPNs along with the required protocols. It also creates multicast traffic to run

between VPNs. The VPN tunnels should be successfully established and labeled multicast traffic

should be able to successfully pass through the DUT.

Description

MPLS IP VPN (unicast) became a popular method of connecting different LANs/networks and

providing VPN support for service providers due to the simplicity and the ease of deployment.

However, multicast was not supported on these traditional IP VPN (RFC2547-based) networks.

Recently multicast became the preferred method of delivering content for audio/video

streaming, software downloads and critical financial applications. A new draft was written to

support multicast traffic over these VPNs. It borrows heavily from the RFC2547 implementation,

but additionally uses protocols like GRE and PIM on both the customer and the provider side.

GRE is used to encapsulate multicast traffic for transport across the IP network and a point-to-

multipoint GRE tunnel is built from the multicast source to the receivers. This formation is also

called MDT or multicast distribution tree. PIM is used on both the customer side (to attach

multicast sources and receivers) and the provider side (to signal MDT).

In this test, test ports emulate the customer side (CE, VPN sites) connected to the DUT (usually

PE) which in turn are connected to other test ports emulating the provider side (P,PE, CE and VPN

sites). The IGP, MPLS and PIM protocols should come up successfully and labels should be

appropriately bound. The GRE tunnels should successfully come up and we should be able to

successfully pass multicast data through the DUT.

Target Users

NEMs and service providers testing mVPN


Core routers with multicast VPN support

Reference

Draft-rosen-vpn-mcast-08.txt, RFC 2547, RFC 4364

Relevance

This test case determines whether the DUT is able to successfully bring up the GRE/VPN tunnels

between the customer and provider and pass multicast traffic through it.

Version

1.0


23

Test Category


PASS

[x] Performance [ ] Availability [ ] Security [x] Scale


Ability to emulate a real network topology

Multicast VPN emulation support

Real-time counters showing the corresponding control and data plane stats

Ability to change configuration on the fly

GRE tunneling

Dynamic label assignment capability

Separately control unicast and multicast traffic

Switchover capability between the default and data MDT

Topology Diagram

MPLS Network

Site A

Site BCE Router P Router

CE Router

CE Router

Site C

Site DPE Router

PE Router

PE Router

IP Traffic MPLS Labeled IP Traffic IP Traffic

IGP/PIM/RSVP-TEIGP/PIM IGP/PIM

Unicast VPN/VRF

P2MP GRE Tunnel VRF

Multicast

Sender

Multicast

ReceiversMulticast

Receivers

Test Procedure

1. Use the Multicast VPN Wizard.

a. Select the provider side ports.

i. Configure the IGP (OSPF, ISIS, RIP etc.) and the MPLS (RSVP-TE or LDP) protocols.

ii. Configure the emulated P and PE routers with appropriate IP addressing and scale.

1. Optionally, for BGP, enable Route Reflectors and/or BFD.

b. Select the customer-side ports.

c. Configure the VRFs.

i. Configure the number of VPNs and how they are assigned (Round

Robin/Sequential) – if more than 1 CE.

DU

T

Test Port 2 Test Port 1


24

ii. Select the CE protocol (BGP, OSPF, RIP, ISIS or Mixed).

iii. Select the RD assignment (Router Target or Manual).

1. If RT, configure the appropriate values.

2. If Manual, configure appropriate values.

iv. Configure the VRFs per PE.

d. Configure the PIM type and parameters for both the customer and provider sides.

e. Configure the Default MDT and Group addresses.

f. Optionally configure the Data MDT and PIM Type.

g. Configure the VRF Route Ranges and the Starting Label number.

h. Configure the VRF Traffic – select end points as well as customer and provider Load %

and the Frame Size.

i. Optionally, configure Unicast Traffic.

i. Finish the Wizard.

2. Start the protocol emulation and verify that they come up. Verify that the GRE tunnel comes

up, that unicast traffic is established, and that the MPLS labels bind.

3. Start multicast traffic and verify that the receive test port receives the multicast and unicast

traffic (if configured) appropriately

4. Verify that no traffic loss occurs.

5. Optionally configure MDT Switchover.

6. Scale the number of P, PE, CE and/or VRF routes until frames are dropped.

7. End of test.



Number of P Routers on the provider side

Emulated routers connected directly to the DUT. The more P routers, the more taxing for the DUT.

1

Number of PE routers per P router

Emulated PE routers which will have the VRF configurations.

2

Number of VPNs/CE VPN sites per CE/sub-interface on the customer side. 1

Number of VRFs/PE VRFs per PE on the provider side. Equal to the number of VPNs/CE on the customer side.

1

Provider and customer PIM Protocol Type

PIM-SM or PIM-SSM PIM-SM

Data MDT Allows testing the switchover scenario from the default MDT

Not enabled



IGP Protocols State Machine

All IGP protocols should come up successfully and tunnels should be established properly for traffic flow.

Up, Down, Established, Full

Multicast Protocols State Machine

Both the customer and provider PIM are vital to build the MDT and associate the source and receivers for the traffic to flow successfully.

Neighbor/Down

Number of Tunnels

All configured tunnels should be UP for traffic to flow successfully.

Up/Down


25


Latency per stream

Should be within the expected range of the DUT. Microseconds

Packet loss, Sequencing issues

Any packet loss or sequencing issues, such as duplicate, re-ordered, or late packets, indicate an issue with the DUT’s traffic forwarding capability.

Whole number

Desired Result

The configured GRE/VPN tunnels should come up successfully and the multicast/unicast traffic

should successfully pass through the DUT.

Analysis

The configured IGP Protocols (BGP, OSPF, RIP or ISIS), GRE/VPN tunnels, PIM, MPLS protocols

(RSVP-TE or LDP) should come up successfully and the multicast/unicast traffic should flow

successfully.

Check the state machine of any protocol that doesn’t come up and verify that the tester

configuration matches the DUT.


26

ROUTE_007 MPLS IP VPN test

Abstract

This test determines whether the DUT has the ability to support IP VPN and pass labeled

multicast traffic. In this test case, test ports emulate CE, P and PE devices and customer and

provider side VPNs using the required protocol. The VPN tunnels should be successfully

established and labeled traffic should be able to successfully pass through the DUT.

Description

MPLS IP VPN (unicast) has become a popular method of connecting different LANs/networks and

providing VPN support for the service providers due to the simplicity and the ease of

deployment.

In this test, test ports emulate the customer side of the configuration (CE, VPN sites) connected

to the DUT (usually PE) which in turn is connected to other test ports emulating the provider side

of the configuration (P,PE, CE and VPN sites). The IGP and the MPLS protocols should come up

successfully and labels should be appropriately bound. The VPN tunnels should come up and the

DUT should be able pass traffic.

Target Users

NEMs and service providers testing MPLS and labeled traffic forwarding


Core routers

Reference

RFC 2547, RFC 4364 (Obsolete RFC 2547)

Relevance

This test case determines whether the DUT can bring up the VPN tunnels between the customer

and provider and pass labeled traffic.

Version

1.0

Test Category


PASS

[x] Performance [ ] Availability [ ] Security [x] Scale


27



RFC 2547 emulation


Ability to change configuration on the fly


Separate control of unicast and multicast traffic

Topology Diagram

Site C

Site D

Site A

Site B

CE Router

CE Router

CE Router

PE Router

PE Router

PE Router P Router

DUT

Spirent TestCenter Port 2Spirent TestCenter Port 1

Test Procedure

1. Use the RFC 2547 (MPLS IP VPN) Wizard.

a. Select the provider-side ports.

i. Configure the IGP (OSPF, ISIS, RIP etc.) and MPLS (RSVP-TE or LDP) protocols.








iii. Select the RD assignment (Router Target or Manual),




d. Configure the VRF Route Ranges and the Starting Label number.

e. Configure the VRF Traffic. Select end points and customer and provider Load % and the

Frame Size.

f. Finish the Wizard.

2. Start protocol emulation and verify that they come up. Verify that the VPN tunnels come up,

the MPLS labels bind, and that traffic passes successfully.


28

3. Scale the number of P, PE, CE and/or VRF routes until frames are dropped.

4. End of test.




Emulated routers directly connected to the DUT. The more P routers, the more taxing for the DUT.

1


Emulated PE routers with VRF configurations. 2



1






Number of Tunnels All configured tunnels should be UP for traffic to flow successfully.

Up/Down

Latency per stream Should be within the expected range of the DUT. Microseconds

Packet loss, Sequencing issues

Packet loss or sequencing issues, such as duplicate, re-ordered, or late packets, indicate an issue with the DUT’s traffic forwarding capability.

Whole number

Desired Result

The configured VPN tunnels should come up successfully and multicast/unicast traffic should

successfully pass through the DUT.

Analysis

The configured IGP Protocols (BGP, OSPF, RIP or ISIS), GRE/VPN tunnels, MPLS Protocols (RSVP-

TE or LDP) should come up successfully and the VPN traffic should flow successfully.




29

ROUTE_008 Determine whether the DUT supports LSP Ping (MPLS

OAM)

Abstract

This test determines whether the DUT supports LDP LSP Ping messages (part of MPLS OAM) and

sends correct return codes.

Description

MPLS IP VPN has become a popular method of connecting different LANs/networks and

providing VPN support for service providers due to the simplicity and the ease of deployment.

Traditional MPLS networks have no inherent OAM mechanism. New standards are being

developed to address that requirement. LSP Ping is part of that effort. It supports fault

determination within the various nodes of the network and troubleshooting in case of an issue.

In this test, test ports emulate the customer side of the configuration (CE, VPN sites) connected

to the DUT (usually PE) which in turn are connected to other test ports emulating the provider

side of the configuration (P,PE, CE and VPN sites). The LSP Ping feature is enabled on the P and PE

routers on the provider side of the network. The IGP and the MPLS protocols should come up

successfully and labels should be appropriately bound. The VPN tunnels should successfully come

up and should be able to pass traffic. The DUT should respond with the correct codes for all the

LSP Ping packets that are sent.

Target Users

NEMs and service providers


Core routers

Reference

RFC 4369

Relevance

This test case determines the DUT is able to respond to LSP Ping messages and reply with the

correct codes.

Version

1.0

Test Category



30

PASS

[x] Performance [x] Availability [ ] Security [ ] Scale



MPLS IP VPN emulation

LSP Ping feature support


Ability to change configuration on the fly without affecting the control or the data plane


Topology Diagram

Site C

Site D

Site A

Site B

CE Router

CE Router

CE Router

PE Router

PE Router

PE Router P Router

DUT

Spirent TestCenter Port 2Spirent TestCenter Port 1

Test Procedure

1. Use the RFC 2547 (MPLS IP VPN) Wizard.

a. Select the provider-side ports.

i. Configure the IGP (OSPF, ISIS, RIP etc.) and the MPLS (RSVP-TE or LDP) protocols.








iii. Select the RD assignment (Router Target or Manual).




d. Configure the VRF Route Ranges and the Starting Label number.

e. Configure the VRF Traffic. Select end points and customer and provider Load % and the

Frame Size.


31

f. Enable LSP Ping on both the Core and the VPN tunnels.

i. Optionally, if it isn’t enabled in the wizard, it can be enabled on a per-P/PE basis in

the main configuration window.

g. Finish the Wizard.

h. Input the appropriate parameters for the Echo Request/Replies.

2. Start protocol emulation and verify that they come up. Verify that the VPN tunnels come up,

that the MPLS labels bind, and that the traffic passes successfully.

3. Start the LSP Pings and verify that the correct return codes are sent from the DUT, showing

results per FEC..

4. Introduce faults on the DUT, such as mis-matched labels, broken LDP adjacencies and other

software/hardware errors, and verify that the appropriate return codes appear in the

results.

5. End of test.




Emulated routers directly connected to the DUT. The more P routers, the more taxing for the DUT.

1


Emulated PE routers with VRF configurations. 2



1

LSP Ping operation mode Construct the outgoing ping packet. IP/UDP

Ping Interval The time between each ping request. 5 seconds

Ping Time Out Time until the ping request is declared dead. 2 seconds

Time to Leave Hops before the packet is discarded by the forwarding router.

1

EXP bits QoS bits for MPLS. 0

Validate FEC Stack Option to validate the FEC to which the ping is sent. Not checked

Destination IPv4 Address IP address to which the ping is sent. 127.0.0.1






Number of Tunnels All configured tunnels should be UP for traffic to flow successfully.

Up/Down

LSP Ping Up Count Determines whether LSP Ping emulation is running for that particular P/PE router.

Up/Down

Tx Echo Request Transmitted ping counts per emulated P/PE router. Whole number

Rx Echo Reply Received ping reply count per emulated P/PE router. Whole number

Rx Echo Request Received ping counts from the DUT per emulated P/PE router.

Whole number

Tx Echo Reply Transmitted ping replies to the DUT per emulated P/PE router.

Whole number


32


Min, Avg and Max Ping latency

The minimum, average and max ping latency per emulated P/PE router.

Ms

Rx Return Code Code the DUT returns to the Echo request sent by the tester.

Defined in the specification

Desired Result

The configured VPN tunnels should come up successfully and the multicast/unicast traffic should

successfully pass through the DUT.

The DUT should receive and appropriately process the LSP Ping/Echo messages.

Analysis

The configured IGP Protocols (BGP, OSPF, RIP or ISIS), GRE/VPN tunnels, MPLS Protocols (RSVP-

TE or LDP) should come up successfully and the VPN traffic should flow successfully.



The DUT should receive and appropriately process the LSP Ping/Echo messages and return the

appropriate codes.

The DUT should also be able to reply with the correct codes when a fault or multiple faults are

introduced.


33

Appendix A – Telecommunications

Definitions

APPLICATION LOGIC. The computational aspects of an application, including a list of instructions that tells a

software application how to operate.

APPLICATION SERVICE PROVIDER (ASP). An ASP deploys hosts and manages access to a packaged application by

multiple parties from a centrally managed facility. The applications are delivered over networks on a

subscription basis. This delivery model speeds implementation, minimizes the expenses and risks incurred

across the application life cycle, and overcomes the chronic shortage of qualified technical personnel

available in-house.

APPLICATION MAINTENANCE OUTSOURCING PROVIDER. Manages a proprietary or packaged application from

either the customer's or the provider's site.

ASP INFRASTRUCTURE PROVIDER (AIP). A hosting provider that offers a full set of infrastructure services for

hosting online applications.

ATM. Asynchronous Transport Mode. An information transfer standard for routing high-speed, high-

bandwidth traffic such as real-time voice and video, as well as general data bits.

AVAILABILITY. The portion of time that a system can be used for productive work, expressed as a

percentage.

BACKBONE. A centralized high-speed network that interconnects smaller, independent networks.

BANDWIDTH. The number of bits of information that can move through a communications medium in a

given amount of time; the capacity of a telecommunications circuit/network to carry voice, data, and

video information. Typically measured in Kbps and Mbps. Bandwidth from public networks is typically

available to business and residential end-users in increments from 56 Kbps to 45 Mbps.

BIT ERROR RATE. The number of transmitted bits expected to be corrupted per second when two computers

have been communicating for a given length of time.

BURST INFORMATION RATE (BIR). The rate of information in bits per second that the customer may need over

and above the CIR. A burst is typically a short duration transmission that can relieve momentary

congestion in the LAN or provide additional throughput for interactive data applications.

BUSINESS ASP. Provides prepackaged application services in volume to the general business market,

typically targeting small to medium size enterprises.

BUSINESS-CRITICAL APPLICATION. The vital software needed to run a business, whether custom-written or

commercially packaged, such as accounting/finance, ERP, manufacturing, human resources and sales

databases.


34

BUSINESS SERVICE PROVIDER. Provides online services aided by brick-and-mortar resources, such as payroll

processing and employee benefits administration, printing, distribution or maintenance services. The

category includes business process outsourcing (BPO) companies.

COMMERCE NETWORK PROVIDER. Commerce networks were traditionally proprietary value-added networks

(VANs) used for electronic data interchange (EDI) between companies. Today the category includes the

new generation of electronic purchasing and trading networks.

COMPETITIVE ACCESS PROVIDER (CAP). A telecommunications company that provides an alternative to a LEC

for local transport and special access telecommunications services.

CAPACITY. The ability for a network to provide sufficient transmitting capabilities among its available

transmission media, and respond to customer demand for communications transport, especially at peak

usage times.

CLIENT/DEVICE. Hardware that retrieves information from a server.

CLUSTERING. A group of independent systems working together as a single system. Clustering technology

allows groups of servers to access a single disk array containing applications and data.

COMPUTING UTILITY PROVIDER (CUP). A provider that delivers computing resources, such as storage, database

or systems management, on a pay-as-you-go basis.

CSU/DSU. Channel Server Unit/Digital Server Unit. A device used to terminate a telephone company

connection and prepare data for a router interface.

DATA MART. A subset of a data warehouse, intended for use by a single department or function.

DATA WAREHOUSE. A database containing copious amounts of information, organized to aid decision-

making in an organization. Data warehouses receive batch updates and are configured for fast online

queries to produce succinct summaries of data.

DEDICATED LINE. A point-to-point, hardwired connection between two service locations.

DEMARCATION LINE. The point at which the local operating company's responsibility for the local loop ends.

Beyond the demarcation point (also known as the network interface), the customer is responsible for

installing and maintaining all equipment and wiring.

DISCARD ELIGIBILITY (DE) BIT. Relevant in situations of high congestion, it indicates that the frame should be

discarded in preference to frames without the DE bit set. The DE bit may be set by the network or by the

user; and once set cannot be reset by the network.

DS-1 OR T-1. A data communication circuit capable of transmitting data at 1.5 Mbps. Currently in

widespread use by medium and large businesses for video, voice, and data applications.

DS-3 OR T-3. A data communications circuit capable of transmitting data at 45 Mbps. The equivalent data

capacity of 28 T-1s. Currently used only by businesses/institutions and carriers for high-end applications.


35

ELECTRONIC DATA INTERCHANGE (EDI). The electronic communication of business transactions (orders,

confirmations, invoices etc.) of organizations with differing platforms. Third parties provide EDI services

that enable the connection of organizations with incompatible equipment.

ENTERPRISE ASP. An ASP that delivers a select range of high-end business applications, supported by a

significant degree of custom configuration and service.

ENTERPRISE RELATIONSHIP MANAGEMENT (ERM). Solutions that enable the enterprise to share comprehensive,

up-to-date customer, product, competitor and market information to achieve long-term customer

satisfaction, increased revenues, and higher profitability.

ENTERPRISE RESOURCE PLANNING (ERP). An information system or process integrating all manufacturing and

related applications for an entire enterprise. ERP systems permit organizations to manage resources

across the enterprise and completely integrate manufacturing systems.

ETHERNET. A local area network used to connect computers, printers, workstations, and other devices

within the same building. Ethernet operates over twisted wire and coaxial cable.

EXTENDED SUPERFRAME FORMAT. A T1 format that provides a method for easily retrieving diagnostics

information.

FAT CLIENT. A computer that includes an operating system, RAM, ROM, a powerful processor and a wide

range of installed applications that can execute either on the desktop or on the server to which it is

connected. Fat clients can operate in a server-based computing environment or in a stand-alone fashion.

FAULT TOLERANCE. A design method that incorporates redundant system elements to ensure continued

systems operation in the event of the failure of any individual element.

FDDI. Fiber Distributed Data Interface. A standard for transmitting data on optical-fiber cables at a rate of

about 100 Mbps.

FRAME. The basic logical unit in which bit-oriented data is transmitted. The frame consists of the data bits

surrounded by a flag at each end that indicates the beginning and end of the frame. A primary rate can be

thought of as an endless sequence of frames.

FRAME RELAY. A high-speed packet switching protocol popular in networks, including WANs, LANs, and

LAN-to-LAN connections across long distances.

GBPS. Gigabits per second, a measurement of data transmission speed expressed in billions of bits per

second.

HOSTED OUTSOURCING. Complete outsourcing of a company's information technology applications and

associated hardware systems to an ASP.

HOSTING PROVIDER. Provider who operates data center facilities for general-purpose server hosting and

collocation.

INFRASTRUCTURE ISV. And independent software vendor that develops infrastructure software to support

the hosting and online delivery of applications.


36

INTEGRATED SERVICES DIGITAL NETWORK (ISDN). An information transfer standard for transmitting digital voice

and data over telephone lines at speeds up to 128 Kbps.

INTEGRATION. Equipment, systems, or subsystem integration, assembling equipment or networks with a

specific function or task. Integration is combining equipment/systems with a common objective, easy

monitoring and/or executing commands. It takes three disciplines to execute integration: 1) hardware, 2)

software, and 3) connectivity – transmission media (data link layer), interfacing components. All three

aspects of integration have to be understood to make two or more pieces of equipment or subsystems

support the common objective.

INTER-EXCHANGE CARRIER (IXC). A telecommunications company that provides telecommunication services

between local exchanges on an interstate or intrastate basis.

INTERNET SERVICE PROVIDER (ISP). A company that provides access to the Internet for users and businesses.

INDEPENDENT SOFTWARE VENDOR (ISV). A company that is not a part of a computer systems manufacturer

that develops software applications.

INTERNETWORKING. Sharing data and resources from one network to another.

IT SERVICE PROVIDER. Traditional IT services businesses, including IT outsourcers, systems integrators, IT

consultancies and value added resellers.

KILOBITS PER SECOND (KBPS). A data transmission rate of 1,000 bits per second.

LEASED LINE. A telecommunications line dedicated to a particular customer along predetermined routers.

LOCAL ACCESS TRANSPORT AREA (LATA). One of approximately 164 geographical areas within which local

operating companies connect all local calls and route all long-distance calls to the customer's inter-

exchange carrier.

LOCAL EXCHANGE CARRIER (LEC). A telecommunications company that provides telecommunication services

in a defined geographic area.

LOCAL LOOP. The wires that connect an individual subscriber's telephone or data connection to the

telephone company central office or other local terminating point.

LOCAL/REGIONAL ASP. A company that delivers a range of application services, and often the complete

computing needs, of smaller businesses in their local geographic area.

MEGABITS PER SECOND (MBPS). 1,024 kilobits per second.

METAFRAME. The world's first server-based computing software for Microsoft Windows NT 4.0 Server,

Terminal Server Edition multi-user software (co-developed by Citrix).

MODEM. A device for converting digital signals to analog and vice versa, for data transmission over an

analog telephone line.

MULTIPLEXING. The combining of multiple data channels onto a single transmission medium. Sharing a

circuit - normally dedicated to a single user - between multiple users.


37

MULTI-USER. The ability for multiple concurrent users to log on and run applications on a single server.

NET-BASED ISV. An ISV whose main business is developing software for Internet-based application services.

This includes vendors who deliver their own applications online, either directly to users or via other

service providers.

NETWORK ACCESS POINT (NAP). A location where ISPs exchange traffic.

NETWORK COMPUTER (NC). A thin-client hardware device that executes applications locally by downloading

them from the network. NCs adhere to a specification jointly developed by Sun, IBM, Oracle, Apple and

Netscape. They typically run Java applets within a Java browser, or Java applications within the Java

Virtual Machine.

NETWORK COMPUTING ARCHITECTURE. A computing architecture in which components are dynamically

downloaded from the network onto the client device for execution by the client. The Java programming

language is at the core of network computing.

ONLINE ANALYTICAL PROCESSING (OLAP). Software that enables decision support via rapid queries to large

databases that store corporate data in multidimensional hierarchies and views.

OPERATIONAL RESOURCE PROVIDER. Operational resources are external business services that an ASP might

use as part of its own infrastructure, such as helpdesk, technical support, financing, or billing and payment

collection.

OUTSOURCING. The transfer of components or large segments of an organization's internal IT infrastructure,

staff, processes or applications to an external resource such as an ASP.

PACKAGED SOFTWARE APPLICATION. A computer program developed for sale to consumers or businesses,

generally designed to appeal to more than a single customer. While some tailoring of the program may be

possible, it is not intended to be custom-designed for each user or organization.

PACKET. A bundle of data organized for transmission, containing control information (destination, length,

origin, etc.), the data itself, and error detection and correction bits.

PACKET SWITCHING. A network in which messages are transmitted as packets over any available route rather

than as sequential messages over circuit-switched or dedicated facilities.

PEERING. The commercial practice under which nationwide ISPs exchange traffic without the payment of

settlement charges.

PERFORMANCE. A major factor in determining the overall productivity of a system, performance is primarily

tied to availability, throughput and response time.

PERMANENT VIRTUAL CIRCUIT (PVC). A PVC connects the customer's port connections, nodes, locations, and

branches. All customer ports can be connected, resembling a mesh, but PVCs usually run between the

host and branch locations.

POINT OF PRESENCE (POP). A telecommunications facility through which the company provides local

connectivity to its customers.


38

PORTAL. A company whose primary business is operating a Web destination site, hosting content and

applications for access via the Web.

REMOTE ACCESS. Connection of a remote computing device via communications lines such as ordinary

phone lines or wide area networks to access distant network applications and information.

REMOTE PRESENTATION SERVICES PROTOCOL. A set of rules and procedures for exchanging data between

computers on a network, enabling the user interface, keystrokes, and mouse movements to be

transferred between a server and client.

RESELLER/VAR. An intermediary between software and hardware producers and end users. Resellers

frequently add value (thus Value-Added Reseller) by performing consulting, system integration and

product enhancement.

ROUTER. A communications device between networks that determines the best path for optimal

performance. Routers are used in complex networks of networks such as enterprise-wide networks and

the Internet.

SCALABILITY. The ability to expand the number of users or increase the capabilities of a computing solution

without making major changes to the systems or application software.

SERVER. The computer on a local area network that often acts as a data and application repository and that

controls an application's access to workstations, printers and other parts of the network.

SERVER-BASED COMPUTING. A server-based approach to delivering business-critical applications to end-user

devices, whereby an application's logic executes on the server and only the user interface is transmitted

across a network to the client. Benefits include single-point management, universal application access,

bandwidth-independent performance, and improved security for business applications.

SINGLE-POINT CONTROL. One of the benefits of the ASP model, single-point control helps reduce the total

cost of application ownership by enabling widely used applications and data to be deployed, managed

and supported at one location. Single-point control enables application installations, updates and

additions to be made once, on the server, which are then instantly available to users anywhere.

SPECIALIST ASP. Provide applications which serve a specific professional or business activity, such as

customer relationship management, human resources or Web site services.

SYSTEMS MANUFACTURER. Manufacturer of servers, networking and client devices.

TELECOMS PROVIDER. Traditional and new-age telecommunications network providers (telcos).

THIN CLIENT. A low-cost computing device that accesses applications and and/or data from a central server

over a network. Categories of thin clients include Windows-Based Terminals (WBT, which comprise the

largest segment), X-Terminals, and Network Computers (NC).

TOTAL COST OF OWNERSHIP (TCO). Model that helps IT professionals understand and manage the budgeted

(direct) and unbudgeted (indirect) costs incurred for acquiring, maintaining and using an application or a

computing system. TCO normally includes training, upgrades, and administration as well as the purchase

price. Lowering TCO through single-point control is a key benefit of server-based computing.


39

TOTAL SECURITY ARCHITECTURE (TSA). A comprehensive, end-to-end architecture that protects the network.

TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL (TCP/IP). A suite of network protocols that allow

computers with different architectures and operating system software to communicate over the Internet.

USER INTERFACE. The part of an application that the end user sees on the screen and works with to operate

the application, such as menus, forms and buttons.

VERTICAL MARKET ASP. Provides solutions tailored to the needs of a specific industry, such as the healthcare

industry.

VIRTUAL PRIVATE NETWORK (VPN). A secure, encrypted private connection across a cloud network, such as

the Internet.

WEB HOSTING. Placing a consumer's or organization's web page or web site on a server that can be

accessed via the Internet.

WIDE AREA NETWORK. Local area networks linked together across a large geographic area.

WINDOWS-BASED TERMINAL (WBT). Thin clients with the lowest cost of ownership, as there are no local

applications running on the device. Standards are based on Microsoft's WBT specification developed in

conjunction with Wyse Technology, NCD, and other thin client companies.


40

Appendix B – Layer 2 802.1q CoS

The following tables represent best practices for Layer 2 VLAN / Q-in-Q CoS. Each row relates the

appropriate metric to measured minimum acceptable for its respective traffic class.

VLAN 802.1p CoS / Q-in-Q Priority

802.1 PRI CoS

Min. RX / TX Bandwidth

Ratio

Max Jitter (uSec)

Max Latency (uSec)

Max Loss

(Frames)



Max Late

(Frames)

7 1 0 >=1 0 0 0 0

6 1 0 2 0 0 0 0

5 .99 1 2 0 0 0 0

4 .98 1 3 0 0 0 0

3 .95 2 5 0 1 1 1

2 .90 3 5 1 1 1 1

1 .85 5 10 1 2 2 2

0 ANY ANY ANY ANY ANY ANY ANY


41

Appendix C – RFC 2474 Layer 3 QoS

The following tables represent best practices for Layer 2 VLAN / Q-in-Q CoS. Each row relates the

appropriate metric to measured minimum acceptable for its respective traffic class.

IPv4 / IPv6 DiffServ

Codepoint Max Jitter (uSec)

Max Latency (uSec)

Max Loss (Frames)



Max Late (Frames)

EF 0 >=1 0 0 0 0

AF31 0 2 0 0 0 0

AF21 2 5 0 1 1 1

AF11 3 5 1 1 1 1

BE ANY ANY ANY ANY ANY ANY


42

Appendix D – RFC 2474 Layer 3 QoS

Definitions

The following table represents the definitions of each DiffServ Codepoint possibility.

DSCP Value DF Code Point

Equivalent IP Precedent

Description

000 000 00 BE 000 - Routine Best Effort, Unclassified Quality

001 010 10 AF11 001 - Priority High-Throughput Transactions with high loss sensitivity

001 100 12 AF12 001 - Priority High-Throughput Transactions with some loss sensitivity

001 110 14 AF13 001 - Priority High-Throughput Transactions with loss resiliency

001 010 18 AF21 001 - Immediate Low-Latency Transactions with high loss sensitivity

010 100 20 AF22 001 - Immediate Low-Latency Transactions with some loss sensitivity

010 119 22 AF23 001 - Immediate Low-Latency Transaction with loss resiliency

011 010 26 AF31 011 - Flash Broadcast Media with high loss sensitivity

011 110 28 AF32 011 - Flash Broadcast Media with some loss sensitivity

011 110 30 AF33 001 - Flash Broadcast Media with loss resiliency

100 010 34 AF41 100 – Flash Override Live Media with high loss sensitivity

100 110 36 AF42 100 – Flash Override Live Media with some loss sensitivity

100 110 38 AF43 100 – Flash Override Live Media with loss resiliency

101 110 46 EF 101 – Critical Mission Critical Transactions or VoIP

spirent journal of core routing and tunneling pass … traffic, routing, and mpls protocols (e.g.,...

Documents