Answers to your Questions
What are the critical
scalability measures for L2oMPLS?
There are two scalability measures that are important for
Layer 2 over MPLS: the number of LDP targeted sessions and
the number of Virtual Circuits. The LDP targeted sessions
are established between the two Provider Edge (PE) routers
that are used to set up an L2oMPLs transport tunnel. A single
PE router may need to initiate LDP sessions with a large number
of PE routing peers (each LDP session also has an underlying
TCP session). Once each session is set up, a large number
of Virtual Circuits can be established over each of these
sessions, depending on how many Layer-2 connections need to
be supported over each PE pair.
What is the difference
between 'Martini' and 'Kompella' drafts, and which is more
commonly implemented?
The "Martini" drafts are contributions made to the IETF's
PWE3 (Pseudo Wire Emulation Edge-to-Edge) working group by
Luca Martini of Level 3 Communications and a number of other
authors. The "Martini-trans" draft defines the transport mechanism
using the LDP protocol. The "Martini-encaps" series of drafts
defines how the Layer-2 data traffic is encapsulated prior
to being carried in the MPLS network.
The "Kompella" draft is a contribution made to the PWE3 working
group by Kireeti Kompella of Juniper Networks and a number
of other authors. This draft defines the transport mechanism
using the BGP protocol. The "Kompella" draft recommends using
Martini-style encapsulation for traffic forwarding.
As for which is more common, nine vendors at the last Supercomm
event demonstrated interoperability for Ethernet over MPLS
using LDP, as defined in the "Martini" draft. The "Martini"
draft is clearly more commonly implemented in the market than
the "Kompella" draft. It is already being implemented and
evaluated by Service Providers.
My Edge Aggregation Device
not only terminates PPPoX sessions, but also tunnels them
using L2TP. How can I test this?
To test this scenario, the tester that you use should support
both PPPoX and L2TP stacks and should provide emulation of
LNS, LAC, and PPPoX clients. You can then initiate PPPoX sessions
and tunnel these through L2TP to measure such parameters as
tunnel scalability and sessions per tunnel, as well as to
test the robustness of your L2TP implementation by injecting
error conditions (tunnel ID mismatch, etc.).
I would like to test
a scenario wherein links go down and all PPPoX sessions are
terminated abruptly, followed by a burst of PPPoX session
establishment requests.
To test this scenario, the following steps are recommended:
- Initiate a large number of PPP sessions and wait until
they are all active.
- Cancel all sessions, thereby causing the PPP links to
go down suddenly. The SUT will realize that they are down
when it receives no response to its LCP Echo Requests.
- Now re-enable the sessions. This will result in a flood
of LCP Configure Requests. The SUT's performance after link
down can be verified based on how many links are re-activated.
Why is PPPoX Scalability
testing important?
PPP is a complex protocol: it requires a minimum of thirteen
protocol exchanges (LCP-4, CHAP-3, IPCP-6, etc.) to establish
a single session. Naturally, it is very important to test
the robustness of the protocol implementation when thousands
of authenticated PPP sessions have to be established over
a short period of time.
What kind of performance
measurements are relevant for PPPoX and L2TP?
The basic performance measurements follow general measurements
for IP traffic with the added complexity of sessions and tunnels.
The metrics are
- Session and tunnel setup/tear-down rate
- Session and tunnel scalability
- Sessions per tunnel
- QoS parameters (packets per second, packet loss, jitter,
etc.) with varying traffic mix.
|
Network Services 
