One document matched: draft-bryant-mpls-sfl-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-bryant-mpls-sfl-framework-00"
ipr="trust200902" updates="">
<front>
<title abbrev="SFL Framework">Synonymous Flow Label Framework</title>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="George Swallow" initials="G" surname="Swallow">
<organization>Cisco Systems</organization>
<address>
<email>swallow@cisco.com</email>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S " surname="Sivabalan">
<organization>Cisco Systems</organization>
<address>
<email>msiva@cisco.com</email>
</address>
</author>
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author fullname="Mach(Guoyi) Chen" initials="M" surname="Chen">
<organization>Huawei</organization>
<address>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author fullname="Zhenbin(Robin) Li" initials="Z" surname="Li">
<organization>Huawei</organization>
<address>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<date year="2015" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>OAM</keyword>
<keyword></keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>draft-bryant-mpls-flow-ident describes the requirement for
introducing flow identities within the MPLS architecture. This document
describes a method of accomplishing this by using a technique called
Synonymous Flow Labels in which labels which mimic the behaviour of
other labels provide the identification service. These identifiers can
be used to trigger per-flow operations on the on the packet at the
receiving label switching router.</t>
</abstract>
</front>
<middle>
<section anchor="INTRO" title="Introduction">
<t><xref target="I-D.bryant-mpls-flow-ident"></xref> describes the
requirement for introducing flow identities within the MPLS
architecture.</t>
<t>This document describes a method of accomplishing this by using a
technique called Synonymous Flow Labels (SFL) <xref
target="SFLSECT">(see</xref>) in which labels which mimic the behaviour
of other labels provide the identification service. These identifiers
can be used to trigger per-flow operations on the packet at the
receiving label switching router.</t>
</section>
<section anchor="SFLSECT" title="Synonymous Flow Labels">
<t>An SFL is defined to be a label that causes exactly the same
behaviour at the egress Label Switching Router (LSR) as the label it
replaces, but in addition also causes an agreed action to take place on
the packet. There are many possible additional actions such as the
measurement of the number of received packets in a flow, triggering
IPFIX inspection, triggering other types of Deep Packet Inspection, or
identification of the packet source. In, for example, a Performance
Monitoring (PM) application, the agreed action could be the recording of
the receipt of the packet by incrementing a packet counter. This is a
natural action in many MPLS implementations, and where supported this
permits the implementation of high quality packet loss measurement
without any change to the packet forwarding system.</t>
<t>Consider an MPLS application such as a pseudowire (PW), and consider
that it is desired to use the approach specified in this document to
make a packet loss measurement. By some method outside the scope of this
text, two labels, synonymous with the PW labels are obtained from the
egress terminating provider edge (T-PE). By alternating between these
SFLs and using them in place of the PW label, the PW packets may be
batched for counting without any impact on the PW forwarding behaviour
(note that strictly only one SFL is needed in this application, but that
is an optimization that is a matter for the implementor).</t>
<t>Now consider an MPLS application that is multi-point to point such as
a VPN. Here it is necessary to identify a packet batch from a specific
source. This is achieved by making the SFLs source specific, so that
batches from one source are marked differently from batches from another
source. The sources all operate independently and asynchronously from
each other, independently co-ordinating with the destination. Each
ingress is thus able to establish its own SFL to identify the sub-flow
and thus enable PM per flow.</t>
<t>Finally we need to consider the case where there is no MPLS
application label such as occurs when sending IP over an LSP. In this
case introducing an SFL that was synonymous with the LSP label would
introduce network wide forwarding state. This would not be acceptable
for scaling reasons. We therefore have no choice but to introduce an
additional label. Where penultimate hop popping (PHP) is in use, the
semantics of this additional label can be similar to the LSP label.
Where PHP is not in use, the semantics are similar to an MPLS explicit
NULL. In both of these cases the label has the additional semantics of
the SFL.</t>
<t>Note that to achieve the goals set out in <xref
target="INTRO"></xref> SFLs need to be allocated from the platform label
table.</t>
</section>
<section anchor="UST" title="User Service Traffic in the Data Plane">
<t>As noted in <xref target="SFLSECT"></xref> it is necessary to
consider two cases:<list style="numbers">
<t>Applications label present</t>
<t>Single label stack</t>
</list></t>
<section anchor="ALP" title="Applications Label Present">
<t><xref target="SFL-Stack"></xref> shows the case in which both an
LSP label and an application label are present in the MPLS label
stack. Traffic with no SFL function present runs over the "normal"
stack, and SFL enabled flows run over the SFL stack with the SFL used
to indicate the packet batch.</t>
<figure anchor="SFL-Stack"
title="Use of Synonymous Labels In A Two Label MPLS Label Stack">
<artwork><![CDATA[
+-----------------+ +-----------------+
| | | |
| LSP | | LSP | <May be PHPed
| Label | | Label |
+-----------------+ +-----------------+
| | | |
| Application | | Synonymous Flow |
| Label | | Label |
+-----------------+ +-----------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+-----------------+ +-----------------+
"Normal" Label Stack Label Stack with SFL
]]></artwork>
</figure>
<t>At the egress LSR the LSP label is popped (if present). Then the
SFL is processed in exactly the same way as the corresponding
application label would have been processed.</t>
<section anchor="TTLTC" title="Setting TTL and the Traffic Class Bits">
<t>The TTL and the Traffic Class bits <xref target="RFC5462"></xref>
in the SFL LSE would normally be set to the same value as would have
been set in the label that the SFL is synonymous with. However it is
recognised that there may be an applications need to set the SFL to
some other value. An example would be where it was desired to cause
the SFL to trigger an action in the TTL expiry exception path as
part of the label action.</t>
</section>
</section>
<section anchor="SLS" title="Single Label Stack">
<t><xref target="SFL-Stack2"></xref> shows the case in which only an
LSP label is present in the MPLS label stack. Traffic with no SFL
function present runs over the "normal" stack and SFL enabled flows
run over the SFL stack with the SFL used to indicate the packet batch.
However in this case it is necessary for the ingress LSR to first push
the SFL and then to push the LSP label.</t>
<figure anchor="SFL-Stack2"
title="Use of Synonymous Labels In A Single Label MPLS Label Stack">
<artwork><![CDATA[ +-----------------+
| |
| LSP | <= May be PHPed
| Label |
+-----------------+ +-----------------+
| | | | <= Synonymous with
| LSP | | Synonymous Flow | Explicit NULL
| Label | | Label |
+-----------------+ +-----------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+-----------------+ +-----------------+
"Normal" Label Stack Label Stack with SFL
]]></artwork>
</figure>
<t>At the receiving LSR it is necessary to consider two cases:</t>
<t><list style="numbers">
<t>Where the LSP label is still present</t>
<t>Where the LSP label is penultimate hop popped</t>
</list>If the LSP label is present, it processed exactly as it would
normally processed and then it is popped. This reveals the SFL which
in the case of RFC6374 measurements is simply counted and then
discarded. In this respect the processing of the SFL is synonymous
with an Explicit NULL. As the SFL is the bottom of stack, the IP
packet that follows is processed as normal.</t>
<t>If the LSP label is not present due to PHP action in the upstream
LSR, two almost equivalent processing actions can take place. Either
the SFL can be treated as an LSP label that was not PHPed and the
additional associated SFL action is taken when the label is processed.
Alternatively, it can be treated as an explicit NULL with associated
SFL actions. From the perspective of the measurement system described
in this document the behaviour of two approaches are indistinguishable
and thus either may be implemented.</t>
<section title="Setting TTL and the Traffic Class Bits">
<t>The TTL and the Traffic Class considerations described in <xref
target="TTLTC"></xref> apply.</t>
</section>
</section>
<section title="Aggregation of SFL Actions">
<t>There are cases where it is desirable to aggregate an SFL action
against a number of labels. For example where it is desirable to have
one counter record the number of packets received over a group of
application labels, or where the number of labels used by a single
application is large, and consequently the increase in the number of
allocated labels needed to support the SFL actions consequently
becomes too large to be viable. In these circumstances it would be
necessary to introduce an additional label in the stack to act as an
aggregate instruction. This is not strictly a synonymous action in
that the SFL is not replacing a existing label, but is somewhat
similar to the single label case shown in <xref target="SLS"></xref>,
and the same signalling, management and configuration tools would be
applicable.</t>
<t></t>
<figure anchor="SFL-Agg" title="Aggregate SFL Actions">
<artwork><![CDATA[ +-----------------+
| |
| LSP | < May be PHPed
| Label |
+-----------------+ +-----------------+
| | | |
| LSP | | Aggregate |
| Label | | SFL |
+-----------------+ +-----------------+
| | | |
| Application | | Application |
| Label | | Label |
+-----------------+ +-----------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+-----------------+ +-----------------+
"Normal" Label Stack Label Stack with SFL
]]></artwork>
</figure>
<t></t>
<t>The Aggregate SFL is shown in the label stack depicted in <xref
target="SFL-Agg"></xref> as preceding the application label, however
the choice of position before, or after, the application label will be
application specific. In the case described in <xref
target="ALP"></xref>, by definition the SFL has the full application
context. In this case the positioning will depend on whether the SFL
action needs the full context of the application to perform its action
and whether the complexity of the application will be increased by
finding an SFL following the application label.</t>
<t>This third SFL case requires further though by the authors and this
section will be updated in a future version of this draft to reflect
those thoughts.</t>
</section>
</section>
<section title="Equal Cost Multipath Considerations">
<t>The introduction to an SFL to an existing may cause that flow to take
a different path through the network under conditions of Equal Cost
Multipath (ECMP). This is turn may invalidate the certain uses of the
SFL such as performance measurement applications. Where this is a
problem there are two solutions worthy of consideration:</t>
<t><list style="numbers">
<t>The operator can elect to always run with the SFL in place in the
MPLS label stack.</t>
<t>The operator can elect to use <xref target="RFC6790"></xref>
Entropy Labels which, in a network that fully supports this type of
ECMP, results in the ECMP decision being independent of the value of
the other labels in the label stack.</t>
</list></t>
</section>
<section anchor="PC" title="Privacy Considerations">
<t>Recent IETF concerns on pervasive monitoring are described in <xref
target="RFC7258"></xref>. The inclusion of originating and/or flow
information in a packet provides more identity information and hence
potentially degrades the privacy of the communication. Whilst the
inclusion of the additional granularity does allow greater insight into
the flow characteristics it does not specifically identify which node
originated the packet other than by inspection of the network at the
point of ingress, or inspection of the control protocol packets. This
privacy threat may be mitigated by encrypting the control protocol
packets, regularly changing the synonymous labels and by concurrently
using a number of such labels. The minimizing the scope of the identity
indication can be useful in minimizing the observability of the flow
characteristics.</t>
</section>
<section anchor="SEC" title="Security Considerations">
<t>The issue noted in <xref target="PC"></xref> is a security
consideration. There are no other new security issues associated with
the MPLS dataplane. Any control protocol used to request SFLs will need
to ensure the legitimacy of the request.</t>
</section>
<section title="IANA Considerations">
<t>This draft makes no IANA requests.</t>
</section>
<section title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.5462'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7258'?>
<?rfc include='reference.I-D.bryant-mpls-flow-ident'?>
<?rfc include='reference.RFC.6790'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:34:05 |