MPLS Flow Identification Considerations
Huawei
stewart.bryant@gmail.com
Cisco Systems
cpignata@cisco.com
Huawei
mach.chen@huawei.com
Huawei
lizhenbin@huawei.com
ZTE Corp.
gregimirsky@gmail.com
MPLS Working Group
This document discusses the aspects that need to be be considered
when developing a
solution for MPLS flow identification. The key application that needs
this is in-band performance monitoring of MPLS flows when MPLS is used to
encapsulate user data packets.
This document discusses the aspects that need to be considered when developing a
solution for MPLS flow identification. The key
application that needs this is in-band performance monitoring
of MPLS flows when MPLS is used for the encapsulation of user data packets.
There is a need to identify flows in MPLS networks for various applications
such as determining packet loss and packet delay measurement. A
method of loss
and delay measurement in MPLS networks was defined in .
When used to measure packet loss depends on the use of
injected Operations, Administration, and Maintenance (OAM) packets to
designate the beginning and the end of the packet group over which
packet loss is being measured. Where the misordering of packets from
one group relative to the following group, or misordering of one of
the packets being counted relative to the packet occurs,
then an error will occur in the packet loss measurement.
In
addition, did not support different granularities of flow
or address
a number of multi-point cases in which two or more ingress Label
Switching Routers (LSRs) could send packets to one or more
destinations.
Improvements in link and transmission technologies have made it more
difficult to assess packet loss using active performance
measurement methods with synthetic traffic, due to the very low loss
rate in normal operation. That, together with more demanding service
level requirements, means that network operators now need to be able to
measure the loss of the actual user data traffic by using passive
performance measurement methods. Any technique deployed needs to be
transparent to the end user, and it needs to be assumed that they
will not take any active part in the measurement process.
Indeed it is important that any flow identification technique be invisible
to them, and that no remnant of the measurement process leaks into their
network.
Additionally where there are multiple traffic sources, such as in
multi-point to point and multi-point to multi-point network
environments there needs to be a method whereby the sink can
distinguish between packets from the various sources, that is to say,
that a multi-point to multi-point measurement model needs to be
developed.
Modern networks, if not oversubscribed, generally drop relatively few
packets, thus packet loss measurement is highly sensitive to the
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 it may not be possible to achieve
the required accuracy in the loss measurement of customer data
traffic. Thus where accurate measurement of packet loss is required,
it may be economically advantageous, or even a technical requirement, to
include some form of marking in the packets to assign each packet to
a particular counter for loss measurement purposes.
Where this level of accuracy is required and the traffic between a
source-destination pair is subject to Equal-Cost Multipath (ECMP) a
demarcation mechanism is needed to group the packets into batches.
Once a batch is correlated at both ingress and egress, the packet
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
egress. Errors in the accounting are particularly acute in Label
Switched Paths (LSPs) subjected to ECMP because the network transit
time will be different for the various ECMP paths since:
The packets may traverse different sets of LSRs.
The packets may depart from different interfaces on different
line cards on LSRs.
The packets may arrive at different interfaces on different line
cards on LSRs.
A consideration with this solution on modifying the identity label
(the MPLS label
ordinarily used to identify the LSP, Virtual Private Network,
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
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
ECMP path. Where the path member is chosen by reference to an
entropy label then changing the batch identifier will not
result in a change to the chosen ECMP path. ECMP is so pervasive in
multi-point to (multi-) point networks that some method of avoiding
accounting errors introduced by ECMP needs to be supported.
Most of the existing delay measurement methods are active methods
that depend on the extra injected test packet to evaluate the delay
of a path. With the active measurement method, the rate, numbers and
interval between the injected packets may affect the accuracy of the
results. Due to ECMP (or link aggregation techniques) injected test packets may
traverse different links from the ones used by the data traffic.
Thus there exists a requirement to measure the delay of the real traffic.
For combined loss-delay measurements, both the loss and the delay
considerations apply.
The most basic unit of identification is the identity of the node
that processed the packet on its entry to the MPLS network. However,
the required unit of identification may vary depending on the use
case for accounting, performance measurement or other types of packet
observations. In particular note that there may be a need to impose
identity at several different layers of the MPLS label stack.
This document considers following units of identifications:
Per source LSR - everything from one source is aggregated.
Per group of LSPs chosen by an ingress LSR - an ingress LSP
aggregates group of LSPs (ex: all LSPs of a tunnel).
Per LSP - the basic form.
Per flow within an LSP - fine grained method.
Note that a fine grained identity resolution is needed when there is
a need to perform these operations on a flow not readily identified
by some other element in the label stack.
Such fine-grained
resolution may be possible by deep packet inspection. However, this may
not always be possible, or it may be desired to minimize processing
costs by doing this only on entry to the network. Adding a
suitable identifier to the packet for reference by other network
elements minumises the processing needed by other network
elements.
An example of such a fine grained case might be traffic
belonging to a certain service or from a
specific source, particularly if matters related to service level
agreement or application performance were being investigated
We can thus characterize the identification requirement in the
following broad terms:
There needs to be some way for an egress LSR to identify the
ingress LSR with an appropriate degree of scope. This concept is
discussed further in .
There needs to be a way to identify a specific LSP at the egress
node. This allows for the case of instrumenting multiple LSPs
operating between the same pair of nodes. In such cases the
identity of the ingress LSR is insufficient.
In order to conserve resources such as labels, counters and/or
compute cycles it may be desirable to identify an LSP group so
that a operation can be performed on the group as an aggregate.
There needs to be a way to identify a flow within an LSP. This is
necessary when investigating a specific flow that has been
aggregated into an LSP.
The unit of identification and the method of determining which
packets constitute a flow will be application or use-case specific
and is out of scope of this document.
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.
The ingress LSR for a point to point LSP, such as those created using
the Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
Signaling protocol, or those that conform to the MPLS
Transport Profile (MPLS-TP) may be identified by inspection
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
pair at every hop at a given layer in the LSP hierarchy. Provided
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
determining the identity of the ingress LSR must be regarded as a
solved problem. Note however that the identity of a flow cannot to
be determined without further information being carried in the
packet, or gleaned from some aspect of the packet payload.
In the case of a point to multi-point LSP, and in the absence of
Penultimate Hop Popping (PHP) the identity of the ingress LSR may
also be inferred from the top label. However, it may not possible to
adequately identify the flow from the top label alone, and thus
further information may need to be carried in the packet, or gleaned
from some aspect of the packet payload. In designing any solution it
is desirable that a common flow identity solution be used for both
point to point and point to multi-point LSP types. Similarly it is
desirable that a common method of LSP group identification be used.
In the above cases, a context label needs to be used to
provide the required identity information. This is widely supported
MPLS feature.
A more interesting case is the case of a multi-point to point LSP.
In this case the same label is normally used by multiple ingress or
upstream LSRs and hence source identification is not possible by
inspection of the top label by the egress LSRs. It is therefore
necessary for a packet to be able to explicitly convey any of the
identity types described in .
Similarly, in the case of a multi-point to multi-point LSP the same
label is normally used by multiple ingress or upstream LSRs and hence
source identification is not possible by inspection of the top label
by egress LSRs. The various types of identity described in
are again needed. Note however, that the scope of the identity may
be constrained to be unique within the set of multi-point to multi-
point LSPs terminating on any common node.
The scope of identification can be constrained to the set of flows
that are uniquely identifiable at an ingress LSR, or some aggregation
thereof. There is no need of an ingress LSR seeking assistance
from outside the MPLS protocol domain.
In any solution that constrains itself to carrying the required
identity in the MPLS label stack rather than in some different
associated data structure, constraints on the choice of
label and label stack size imply
that the scope of identity resides within that MPLS domain. For
similar reasons the identity scope of a component of an LSP is
constrained to the scope of that LSP.
In any network it is unlikely that all LSRs will have the same
capability to support the methods of identification discussed in this
document. It is therefore an important constraint on any flow identity
solution that it is backwards compatible with deployed MPLS equipment
to the extent that deploying the new feature will not disable
anything that currently works on a legacy equipment.
This is particularly the case when the deployment is incremental or
the feature is not required for all LSRs or all LSPs. Thus,
the flow identification design must support the co-existence of
both LSRs that can, and cannot, identify the traffic components
described in . In addition the identification of the
traffic components described in must be an optional feature
that is disabled by default. As a design simplification, a solution
may require that all egress LSRs of a point to multi-point or a multi-
point to multi-point LSP support the identification type in 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
LSRs are enabled to support the required identity type, or none of
them are.
There is a huge installed base of MPLS equipment, typically this type
of equipment remains in service for an extended period of time, and
in many cases hardware constraints mean that it is not possible to
upgrade its dataplane functionality. Changes to the MPLS data plane
are therefore expensive to implement, add complexity to the network,
and may significantly impact the deployability of a solution that
requires such changes. For these reasons, MPLS users have
set a very high bar to changes to the MPLS data plane, and only a
very small number have been adopted. Hence, it is important that the
method of identification must minimize changes to the MPLS data
plane. Ideally method(s) of identification that require no changes
to the MPLS data plane should be given preferential consideration.
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
that makes no change, and the advantage of the approach will need 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
change as possible and (b) be a general purpose method so as to
maximize its use for future applications. It is imperative that, as
far as can be foreseen, any necessary change made to the MPLS data
plane does not impose any foreseeable future limitation on the MPLS
data plane.
Stack size is an issue with many MPLS implementations both as a
result of hardware limitations, and due to the impact on networks and
applications where a large number of small payloads need to be
transported In particular one MPLS payload may be carried inside
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
identification may be required at both layers. Of particular concern
is the implementation of low cost edge LSRs that for cost reasons
have a significant limit on the number of Label Stack Elements (LSEs)
that they can impose or dispose. Therefore, any method of identity
must not consume an excessive number of unique labels, and must not
result in an excessive increase in the size of the label stack.
The MPLS data plane design provides two types of special purpose
labels: the original 16 reserved labels and the much larger set of
special purpose labels defined in . The original reserved
labels need one LSE, and the newer special purpose labels
need two LSEs. Given the tiny number of original reserved labels, it
is core to the MPLS design philosophy that this scarce resource is
only used when it is absolutely necessary. Using a single LSE
reserved or special purpose label to encode flow identity thus
requires two stack entries, one for the reserved label and one for
the flow identity. The larger set of labels requires two
labels stack entries for the special purpose label itself and hence a
total of three label stack entries to encode the flow identity.
The use of special purpose labels (SPL) as part of a method
to encode the identity information therefore has a number of
undesirable implications for the data plane and hence whilst a
solution may use SPL(s), methods that do not require SPLs need to be
carefully considered.
Any flow identity design should both seek to minimise the complexity
of the control plane and should minimise the amount of label co-
ordination needed amongst LSRs.
The inclusion of originating and/or flow information in a packet
provides more identity information and hence potentially degrades the
privacy of the communication. Recent IETF concerns on pervasive
monitoring would lead it to prefer a solution that does not
degrade the privacy of user traffic below that of an MPLS network not
implementing the flow identification feature. The choice of using
MPLS technology for this OAM solution has a privacy advantage as
the choice of the label identifying a flow is limited to the
scope of the MPLS domain and does not have any dependency
on the user data’s identification. This minimizes the
observability of the flow characteristics.
Any solution to the flow identification needs must not degrade the
security of the MPLS network below that of an equivalent network not
deploying the specified identity solution.
In order to
preserve present assumptions about MPLS privacy properties,
propagation of
identification information outside the MPLS network imposing it must
be disabled by default. Any solution should provide for the
restriction of the identity information to those components of the
network that need to know it. It is thus desirable to limit the
knowledge of the identify of an endpoint to only those LSRs that need
to participate in traffic flow. The choice of using MPLS technology
for this OAM solution, with MPLS encapsulation of user traffic,
provides for a key advantage over other data plane solutions,
as it provides for a controlled access and trusted domain
within a Service Provider’s network.
For a more comprehensive discussion of MPLS security and attack
mitigation techniques, please see the Security Framework for
MPLS and GMPLS Networks .
This document has no IANA considerations. (At the discretion of the
RFC Editor this section may be removed before publication).
The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow
and Deborah Brungard for their comments.
Alternate-Marking Method for Passive and Hybrid Performance Monitoring
This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.
MPLS Upstream Label Assignment and Context-Specific Label Space
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]
Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]
Requirements of an MPLS Transport Profile
This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]
Packet Loss and Delay Measurement for MPLS Networks
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]
The Use of Entropy Labels in MPLS Forwarding
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]
Pervasive Monitoring Is an Attack
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.
Allocating and Retiring Special-Purpose MPLS Labels
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.
Security Framework for MPLS and GMPLS Networks
This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.