BT Requirements for MPLS-TP features

The environment in which these features are likely to be deployed is a SS-PW or MS-PW network similar to the SS-PW one shown in Figure 2 of the PW architecture or the MS-PW one shown in Figure 2 of the Requirements for Multi-Segment PWE 3. However the details of the deployment scenario places a number of constraints on possible solutions which are not covered by or . The following deployment options and restrictions apply. One or both T-PEs may be placed on a customer’s premises. Customer premises are considered unsecured environments. The network between T-PEs and/or S-PEs is a NGN packet core supporting multiple services including regional and national governmental traffic of one or more countries and may be considered by any particular national or regional government which it is supporting to be “critical national and/or regional infrastructure”. Therefore the following constraints apply to any solution: There MUST NOT be an IP path between an unsecure T-PE and its neighbouring S-PE. The PW segment between an unsecured T-PE and the S-PE MUST NOT run any control plane protocols. The reasons for the above constraints are many fold, however two examples are provided below: If an IP path exists between T-PE and S-PE devices then S-PE devices could be protocol and port scanned, making any future vulnerabilities in the S-PE potentially exploitable. Use of a control plane between T-PE and S-PE devices opens the core control plane (i.e. the control plane between S-PEs) to attack from insecure, uncontrolled locations. MD5 (or similar) authentication may not be acceptable to fully secure the control plane as there is still a risk that the MD5 key could be extracted from the T-PE, and the channel be used to flood labels, or attempt to crash the S-PE node using port fuzzing techniques. In addition to the lack of an IP path between an unsecured T-PE and its neighbouring S-PE it is expected that equipment will support additional mechanisms to ensure that traffic from an unsecured T-PE is only forwarded if the data packet and protocol stack contain values that the S-PE expects to receive from that T-PE, e.g. S-PEs MUST drop any packets sent from unsecured T-PEs if the packets are labelled with labels that have not been configured for/signalled to that T-PE. The following figure shows the envisaged deployment model. Although the figure shows a MS-PW case the requirements outlined in this document MUST also be applicable to a SS-PW deployment model.

Other deployment considerations include: All equipment MUST use IP addressing for OAM, signalling and management traffic and MUST be capable of being managed via a (at least logically) separate IP based DCN network. LSPs across the core network connecting S-PEs could be LDP signalled.

LSP and PW devices SHOULD NOT accept and forward any abelled packet with a label stack that has not been configured on or advertised out of the receiving interface.

It MUST be possible to statically configure and operate LSPs (including forwarding MPLS traffic) between PEs without the existence of an IP path or IP next hop on either PE device. It MUST also be possible to dynamically setup LSPs via a control plane. Where a control plane is used to setup an LSP the session establishment MUST support the use of MD5. Bi-directional LSPs (either associated bi-directional or co-routed bi-directional) SHOULD be supported if they simplify the operation of the network. It MUST be possible to configure and operate LSPs which contain a mixture of statically provisioned and dynamically setup LSP segments.

MS-PW implementations exist today which support limited ability to statically provision MS-PW segments, however they require an IP next hop to be defined between T-PEs and S-PEs. In some deployment scenarios the existence of an IP path between T-PEs and S-PEs is unacceptable. It MUST be possible to statically configure and operate (including forwarding PW traffic) between PEs without the existence of an IP path or IP next hop on either PE device. It MUST also be possible to dynamically setup LSPs via a control plane. Where a control plane is used to setup a PW the session establishment MUST support the use of MD5. Where a control plane is used to setup a PW segment it SHOULD support both FEC128 and FEC129. It MUST be possible to migrate a PW segment from being statically configured/operated to being dynamically (i.e. control plane driven) configured/operated (and vice versa) with no impact to traffic in the PW data plane (i.e. such migration MUST NOT result in packet loss or other service or performance affecting impacts).

MS-PW implementations exist today which support a limited ability to statically provision OAM using VCCV, however they require T-LDP to be running in order to negotiate VCCV capabilities. In some deployment scenarios the existence of a control plane (T-LDP) and/or an IP path between T-PEs and S-PEs is unacceptable. It MUST be possible to statically configure and operate OAM (including CC) between T-PEs and S-PEs without the existence of an IP path or control plane between the T-PE and S-PE devices, including static configuration and operation of: OAM capabilities OAM sessions It MUST be possible to statically configure and operate OAM for LSPs including OAM capabilities and sessions. It MUST be possible to statically configure and operate OAM for PWs including OAM capabilities and sessions. It MUST be possible to statically configure and operate OAM (including CC) for both per-segment (SS-PW and MS-PW cases) and end to end (MS-PW case) modes of operation. It MUST be possible to statically configure and operate OAM regardless of whether the LSP or PW (including individual PW segments) was statically or dynamically configured.

The following OAM functions MUST be supported: Connectivity Checks Diagnostics Performance Monitoring The requirements for each are specified in the sections below.

It MUST be possible to perform heartbeat connectivity checks in order to validate the data plane integrity of an LSP. It MUST be possible to perform heartbeat connectivity checks in order to validate the data plane integrity of a PW both on a per segment (SS-PW and MS-PW cases) and end to end (MS-PW case) basis. It MUST be possible to detect LSP failures in sub second time frames. It MUST be possible to detect PW failures on a per segment basis in sub second time frames. A mechanism MUST be provided to enable end to end PW OAM to scale such that a single T-PE can support OAM for low thousands of PWs and maintain sub second fault detection.

The following diagnostic tools and tests MUST be provided A loopback test which performs an end to end loopback test with the option for it to be intrusive to the PW data plane and non-intrusive to the PW data plane. See for more detailed requirements related to the loopback test. A traceroute mechanism to verify, on demand, the path of dynamic and static LSP segments and end to end paths. A ping mechanism to verify, on demand, the connectivity of LSPs and PWs on per segment and end to end basis.

MPLS OAM does not support any performance management today and in order to monitor the performance of customer services other techniques have to be used such as IP SLA probes. In an environment with a requirement to provide a strictly defined SLA to customers and/or where customer traffic is not IP based, performance monitoring is required before bringing a PW supporting customer traffic into service as well as continuous performance monitoring for such tasks as SLA verification and reporting. However, in order for performance measurements to be meaningful they should only be recorded when an LSP or PW is in the available state. Therefore, definitions of the entry/exit of the unavailable state of a packet based transport path are REQUIRED and should be meaningful to a packet based client layer (i.e. should not be purely based on a definition for SES). It MUST be possible to statically configure and operate performance monitoring regardless of whether the LSP or PW (including individual PW segments) was statically or dynamically configured. The following performance monitoring tools MUST be provided. Note we are currently working with our customers to define the measurement granularity that must be provided in order to strike the correct balance between providing the necessary tools and functionality we and our customers require while not over specifying the solution. The details provided below are our current best view as to what is required. Where both ends are synchronised with respect to time then one way latency and jitter is REQUIRED with the accuracy detailed in the sections below. Further details of the types of statistics (latency, jitter, packet loss and throughput) and the granularities required are provided in the sub-sections below. Note: As well as their stated purposes of SLA verification and pre-commission testing the performance monitoring tools below MUST also be suitable for use as on-demand diagnostic tools. End to End loopback performance monitoring of a SS-PW or MS-PW from T-PE to T-PE while that PW is carrying live customer traffic. This End to End loopback performance monitoring MUST NOT be intrusive (i.e. it MUST NOT affect the customer traffic or the performance received by the customer in any way). Measurement and recording of latency, jitter, and packet loss MUST be supported as detailed in , and respectively. End to End loopback performance monitoring of a SS-PW or MS-PW from T-PE to T-PE before bringing that PW into live service and placing customer traffic on the MS-PW. This End to End loopback performance monitoring SHOULD be intrusive in order to simulate the likely performance of the PW when it is carrying live customer traffic. Measurement and recording of latency, jitter, throughput and packet loss MUST be supported as detailed in , , and respectively. MIB support for performance monitoring alarming and reporting. This performance monitoring MIB MUST support the collection of the following performance monitoring statistics on a per PW basis. [Editor’s note: Require MIB stat resolution to be at same level as what the probe is associated with e.g. per PW if probes are run per PW. Need to word above better] One way latency. Two way latency. Jitter. Packet loss.

The measurement and recording of two way latency (round trip delay) MUST be supported. For two way latency it MUST be possible for the operator to select which end of the PW initiates and records the result of the performance management function. The measurement and recording of one way latency SHOULD be supported. It MUST be possible to measure and record latency to a granularity down to 100us to an accuracy of +/-100us. It MUST be possible for an operator to configure the rate at which latency is measured on a per LSP basis. It MUST be possible for an operator to configure the rate at which latency is measured on a per PW basis. It MUST be possible for latency probes to be QoS marked to measure and record the delay experienced by different classes of traffic in the network including local treatment by the device generating the probe. It MUST be possible to run different latency probes in multiple QoS classes simultaneously.

Where one way latency is supported then the measurement and recording of one way jitter MUST also be supported. It MUST be possible to measure jitter in both directions of a PW or bi-directional LSP. It MUST be possible to measure and record jitter to a granularity down to 100us to an accuracy of +/-100us. It MUST be possible for an operator to configure the rate at which jitter is measured on a per PW and per LSP basis. It MUST be possible for jitter probes to be QoS marked to measure and record the jitter experienced by different classes of traffic in the network including local treatment by the device generating the probe. It MUST be possible to run different jitter probes in multiple QoS classes simultaneously.

It MUST be possible to measure and record the throughput that is achievable within a PW up to the maximum throughput defined for that PW. It MUST be possible to test two way throughput (loopback) end to end through a PW. It SHOULD be possible to test one way throughput through a PW. It MUST be possible to enable the ability to execute a throughput test on a per PW basis. It MUST be possible for an operator to configure a maximum bandwidth that a throughput test can run up to on a per PW basis. [Editor’s note: Need to insert some text requiring a mechanism to limit the chance of fat fingers running inappropriate tests, e.g. on a per PW basis the ability to run a throughput test (and the maximum rate) needs to be pre-authorised via some mechanism e.g. within the PW interface configuration]

It MUST be possible to measure one way packet loss end to end within a PW. Typically in today's networks packet loss is measured using separate probes to the actual user/customer traffic (e.g. by reusing delay/jitter probes). However such an approach is not appropriate for all use cases as the resolution provided by such a probe approach is not sufficient to monitor and measure some SLAs (e.g. where extremely low packet loss is being guaranteed within an SLA). In such cases it is necessary to have a mechanism that records packet loss based on the actual user/customer traffic flow. It MUST be possible to measure one way packet loss to an accuracy of a single lost user/customer packet. It is anticipated that packet loss "buckets" not longer than 5 minutes are sufficient for a very high proportion of use cases.

It MUST be possible to pre-build and designate a back up path at the LSP and/or PW layer. If done at the LSP layer then any clients of the LSP (including PWs) will be implicitly rerouted. If done at the PW layer it will require the explicit provisioning of a backup LSP. Solutions MUST support the use of end to end status bits indicating which PW is currently the "active" PW.