MPLS Working Group B. Niven-Jenkins Internet-Draft S. Fiddian Intended status: Informational BT Expires: January 4, 2010 July 3, 2009 BT Requirements for MPLS-TP features draft-jenkins-mpls-tp-bt-requirements-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document outlines BT's requirements for MPLS-TP features based on our current thinking for how we may utilise functionality being defined as part of the MPLS-TP standardisation effort within our Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 1] Internet-Draft BT Requirements for MPLS-TP features July 2009 existing deployed MPLS networks. This document is not intended to describe all future requirements for MPLS-TP features, only for those features that we have a currently defined requirement for today and which we would like to see priority be given to them when specifying and standardising MPLS-TP within IETF. These features are required in order to enable us to enhance live, revenue generating services. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deployment reference model . . . . . . . . . . . . . . . . . . 3 4. Required features . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Static LSP provisioning . . . . . . . . . . . . . . . . . 5 4.2. Static PW provisioning . . . . . . . . . . . . . . . . . . 6 4.3. Static OAM provisioning . . . . . . . . . . . . . . . . . 6 4.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Connectivity Checks . . . . . . . . . . . . . . . . . 7 4.4.2. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7 4.4.3. Performance monitoring . . . . . . . . . . . . . . . . 8 4.4.4. Redundancy . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 2] Internet-Draft BT Requirements for MPLS-TP features July 2009 1. Introduction This document outlines BT's requirements for MPLS-TP features based on our current thinking for how we may utilise functionality being defined as part of the MPLS-TP standardisation effort within our existing deployed MPLS networks. This document is not intended to describe all future requirements for MPLS-TP features, only for those features that we have a currently defined requirement for today and which we would like to see priority be given to them when specifying and standardising MPLS-TP within IETF. These features are required in order to enable us to enhance live, revenue generating services. If deployed, any features described in this document would need to be compatible with current MPLS implementations as we would be looking to deploy these features within our existing, deployed MPLS devices. Not all features described in this document are fully specified at this time as we are still working with our customers to scope them such that they provide the necessary functionality we and our customers require without over specifying the solution. The following sections outline a deployment reference model and the MPLS-TP features BT has requirements for to support a subset of our current and future MPLS based services. 2. Terminology Jitter: Jitter is defined as packet delay variation as per [RFC3393]. Latency: Latency is defined as the delay (time of flight) seen by any one packet between two defined measurement points in the network. 3. Deployment reference model 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 [RFC3985] or the MS-PW one shown in Figure 2 of the Requirements for Multi-Segment PWE 3[RFC5254]. However the details of the deployment scenario places a number of constraints on possible solutions which are not covered by [RFC3985] or [RFC5254]. The following deployment options and restrictions apply. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 3] Internet-Draft BT Requirements for MPLS-TP features July 2009 o One or both T-PEs may be placed on a customer's premises. o Customer premises are considered unsecured environments. o 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: o There MUST NOT be an IP path between an unsecure T-PE and its neighbouring S-PE. o 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: o 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. o 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 4] Internet-Draft BT Requirements for MPLS-TP features July 2009 Native No IP path between Service T-PE & {T|S}-PE (AC) / \ | / \ | +-----+ +-----+ +----+ | |T-PE1|===========|S-PE1|=========== | |------|.......PW.Seg't1.........PW.Seg't3. | CE | | | | | | | |------|.......PW.Seg't2.........PW.Seg't4. +----+ | | |===========| |=========== +-----+ +-----+ \ / \ / No control plane (LSP or PW) between T-PE & S-PE for negotiating capabilities or configuring forwarding state Figure 1: BT deployment model Other deployment considerations include: o 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. o LSPs across the core network connecting S-PEs could be LDP signalled. 4. Required features 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. 4.1. Static LSP provisioning 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 5] Internet-Draft BT Requirements for MPLS-TP features July 2009 It MUST be possible to configure and operate LSPs which contain a mixture of statically provisioned and dynamically setup LSP segments. 4.2. Static PW provisioning 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). 4.3. Static OAM provisioning 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: o OAM capabilities o 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 6] Internet-Draft BT Requirements for MPLS-TP features July 2009 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. 4.4. OAM The following OAM functions MUST be supported: o Connectivity Checks o Diagnostics o Performance Monitoring The requirements for each are specified in the sections below. 4.4.1. Connectivity Checks 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. 4.4.2. Diagnostics The following diagnostic tools and tests MUST be provided o 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 Section 4.4.3 for more detailed requirements related to the loopback test. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 7] Internet-Draft BT Requirements for MPLS-TP features July 2009 o A traceroute mechanism to verify, on demand, the path of dynamic and static LSP segments and end to end paths. o A ping mechanism to verify, on demand, the connectivity of LSPs and PWs on per segment and end to end basis. 4.4.3. Performance monitoring 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 8] Internet-Draft BT Requirements for MPLS-TP features July 2009 1 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 Section 4.4.3.1, Section 4.4.3.2 and Section 4.4.3.4 respectively. 2 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 Section 4.4.3.1, Section 4.4.3.2, Section 4.4.3.3 and Section 4.4.3.4 respectively. 3 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] o One way latency. o Two way latency. o Jitter. o Packet loss. 4.4.3.1. Latency 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 9] Internet-Draft BT Requirements for MPLS-TP features July 2009 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. 4.4.3.2. Jitter 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. 4.4.3.3. Throughput 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. Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 10] Internet-Draft BT Requirements for MPLS-TP features July 2009 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] 4.4.3.4. Packet loss 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. 4.4.4. Redundancy 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. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 11] Internet-Draft BT Requirements for MPLS-TP features July 2009 RFC. 6. Security Considerations 7. Acknowledgements The following BT people have contributed towards the development of this document: Simon Carter and Neil Harrison. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008. Authors' Addresses Ben Niven-Jenkins BT 208 Callisto House Adastral Park, Ipswich IP5 3RE UK Email: benjamin.niven-jenkins@bt.com Simon Fiddian BT 2160 East Grand Ave El Segundo, California USA Email: simon.fiddian@bt.com Niven-Jenkins & Fiddian Expires January 4, 2010 [Page 12]