draft-ietf-mpls-flow-ident-03.txt   draft-ietf-mpls-flow-ident-04.txt 
MPLS Working Group S. Bryant MPLS Working Group S. Bryant
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational C. Pignataro Intended status: Informational C. Pignataro
Expires: July 27, 2017 Cisco Systems Expires: August 28, 2017 Cisco Systems
M. Chen M. Chen
Z. Li Z. Li
Huawei Huawei
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
January 23, 2017 February 24, 2017
MPLS Flow Identification Considerations MPLS Flow Identification Considerations
draft-ietf-mpls-flow-ident-03 draft-ietf-mpls-flow-ident-04
Abstract Abstract
This memo discusses the desired capabilities for MPLS flow This memo discusses the aspects that must be considered when
identification. The key application that needs this is in-band developing a solution for MPLS flow identification. The key
performance monitoring of user data packets. application that needs this is in-band performance monitoring of user
data packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2017. This Internet-Draft will expire on August 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3 3. Loss Measurement Considerations . . . . . . . . . . . . . . . 3
4. Delay Measurement Considerations . . . . . . . . . . . . . . 4 4. Delay Measurement Considerations . . . . . . . . . . . . . . 4
5. Units of identification . . . . . . . . . . . . . . . . . . . 4 5. Units of identification . . . . . . . . . . . . . . . . . . . 4
6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Dataplane . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1. Normative References . . . . . . . . . . . . . . . . . . 9 15.1. Normative References . . . . . . . . . . . . . . . . . . 9
15.2. Informative References . . . . . . . . . . . . . . . . . 9 15.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This memo discusses the desired capabilities for MPLS flow This memo discusses the aspects that must be considered when
identification. The key application that needs this is in-band developing a solution for MPLS flow identification. The key
performance monitoring of user data packets. application that needs this is in-band performance monitoring of user
data packets.
There is a need to identify flows in MPLS networks for applications There is a need to identify flows in MPLS networks for applications
such as packet loss and packet delay measurement. A method of loss such as packet loss and packet delay measurement. A method of loss
and delay measurement in MPLS networks was defined in [RFC6374]. and delay measurement in MPLS networks was defined in [RFC6374].
When used to measure packet loss [RFC6374] depends on the use of the When used to measure packet loss [RFC6374] depends on the use of the
injected Operations, Administration, and Maintenance (OAM) packets to injected Operations, Administration, and Maintenance (OAM) packets to
designate the beginning and the end of the packet group over which designate the beginning and the end of the packet group over which
packet loss is being measured. Where the misordering of packets from packet loss is being measured. Where the misordering of packets from
one group relative to the following group, or misordering of one of one group relative to the following group, or misordering of one of
the packets being counted relative to the [RFC6374] packet occurs, the packets being counted relative to the [RFC6374] packet occurs,
then an error will occur in the packet loss measurement. In then an error will occur in the packet loss measurement.
addition, this packet performance measurement system needs to be
In addition, this packet performance measurement system needs to be
extended to deal with different granularities of flow and to address extended to deal with different granularities of flow and to address
a number of the multi-point cases in which two or more ingress Label a number of the multi-point cases in which two or more ingress Label
Switching Routers (LSRs) could send packets to one or more Switching Routers (LSRs) could send packets to one or more
destinations. destinations.
Improvements in link and transmission technologies mean that it may Improvements in link and transmission technologies mean that it may
be difficult to assess packet loss using active performance be difficult to assess packet loss using active performance
measurement methods with synthetic traffic, due to the very low loss measurement methods with synthetic traffic, due to the very low loss
rate in normal operation. That, together with more demanding service rate in normal operation. That, together with more demanding service
level requirements, mean that network operators need to be able to level requirements, mean that network operators need to be able to
skipping to change at page 3, line 33 skipping to change at page 3, line 35
developed. developed.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
3. Loss Measurement Considerations 3. Loss Measurement Considerations
Modern networks, if not oversubscribed, normally drop very few Modern networks, if not oversubscribed, potentially drop relatively
packets, thus packet loss measurement is highly sensitive to counter few packets, thus packet loss measurement is highly sensitive to the
errors. Without some form of coloring or batch marking such as that common demarcation of the exact set of packets to be measured for
loss. Without some form of coloring or batch marking such as that
proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve
the required accuracy in the loss measurement of customer data the required accuracy in the loss measurement of customer data
traffic. Thus where accuracy better than the data link loss traffic. Thus where accurate measurement of packet loss is required,
performance of a modern optical network is required, it may be it may be economically advantageous, or even a technical requirement,
economically advantageous, or even a technical requirement, to to include some form of marking in the packets to assign each packet
include some form of marking in the packets to assign each packet to to a particular counter for loss measurement purposes.
a particular counter.
Where this level of accuracy is required and the traffic between a Where this level of accuracy is required and the traffic between a
source-destination pair is subject to Equal-Cost Multipath (ECMP) a source-destination pair is subject to Equal-Cost Multipath (ECMP) a
demarcation mechanism is needed to group the packets into batches. demarcation mechanism is needed to group the packets into batches.
Once a batch is correlated at both ingress and egress, the packet Once a batch is correlated at both ingress and egress, the packet
accounting mechanism is then able to operate on the batch of packets accounting mechanism is then able to operate on the batch of packets
which can be accounted for at both the packet ingress and the packet which can be accounted for at both the packet ingress and the packet
egress. Errors in the accounting are particularly acute in Label egress. Errors in the accounting are particularly acute in Label
Switched Paths (LSPs) subjected to ECMP because the network transit Switched Paths (LSPs) subjected to ECMP because the network transit
time will be different for the various ECMP paths since: time will be different for the various ECMP paths since:
1. The packets may traverse different sets of LSRs. 1. The packets may traverse different sets of LSRs.
2. The packets may depart from different interfaces on different 2. The packets may depart from different interfaces on different
line cards on LSRs line cards on LSRs.
3. The packets may arrive at different interfaces on different line 3. The packets may arrive at different interfaces on different line
cards on LSRs. cards on LSRs.
A consideration in modifying the identity label (the MPLS label A consideration in modifying the identity label (the MPLS label
ordinarily used to identify the LSP, Virtual Private Network, ordinarily used to identify the LSP, Virtual Private Network,
Pseudowire etc) to indicate the batch is the impact that this has on Pseudowire etc) to indicate the batch is the impact that this has on
the path chosen by the ECMP mechanism. When the member of the ECMP the path chosen by the ECMP mechanism. When the member of the ECMP
path set is chosen by deep packet inspection a change of batch path set is chosen by deep packet inspection a change of batch
represented by a change of identity label will have no impact on the represented by a change of identity label will have no impact on the
skipping to change at page 4, line 32 skipping to change at page 4, line 35
multi-point to (multi-) point networks that some method of avoiding multi-point to (multi-) point networks that some method of avoiding
accounting errors introduced by ECMP needs to be supported. accounting errors introduced by ECMP needs to be supported.
4. Delay Measurement Considerations 4. Delay Measurement Considerations
Most of the existing delay measurement methods are active measurement Most of the existing delay measurement methods are active measurement
that depend on the extra injected test packet to evaluate the delay that depend on the extra injected test packet to evaluate the delay
of a path. With the active measurement method, the rate, numbers and of a path. With the active measurement method, the rate, numbers and
interval between the injected packets may affect the accuracy of the interval between the injected packets may affect the accuracy of the
results. Also, for injected test packets, these may not be co-routed results. Also, for injected test packets, these may not be co-routed
with the data traffic due to ECMP. Thus there exists a requirement with the data traffic due to ECMP, or various link aggregation
to measure the delay of the real traffic. technologies all of which distribute flows across a number of paths
at the network, or data-link and hence at the physical layer.
Thus there exists a requirement to measure the delay of the real
traffic.
For combined loss-delay measurements, both the loss and the delay For combined loss-delay measurements, both the loss and the delay
considerations apply. considerations apply.
5. Units of identification 5. Units of identification
The most basic unit of identification is the identity of the node The most basic unit of identification is the identity of the node
that processed the packet on its entry to the MPLS network. However, that processed the packet on its entry to the MPLS network. However,
the required unit of identification may vary depending on the use the required unit of identification may vary depending on the use
case for accounting, performance measurement or other types of packet case for accounting, performance measurement or other types of packet
skipping to change at page 5, line 7 skipping to change at page 5, line 14
This document considers following units of identifications: This document considers following units of identifications:
o Per source LSR - everything from one source is aggregated. o Per source LSR - everything from one source is aggregated.
o Per group of LSPs chosen by an ingress LSR - an ingress LSP o Per group of LSPs chosen by an ingress LSR - an ingress LSP
aggregates group of LSPs (ex: all LSPs of a tunnel). aggregates group of LSPs (ex: all LSPs of a tunnel).
o Per LSP - the basic form. o Per LSP - the basic form.
o Per flow [RFC6790] within an LSP - fine graining method. o Per flow [RFC6790] within an LSP - fine grained method.
Note that a fine grained identity resolution is needed when there is Note that a fine grained identity resolution is needed when there is
a need to perform these operations on a flow not readily identified a need to perform these operations on a flow not readily identified
by some other element in the label stack. Such fine grained by some other element in the label stack. Such fine grained
resolution may be possible by deep packet inspection, but this may resolution may be possible by deep packet inspection, but this may
not always be possible, or it may be desired to minimise processing not always be possible, or it may be desired to minimize processing
costs by doing this only in entry to the network, and adding a costs by doing this only in entry to the network, and adding a
suitable identifier to the packet for reference by other network suitable identifier to the packet for reference by other network
elements. An example of such a fine grained case might be traffic elements. An example of such a fine grained case might be traffic
from a specific application, or from a specific application from a from a specific application, or from a specific application from a
specific source, particularly if matters related to service level specific source, particularly if matters related to service level
agreement or application performance were being investigated. agreement or application performance were being investigated.
We can thus characterize the identification requirement in the We can thus characterize the identification requirement in the
following broad terms: following broad terms:
skipping to change at page 5, line 51 skipping to change at page 6, line 11
The unit of identification and the method of determining which The unit of identification and the method of determining which
packets constitute a flow will be application or use-case specific packets constitute a flow will be application or use-case specific
and is out of scope of this memo. and is out of scope of this memo.
6. Types of LSP 6. Types of LSP
We need to consider a number of types of LSP. The two simplest types We need to consider a number of types of LSP. The two simplest types
to monitor are point to point LSPs and point to multi-point LSPs. to monitor are point to point LSPs and point to multi-point LSPs.
The ingress LSR for a point to point LSP, such as those created using The ingress LSR for a point to point LSP, such as those created using
the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) the Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
[RFC5420] signalling protocol, or those that conform to the MPLS [RFC5420] Signaling protocol, or those that conform to the MPLS
Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection Transport Profile (MPLS-TP) [RFC5654] may be identified by inspection
of the top label in the stack, since at any provider-edge (PE) or of the top label in the stack, since at any provider-edge (PE) or
provider (P) router on the path this is unique to the ingress-egress provider (P) router on the path this is unique to the ingress-egress
pair at every hop at a given layer in the LSP hierarchy. Provided pair at every hop at a given layer in the LSP hierarchy. Provided
that penultimate hop popping is disabled, the identity of the ingress that penultimate hop popping is disabled, the identity of the ingress
LSR of a point to point LSP is available at the egress LSR and thus LSR of a point to point LSP is available at the egress LSR and thus
determining the identity of the ingress LSR must be regarded as a determining the identity of the ingress LSR must be regarded as a
solved problem. Note however that the identity of a flow cannot to solved problem. Note however that the identity of a flow cannot to
be determined without further information being carried in the be determined without further information being carried in the
packet, or gleaned from some aspect of the packet payload. packet, or gleaned from some aspect of the packet payload.
skipping to change at page 7, line 24 skipping to change at page 7, line 35
to the extent that deploying the new feature will not disable to the extent that deploying the new feature will not disable
anything that currently works on a legacy equipment. anything that currently works on a legacy equipment.
This is particularly the case when the deployment is incremental or This is particularly the case when the deployment is incremental or
when the feature is not required for all LSRs or all LSPs. Thus in when the feature is not required for all LSRs or all LSPs. Thus in
broad the flow identification design MUST support the co-existence of broad the flow identification design MUST support the co-existence of
both LSRs that can, and cannot, identify the traffic components both LSRs that can, and cannot, identify the traffic components
described in Section 5. In addition the identification of the described in Section 5. In addition the identification of the
traffic components described in Section 5 MUST be an optional feature traffic components described in Section 5 MUST be an optional feature
that is disabled by default. As a design simplification, a solution that is disabled by default. As a design simplification, a solution
MAY require that all egress LSRs of a point to multipoint or a multi- MAY require that all egress LSRs of a point to multi-point or a
point to multipoint LSP support the identification type in use so multi- point to multi-point LSP support the identification type in
that a single packet can be correctly processed by all egress use so that a single packet can be correctly processed by all egress
devices. The corollary of this last point is that either all egress devices. The corollary of this last point is that either all egress
LSRs are enabled to support the required identity type, or none of LSRs are enabled to support the required identity type, or none of
them are. them are.
9. Dataplane 9. Dataplane
There is a huge installed base of MPLS equipment, typically this type There is a huge installed base of MPLS equipment, typically this type
of equipment remains in service for an extended period of time, and of equipment remains in service for an extended period of time, and
in many cases hardware constraints mean that it is not possible to in many cases hardware constraints mean that it is not possible to
upgrade its dataplane functionality. Changes to the MPLS data plane upgrade its dataplane functionality. Changes to the MPLS data plane
skipping to change at page 7, line 51 skipping to change at page 8, line 13
very small number have been adopted. Hence, it is important that the very small number have been adopted. Hence, it is important that the
method of identification must minimize changes to the MPLS data method of identification must minimize changes to the MPLS data
plane. Ideally method(s) of identification that require no changes plane. Ideally method(s) of identification that require no changes
to the MPLS data plane should be given preferential consideration. to the MPLS data plane should be given preferential consideration.
If a method of identification makes a change to the data plane is If a method of identification makes a change to the data plane is
chosen it will need to have a significant advantage over any method chosen it will need to have a significant advantage over any method
that makes no change, and the advantage of the approach will need to that makes no change, and the advantage of the approach will need to
be carefully evaluated and documented. If a change is necessary to be carefully evaluated and documented. If a change is necessary to
the MPLS data plane proves necessary, it should be (a) be as small a the MPLS data plane proves necessary, it should be (a) be as small a
change as possible and (b) be a general purpose method so as to change as possible and (b) be a general purpose method so as to
maximise its use for future applications. It is imperative that, as maximize its use for future applications. It is imperative that, as
far as can be foreseen, any necessary change made to the MPLS data far as can be foreseen, any necessary change made to the MPLS data
plane does not impose any foreseeable future limitation on the MPLS plane does not impose any foreseeable future limitation on the MPLS
data plane. data plane.
Stack size is an issue with many MPLS implementations both as a Stack size is an issue with many MPLS implementations both as a
result of hardware limitations, and due to the impact on networks and result of hardware limitations, and due to the impact on networks and
applications where a large number of small payloads need to be applications where a large number of small payloads need to be
transported In particular one MPLS payload may be carried inside transported In particular one MPLS payload may be carried inside
another. For example one LSP may be carried over another LSP, or a another. For example, one LSP may be carried over another LSP, or a
PW or similar multiplexing construct may be carried over an LSP and PW or similar multiplexing construct may be carried over an LSP and
identification may be required at both layers. Of particular concern identification may be required at both layers. Of particular concern
is the implementation of low cost edge LSRs that for cost reasons is the implementation of low cost edge LSRs that for cost reasons
have a significant limit on the number of Label Stack Elements (LSEs) have a significant limit on the number of Label Stack Elements (LSEs)
that they can impose or dispose. Therefore, any method of identity that they can impose or dispose. Therefore, any method of identity
MUST NOT consume an excessive number of unique labels, and MUST NOT MUST NOT consume an excessive number of unique labels, and MUST NOT
result in an excessive increase in the size of the label stack. result in an excessive increase in the size of the label stack.
The MPLS data plane design provides two types of special purpose The MPLS data plane design provides two types of special purpose
labels: the original 16 reserved labels and the much larger set of labels: the original 16 reserved labels and the much larger set of
 End of changes. 20 change blocks. 
36 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/