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]