This page describes possible options of implementing QoS guarantees on Ethernet circuits in Geant network. We investigated two possible options. First options is to use the OTN layer to provision the circuit through the backbone, this option will be further described in section 1. Second option are MPLS-TE tunnels over IP/MPLS layer and will be described in section 2.

Use of the OTN layer

TODO: add OTN solution description MHY 

This chapter will describe the deployment of CCS over the OTN layer in Geant network. 

OTN CCS should provide the guaranteed QoS for GTS testbed's links. In order to do so, one OpenNSA instances needs to be deployed over the OTN switch in each GTS location plus over each intermediate switch between GTS locations in the Geant OTN topology. Unlike in IP/MPLS where LSPs creates virtual full mesh, in OTN network the OpenNSA has to configure each OTN switch along the circuit patch, not only devices where circuit terminates. OpenNSA will then configure each OTN switch participating on the circuit as well as handle the time slots assignment based on requested bandwidth. Minimal (and also default, when no bandwidth is specified) bandwidth of one circuit will be 1.25 Gbps. This is also a granularity of possible settings.  

In order to provide VLAN delineated circuits OTN devices in GTS locations have to be equipped by line cards supporting L2 features. (Possibly PXM cards for DTN-X platform.)

GTS data plane requirements per location.

 The GTS needs quiet a lot of dedicated 10GE ports per locations for data plane connections. Requirements for one pod are summarized in the following table. There are always three numbers separated by "/", the meaning is the following:  current(minimal)/expected soon/planned long term.  

In addition to these numbers, in CSF location 2 more ports are needed for GW links.    

Based in these numbers it seems that having one PXM card in a locations could become a bottle next for scaling up in the future as the PXM card is 16x10GE.

Steps needed for deploy the OTN based CCS for GTS

1. Learn the Geant OTN topology and prepare the OpenNSA topology to cover Amsterdam, Bratislava, Prague, Hamburg, London, Milan, Madrid and Paris. 
2. Deploy PXM cards in locations listed above. (Mean place an order for more, since Geant has not enough of them.) 
3. Implement OTN OpenNSA backend for Infinera DTN-X with PXM.   
4. Connect GTS equipment data plane ports to PXM.
5.  Reconfigure GTS

Ad 1: Geant OTN topology

Ad 5: Reconfigure GTS

Thanks to current abstract names of NSI STPs, it could be possible to just deactivate existing testbeds, reconfigure GTS for use of OTN and then activate testbeds again with links in OTN. 

Use of the MPLS-TE

MPLS-TE with the combination of ingress policing and egress HQOS shaping on Junos CCC L2VPN circuits. Hard policing should be avoided in order to prevent frequent packet losses due to out-of-profile traffic, whereas output shaping can be deployed in order to shape traffic and to introduce minimal traffic latency as a trade-off to traffic drop.

Nevertheless, policing is highly encouraged as a result of a notion that user can easily saturate individual circuit and inadvertently affect other circuits traversing the same links and devices. Traffic shaping should be carried out as a first step towards prevention of circuit congestion and it should behave as a form of soft policing where latency addition through buffering acts like a prevention of packet drop.

CLI configlets have been proposed as a result of using Junos Space backend and thus flexible configuration of policers and shapers on MX devices throughout the network.

Policer configuration

The use of traffic policer can be specified in several ways, each producing identical results concerning the limitation of bandwidth over the L2VPN circuit. Basic policer configuration is provided in the following inset containing bandwidth limit and burst size limit parameters.

Policer should be applied as a part of the filter inside which policer is referenced. Family any is specified in order to generalize the traffic family since the traffic could be IPv4, IPv6, MPLS or CCC depending on the policer application.

Such configured filter containing the policer may be applied on the interface (specifically, on the unit level) or on the LSP level. Both configuration scenarios are depicted in the following insets, respectively.

As it was mentioned, both configurations provide the same results, so from the traffic policing standpoint, either configuration may be applied. Bearing in mind that CCC L2VPN circuits are being used and that they allocate a single dedicated LSP for individual circuit, it may more structured to use LSP policing instead of policing on the ingress interface. Main reason for this proposal is the fact that single interface is used for multiple unit configuration which provide ingress into CCC dedicated LSPs. Since circuit establishment depends on specification of transmit and receive LSPs, policer filter must be applied on both sides of the circuit. This is also a mandatory with interface unit policing filters.

Traffic shaping configuration 

As a result of each user having its own circuit and there is a requirement for traffic shaping instead of doing hard policing, hierarchical QoS deployment is scalable and flexible approach for this use case as it allows configuration of shaping rate for each circuit egressing on the particular physical interface. Specifically, each interface unit may be configured with specific parameters regarding traffic classification, priority and guaranteed rate. For the purpose of this use case, shaping rate or peak information rate (PIR) is the crucial parameter determining shaping features.

Hierarchical QoS (HQoS) allows flexible per-unit deployment and configuration of shaping rates as well as committed information rate (CIR) and transmission rate per queue. For the purpose of this deployment and testing, shaping has to be deployed on an interface and on a unit level. Thus, putting interface in PIR-only mode according to which bandwidth is distributed proportionally to configured shaping-rate parameter. Interface is in PIR-only mode if none of the child interfaces are configured with guaranteed-rate parameter, i.e. when they do not have CIR parameter configured

HQOS configuration is depicted in the following inset:

Proposed configuration for the use case would be to configure physical interface PIR parameter and the shaping rates for each traffic-control-profile which would contain shaping-rate for the specific circuit. Proposed configuration is depicted in the following inset: