<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.13 (Ruby 3.0.2) -->
<?rfc comments="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mpls-mna-requirements-16" number="9613" updates="" obsoletes="" category="info" submissionType="IETF" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="MNA Requirements">Requirements for Solutions that Support MPLS Network Actions (MNA)</title> (MNAs)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-requirements-16"/> name="RFC" value="9613"/>
    <author initials="M." surname="Bocci" fullname="Matthew Bocci" role="editor">
      <organization>Nokia</organization>
      <address>
        <email>matthew.bocci@nokia.com</email>
      </address>
    </author>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization>University of Surrey ISC</organization> ICS</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="J." surname="Drake" fullname="John Drake">
      <organization>Independent</organization>
      <address>
        <email>je_drake@yahoo.com</email>
      </address>
    </author>
    <date year="2024" month="May" day="30"/>
    <workgroup>MPLS Working Group</workgroup> month="August"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>

<keyword>Network Action</keyword>
<keyword>NA</keyword>
<keyword>Network Action indicator</keyword>
<keyword>NAI</keyword>
<keyword>Ancillary Data</keyword>
<keyword>AD</keyword>

    <abstract>
      <?line 53?>
<t>This document specifies requirements for the development of MPLS Network Actions (MNA) which (MNAs) that affect the forwarding
or other processing of MPLS packets. These requirements are informed by a number of
proposals for additions to the MPLS information in the labeled packet
 to allow such actions to be performed, either by a transit or terminating Label Switching Router
 (i.e., the Label Edge Router - LER).</t>
    </abstract>
  </front>
  <middle>
    <?line 63?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>There is significant interest in developing the MPLS data plane to
address the requirements of new use cases <xref target="I-D.ietf-mpls-mna-usecases"/>. This requires a
general mechanism, termed MPLS Network Actions (MNA), (MNAs), to allow the network to make a forwarding or
processing decision based on information other than the top label and Traffic Class (TC) bits, and to
also make use of the Network Action Indicator (NAI) and ancillary data (MNA information).
These use cases require the definition of extensions to the MPLS architecture and label
stack label-stack operations that can be used across these use cases in order to minimize implementation
complexity and promote interoperability and extensibility. These protocol extensions need
to conform to the existing MPLS architecture as specified by <xref target="RFC3031"/>, <xref target="RFC3032"/>, and <xref target="RFC6790"/>.</t>
      <t>Note that the MPLS architecture specified in <xref target="RFC3031"/> describes a mechanism for forwarding
MPLS packets through a network without requiring any analysis of the MPLS packet payload's
network layer header by intermediate nodes (Label Switching Routers - LSRs).  Formally,
inspection may only occur at network ingress (the Label Edge Router - LER) where the MPLS
packet is assigned to a Forwarding Equivalence Class (FEC).</t>

      <t>This document specifies the requirements for solutions that encode MPLS Network Actions MNAs
and ancillary data that may be needed by the processing of to process those actions.
   These requirements are informed by a
   number of proposals for to allow additions to the MPLS information in the
   labeled packet
to allow so that such actions to can be performed, either by a
   transit or terminating LSR. It is
anticipated that these will result in two types of solution specification:</t>
      <ol spacing="normal" type="1"><li>
          <t>A specifications:</t>

      <dl spacing="normal">
          <dt>MNA solution specification:</dt><dd>A specification that describes a common protocol that supports all forms of MPLS Network Actions.
This is referred to as the MNA Solution.</t>
        </li>
        <li>
          <t>One MNAs.</dd>
          <dt>Network Action solution specifications:</dt><dd> One or more specifications describing the protocol extensions, and utilising (1), extensions for network action(s) the MNA solution to realise address a use case. These are referred to as Network Action solutions.</t>
        </li>
      </ol> case.</dd>
      </dl>
      <t>The term 'solutions', in isolation, refers to both MNA and Network Action solutions.
The requirements constrain the MNA solution design to enable interoperability between implementations.</t>
      <section anchor="terminology">
        <name>Terminology</name>
        <ul

        <dl spacing="normal">
          <li>
            <t>Network Action:
            <dt>Network Action (NA):</dt><dd> An operation to be performed on an MPLS packet or as a consequence of an MPLS packet
being processed by a router.  A network action  An NA may
affect router state, state or MPLS packet forwarding, or it may affect the MPLS packet in some other way.</t>
          </li>
          <li>
            <t>Network way.</dd>
            <dt>Network Action Indicator (NAI): An (NAI):</dt><dd>An indication in the MPLS packet that a certain network action NA
is to be performed.</t>
          </li>
          <li>
            <t>Ancillary performed.</dd>

            <dt>Ancillary Data (AD): (AD):</dt><dd><t>
Data in an MPLS packet associated with a
      given network action NA that may be used as input to process
      the processing of the network action NA or results may result from the processing
of the network action.
      NA. Ancillary data may be associated with:
            </t> with:</t>

            <ul spacing="normal">
              <li>
                <t>Both the control or maintenance information and the data traffic carried by the Label Switched Path (LSP).</t>
              </li>
              <li>
                <t>Only the control or maintenance information.</t>
              </li>
              <li>
                <t>Only the data traffic carried by the LSP.</t>
              </li>
            </ul>
          </li>
          <li>
            <t>In-Stack Data: Ancillary
	  </dd>
            <dt>In-Stack Data:</dt><dd>Ancillary data carried within the MPLS label stack.</t>
          </li>
          <li>
            <t>Post-Stack Data: Ancillary stack.</dd>
            <dt>Post-Stack Data:</dt><dd>Ancillary data carried in an MPLS packet between the bottom of the MPLS label
stack and the first octet of the user payload.  This document does not prescribe whether
post-stack data precedes or follows any other post-stack header such as a Control Word or
Associated Channel Header (ACH).</t>
          </li>
          <li>
            <t>Scope: (ACH).</dd>
            <dt>Scope:</dt><dd> The set of nodes that should perform a given action.</t>
          </li>
        </ul> action.</dd>
	</dl>
      </section>
    </section>
    <section anchor="requirements-language">
      <name>Requirements Language</name>
      <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>

      <t>Although this document is not a protocol specification, this convention is adopted
for clarity of description of requirements.</t>
    </section>
    <section anchor="mpls-network-action-requirements">
      <name>MPLS Network Action Requirements</name>

      <t>This document specifies requirements on MPLS network actions MNAs and the technology to support
them in MPLS, such as the Network Action Indicators (NAIs), NAIs, the associated ancillary data (AD), AD, and the alert mechanism
to indicate to an LSR that NAIs are present in an MPLS packet.</t>
      <t>The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks
out of which indicators for network actions a NA and associated ancillary data are constructed.<br/> constructed.
It does not specify the detailed actions and processing of any network actions NAs or ancillary
data by an LSR or LER.</t>

      <t>The size of the ancillary data carried post-stack end-to-end end to end in an MPLS packet is a matter for
agreement between the ingress and egress PEs, provider edges (PEs), and is not part of these requirements.
Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed
by transit LSRs along the LSP, Label Switched Path (LSP), requirements on the size of such ancillary data are documented in the following sections.</t>
      <section anchor="general-requirements">
        <name>General Requirements</name>
        <ol spacing="normal" type="1" start="1"><li>
            <t>Any MNA and Network Action solution MUST solutions <bcp14>MUST</bcp14> maintain the properties of extensibility,
        flexibility, and efficiency inherent in the split between the
        control plane context and simple data plane used in MPLS, MPLS and SHOULD the specification
        <bcp14>SHOULD</bcp14> describe how this is achieved.</t>
          </li>
          <li>
            <t>Any solutions to these requirements MUST <bcp14>MUST</bcp14> be based on and MUST NOT <bcp14>MUST NOT</bcp14> restrict the
generality of the MPLS architecture <xref target="RFC3031"/>, target="RFC3031"/> <xref target="RFC3032"/> and <xref target="RFC5331"/>.</t>
          </li>
          <li>
            <t>If extensions to the MPLS data plane are required, they MUST NOT <bcp14>MUST</bcp14>
         be inconsistent consistent with the MPLS architecture <xref target="RFC3031"/>, target="RFC3031"/> <xref target="RFC3032"/> and <xref target="RFC5331"/>.</t>
          </li>
          <li>
            <t>Solutions meeting the requirements set out in this document MUST <bcp14>MUST</bcp14> be able to coexist
with existing MPLS mechanisms.</t>
          </li>
          <li>
            <t>Subject to the constraints in these requirements requirements, a Network Action solution MAY <bcp14>MAY</bcp14> carry MNA
information in-stack, post-stack post-stack, or both in-stack and post-stack.</t>
          </li>
          <li>
            <t>Solutions MUST NOT
            <t>Solution specifications <bcp14>MUST NOT</bcp14> require an implementation to support in-stack
        ancillary data, unless the implementation chooses to support a network action an
        NA that uses in-stack ancillary data.</t>
          </li>
          <li>
            <t>Solutions MUST NOT
            <t>Solution specifications <bcp14>MUST NOT</bcp14> require an implementation to support post-stack ancillary data, unless the implementation chooses to
        support a network action an NA that uses post-stack ancillary data.</t>
          </li>
          <li>
            <t>The design of any MNA solution MUST <bcp14>MUST</bcp14> minimize the amount of processing required to parse
the label stack at an LSR.</t>
          </li>
          <li>
            <t>Solutions MUST <bcp14>MUST</bcp14> minimize any additions to the size of the MPLS label stack.</t>
          </li>
          <li>
            <t>Solutions
            <t>Solution specifications that increase the size of the MPLS label stack in a
        way that is not controlled by the ingress LER MUST <bcp14>MUST</bcp14> discuss the
        consequences.</t>
          </li>
          <li>
            <t>Solution specifications MUST <bcp14>MUST</bcp14> discuss the ECMP consequences of the design.</t>
          </li>
          <li>
            <t>A network action Network Action solution MUST NOT <bcp14>MUST NOT</bcp14> expose information to the LSRs that is not already exposed to the LER.</t>
          </li>
          <li>
            <t>The design of any network action MUST NOT NA <bcp14>MUST NOT</bcp14> expose any information that a user of any service using the LSP considers
confidential <xref target="RFC6973"/> <xref target="RFC3552"/>.</t>
          </li>
          <li>
            <t>Solution specifications MUST <bcp14>MUST</bcp14> document any new security considerations that they
introduce.</t>
          </li>
          <li>
            <t>An MNA solution MUST <bcp14>MUST</bcp14> allow MPLS packets carrying NAI and ancillary data (where it exists) to coexist
with MPLS packets that do not carry this information on the same LSP.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-the-mna-alert-mechanism">
        <name>Requirements on the MNA Alert Mechanism</name>
        <ol spacing="normal" type="1" start="16"><li>
            <t>An MNA solution MUST specification <bcp14>MUST</bcp14> define how a node determines whether NAIs
       are present in the MPLS packet.</t>
          </li>
          <li>
            <t>Special Purpose Labels (SPLs) are a mechanism of last resort, and therefore resort;
       therefore, an MNA solution specification that uses them MUST defines their use <bcp14>MUST</bcp14> minimize the
       number of new SPLs that are allocated.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-network-actions">
        <name>Requirements on Network Actions</name>
        <ol spacing="normal" type="1" start="18"><li>
            <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that an MNA specification solution include support network actions for
private use (See Section 4.1 of NAs for Private
       Use (see <xref target="RFC8126"/>).</t> target="RFC8126" sectionFormat="of" section="4.1"/>).</t>
          </li>
          <li>
            <t>Network action Action solution specifications MUST specify <bcp14>MUST</bcp14> define if the network action NA needs to be
       processed as a part of the immediate forwarding operation and
       whether MPLS packet
mis-ordering misordering is allowed to occur as a result
       of the time taken to process the network action.</t> NA.</t>
          </li>
          <li>
            <t>If a network action Network Action solution specification allows more than one scope for a network action, an
       NA, it MUST provide <bcp14>MUST</bcp14> define a mechanism to specify indicate the precedence of the
       scopes or any combination of the scopes.</t>
          </li>
          <li>
            <t>If a Network Action (NA) network action requires an NAI with in-stack ancillary data that needs to be imposed at an LSR
 on an LSP, then the network action Network Action solution specification MUST <bcp14>MUST</bcp14> specify how this is achieved in all circumstances.</t>
          </li>
          <li>
            <t>If a network action requires an NAI with post-stack ancillary
       data to be imposed at an LSR on an LSP, then the network action Network Action
       solution specification MUST specify <bcp14>MUST</bcp14> describe how this is achieved in all circumstances.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-network-action-indicators">
        <name>Requirements on Network Action Indicators</name>
        <ol spacing="normal" type="1" start="23"><li>
            <t>Insertion, parsing, processing processing, and disposition of NAIs SHOULD <bcp14>SHOULD</bcp14> make use of existing MPLS
data plane operations.</t>
          </li>
          <li>
            <t>Without constraining the mechanism, an MNA solution MUST <bcp14>MUST</bcp14> enable a node inserting or modifying NAIs
 to determine if the target of the NAI, or any other LSR that may expose the NAI, can accept
 and process an MPLS packet containing the NAI.</t>
          </li>
          <li>
            <t>An NAI MUST NOT <bcp14>MUST NOT</bcp14> be imposed for delivery to a node unless it is known that the node
supports processing the NAI.</t>
          </li>
          <li>
            <t>The NAI design MUST <bcp14>MUST</bcp14> support setting the scope of network actions.</t>
          </li>
          <li>
            <t>A given network action Network Action solution specification MUST specify <bcp14>MUST</bcp14> define which scope or
        scopes are applicable to the associated NAI.</t>
          </li>
          <li>
            <t>An MNA solution SHOULD specification <bcp14>SHOULD</bcp14> define the support of NAIs for both Point-to-Point
        (P2P) and Point-to-Multipoint (P2MP) paths, but the Network
        Action solution specification <bcp14>MAY</bcp14> limit a specific NAI MAY
be limited by the network action specification to only one or the other of these
        path types if there is a clear reason to do so.</t>
          </li>
          <li>
            <t>An MNA solution specification defining data plane mechanisms for NAIs MUST <bcp14>MUST</bcp14> be
        consistent across different control plane protocols.</t>
          </li>
          <li>
            <t>An MNA solution MUST <bcp14>MUST</bcp14> allow the deployed MPLS control and management planes to determine the ability of downstream LSRs
to accept and/or process a given NAI.</t>
          </li>
          <li>
            <t>An MNA solution MUST <bcp14>MUST</bcp14> allow indicators for multiple network actions in the same MPLS<br/> MPLS
packet.</t>
          </li>
          <li>
            <t>An MNA solution MUST NOT specification <bcp14>MUST NOT</bcp14> require an implementation to process
        all NAIs present in an MPLS packet.</t>
          </li>
          <li>
            <t>NAIs MUST <bcp14>MUST</bcp14> only be inserted at LSRs that push a label onto the stack, but they can be processed by
LSRs along the path of the LSP. Two examples of LSRs that push a label onto the stack are head end head-end LSRs
and points of local repair (PLRs).</t>
          </li>
          <li>
            <t>If an NA a network action requires in-stack ancillary data, the NAI that indicates this NA MUST network action <bcp14>MUST</bcp14> be
present in the label stack.</t>
          </li>
          <li>
            <t>All NAIs MUST <bcp14>MUST</bcp14> be encoded in a manner consistent with <xref target="RFC3031"/></t> target="RFC3031"/>.</t>
          </li>
          <li>
            <t>If there is post-stack ancillary data for an NAI that is present in the label stack,
 it MUST <bcp14>MUST</bcp14> be possible to infer the presence of the ancillary data without having to parse below the bottom of the label stack.</t>
          </li>
          <li>
            <t>Any processing that removes an NAI from the label stack MUST <bcp14>MUST</bcp14> also remove all associated
ancillary data from the MPLS packet unless the ancillary data is required by any remaining NAIs.</t>
          </li>
          <li>
            <t>MNA solution specifications MUST <bcp14>MUST</bcp14> request that IANA to create registries and make
        allocations from those registries for NAIs as necessary to
        ensure unambiguous identification of standardized NAs. network
        actions.  An MNA solution MAY specification <bcp14>MAY</bcp14> request that IANA to reserve a range
        of a registry for private use.</t> Private Use.
	    </t>
          </li>
          <li>
            <t>A network action Network Action solution specification MUST <bcp14>MUST</bcp14> state where the NAIs are to be
        placed in the MPLS packet, that is whether they are placed in-stack or post-stack.</t>
          </li>
        </ol>
      </section>
      <section anchor="requirements-on-ancillary-data">
        <name>Requirements on Ancillary Data</name>
        <ol spacing="normal" type="1" start="40"><li>
            <t>Network action Action solution specifications MUST specify <bcp14>MUST</bcp14> state whether ancillary data is
        required to fulfil fulfill the action and whether it is in-stack and/or
        post-stack.</t>
          </li>
          <li>
            <t>Network action Action solution specifications MUST specify <bcp14>MUST</bcp14> state if in-stack or post-stack
        ancillary data that is already present in the MPLS packet MAY <bcp14>MAY</bcp14> be
        rewritten by an LSR.</t>
          </li>
          <li>
            <t>Solutions for in-stack ancillary data MUST <bcp14>MUST</bcp14> be able to coexist with and
MUST NOT
<bcp14>MUST NOT</bcp14> obsolete existing MPLS mechanisms. Such solutions MUST <bcp14>MUST</bcp14> be described in a Standards
Track RFC.</t>
          </li>
          <li>
            <t>Network action Action solutions MUST <bcp14>MUST</bcp14> take care to limit the quantity of in-stack ancillary data to the minimum amount required.</t>
          </li>
          <li>
            <t>A network action Network Action solution SHOULD NOT <bcp14>SHOULD NOT</bcp14> use post-stack ancillary data unless the size of that ancillary data if it was inserted into
the label stack
        could prevent the coexistence of the
        network action with other in-use MPLS network functions.</t> functions if it
        were inserted into the label stack.
	    </t>
          </li>
          <li>
            <t>The structure of the NAI and any associated ancillary data MUST <bcp14>MUST</bcp14> enable skipping of
unknown NAIs and any associated AD.</t>
          </li>
          <li>
            <t>Any MNA solution specification MUST <bcp14>MUST</bcp14> describe whether it the solution can coexist with
        existing post-stack data mechanisms (e.g., control words and the
        Generic Associated Channel Header), Header <xref target="RFC5586"/>), and if so how this coexistence
        operates.</t>
          </li>
          <li>
            <t>An MNA solution MUST <bcp14>MUST</bcp14> allow an LER that inserts ancillary data to determine
whether each node that needs to process the ancillary data can read the required distance into the
MPLS packet at that node (compare with the mechanism in <xref target="RFC9088"/>).</t>
          </li>
          <li>
            <t>For scoped in-stack or post-stack ancillary data, any MNA solution MUST <bcp14>MUST</bcp14> allow an LER inserting NAIs whose
network actions make use of that ancillary data to determine if the NAI and ancillary data
will be processed by LSRs within the scope along the path.
Such a solution may need to determine if LSRs along the path can process a specific type
of AD implied by the NAI at the depth in the stack that it will be presented to the LSR.</t>
          </li>
          <li>
            <t>A mechanism MUST <bcp14>MUST</bcp14> exist to notify an egress LER of the presence of ancillary data so
that it can dispose of it appropriately.</t>
          </li>
          <li>
            <t>In-stack ancillary data MUST <bcp14>MUST</bcp14> only be inserted in conjunction with an operation conforming
to
with <xref target="RFC3031"/>.</t>
          </li>
          <li>
            <t>Post-stack ancillary data MUST <bcp14>MUST</bcp14> only be inserted in conjunction with an operation conforming
to
with <xref target="RFC3031"/>.</t>
          </li>
          <li>
            <t>Processing of ancillary data below a swapped label MAY <bcp14>MAY</bcp14> include rewriting the ancillary data.</t>
          </li>
          <li>
            <t>A network action
            <t>If a Network Action solution that needs to change the size of the
        ancillary data MUST data, its specification <bcp14>MUST</bcp14> analyze the implications on MPLS packet
        forwarding and specify how these are addressed.</t>
          </li>
          <li>
            <t>Not more than one standards track Standards Track solution SHOULD specification <bcp14>SHOULD</bcp14> be defined for
        encoding in-stack ancillary data.</t>
          </li>
          <li>
            <t>Not more than one standards track Standards Track solution SHOULD specification <bcp14>SHOULD</bcp14> be defined for
        encoding post-stack ancillary data.</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes has no request of IANA.</t>
      <t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Solutions designed according to the requirements in this document may introduce new security
considerations to MPLS, whose forwarding plane on its own does not provide any built-in
security mechanisms <xref target="RFC5920"/>.</t>
      <t>In particular, such solutions may embed information derived from the MPLS payload
in the MPLS headers. This may expose data that a user of the MPLS-based service might otherwise
assume is opaque to the MPLS network. Furthermore, an LSR may insert information
into the labeled packet such that the forwarding behavior is no longer purely a function of the top label
or another label with forwarding context. Instead, the forwarding behavior may be the result of a more complex heuristic.
This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed
and the upstream LSR inserting the data causing that change.</t>
      <t>Several requirements above address some of these considerations. The MNA framework <xref target="I-D.ietf-mpls-mna-fwk"/>
also provides security considerations resulting from any extensions to the MPLS architecture, and these SHOULD <bcp14>SHOULD</bcp14> be taken
together with the security considerations herein.</t>
      <t>Individual solution specifications meeting the requirements in this document MUST <bcp14>MUST</bcp14> address any
security considerations introduced by the MNA design.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors gratefully acknowledge the contributions from Joel Halpern, Greg Mirsky, Yingzhen Qu, Haoyu Song,
Tarek Saad, Loa Andersson, Tony Li, Adrian Farrel, Jie Dong and Bruno Decraene, <contact fullname="Joel Halpern"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Yingzhen Qu"/>, <contact fullname="Haoyu Song"/>,
<contact fullname="Tarek Saad"/>, <contact fullname="Loa Andersson"/>, <contact fullname="Tony Li"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Jie Dong"/>, <contact fullname="Bruno Decraene"/>, and participants in the
MPLS working group Working Group who have provided comments.</t>
      <t>The authors also gratefully acknowledge the input of the members of the
MPLS Open Design Team.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-mpls-mna-usecases" to="MNA-USECASES"/>
    <displayreference target="I-D.ietf-mpls-mna-fwk" to="MNA-FRAMEWORK"/>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC5331">
          <front>
            <title>MPLS Upstream Label Assignment and Context-Specific Label Space</title>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5331"/>
          <seriesInfo name="DOI" value="10.17487/RFC5331"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5331.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.ietf-mpls-mna-usecases">
          <front>
            <title>Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data</title>
            <author fullname="Tarek Saad" initials="T." surname="Saad">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Kiran Makhijani" initials="K." surname="Makhijani">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Haoyu Song" initials="H." surname="Song">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
              <organization>Ericsson</organization>
            </author>
            <date day="20" month="May" year="2024"/>
            <abstract>
              <t>   This document presents use cases that have a common feature in that
   they may be addressed by encoding network action indicators and
   associated ancillary data within MPLS packets.  There are interest in
   extending the MPLS data plane to carry such indicators and ancillary
   data to address the use cases that are described in this document.

   The use cases described in this document are not an exhaustive set,
   but rather the ones that are actively discussed by members of the
   IETF MPLS, PALS, and DetNet working groups.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-usecases-07"/>
        </reference>
        <reference anchor="I-D.ietf-mpls-mna-fwk">
          <front>
            <title>MPLS Network Actions (MNA) Framework</title>
            <author fullname="Loa Andersson" initials="L." surname="Andersson">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Stewart Bryant" initials="S." surname="Bryant">
              <organization>University of Surrey 5GIC</organization>
            </author>
            <author fullname="Matthew Bocci" initials="M." surname="Bocci">
              <organization>Nokia</organization>
            </author>
            <author fullname="Tony Li" initials="T." surname="Li">
              <organization>Juniper Networks</organization>
            </author>
            <date day="7" month="May" year="2024"/>
            <abstract>
              <t>   This document specifies an architectural framework for the MPLS
   Network Actions (MNA) technologies.  MNA technologies are used to
   indicate actions that impact the forwarding or other processing (such

<!-- [I-D.ietf-mpls-mna-usecases] IESG state: I-D Exists as monitoring) of the packet along the Label Switched Path (LSP) of
   the packet and to transfer any additional data needed for these
   actions.

   The document provides the foundation for the development of a common
   set of network actions and information elements supporting additional
   operational models and capabilities of MPLS networks.  Some of these
   actions are defined in existing MPLS specifications, while others
   require extensions to existing specifications to meet the
   requirements found in "Requirements for MPLS Network Actions".

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-fwk-08"/>
        </reference>
        <reference anchor="RFC5920">
          <front>
            <title>Security Framework for MPLS and GMPLS Networks</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <date month="July" year="2010"/>
            <abstract>
              <t>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 06/05/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-usecases.xml"/>

<!-- [I-D.ietf-mpls-mna-fwk] IESG state: I-D Exists 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5920"/>
          <seriesInfo name="DOI" value="10.17487/RFC5920"/>
        </reference>
        <reference anchor="RFC6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="S. Amante" initials="S." surname="Amante"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="L. Yong" initials="L." surname="Yong"/>
            <date month="November" year="2012"/>
            <abstract>
              <t>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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6790"/>
          <seriesInfo name="DOI" value="10.17487/RFC6790"/>
        </reference>
        <reference anchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="J. Morris" initials="J." surname="Morris"/>
            <author fullname="M. Hansen" initials="M." surname="Hansen"/>
            <author fullname="R. Smith" initials="R." surname="Smith"/>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC9088">
          <front>
            <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS</title>
            <author fullname="X. Xu" initials="X." surname="Xu"/>
            <author fullname="S. Kini" initials="S." surname="Kini"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and Border Gateway Protocol - Link State (BGP-LS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9088"/>
          <seriesInfo name="DOI" value="10.17487/RFC9088"/>
        </reference> 06/05/24 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mpls-mna-fwk.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9088.xml"/>

      </references>
    </references>
    <?line 368?>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VcbW/bRrb+LkD/YZB+qI1K2jpp08TABaraTuvCTryWi6K4
uFiMyJE0NcXhcki7auD/vudlZjhDUU4Wt3tvCySURM6cOa/PeWGm0+l4lJlc
l+tT0Tar6ZvxaDxqdFOoU3Gr/tnqWm1V2VixMrVYmKJttCmtaDayEYu2qkzd
iOubq4V4r5pHU9+LecZ3HF2/nx+PR3K5rNXDqYBPyXrjUW6yUm5hm7yWq2aq
Fey+rQo73ZZyWke3Tk9ej0ePQB/t8ytsAtSKH2vTVkC7bNTa1LtTocuVQeJt
I8v8H7IwJay9U7BTpU/FfzcmmwgL5NZqZeFqt+WLzGxpl//BZ4FQ3My2y622
Fs7R7CpY5fLi7h3+LNtmY+rT8UiIKf5B/+nSAmkz8YPJMi3C13y2a9k0G/XI
P4bfTA2neW/utQxf1QY5rnLdmDp8qbZSF6diy4vMlrjI9yU+NwOyB8hYABn1
TpZNj4xFox4lSKr3I9HxS6kfVG11sxNmBTKta7UTl4uzPhV2+b3lZZa0ygES
fp6J81reqx4FP5tN2fuBdr8sc1Up+CMiy234u/pHjg98v5MbY3g7/L80NXAE
iCZB3L47e3ly8tZfvzn57ht//errVyfR9Ut//e0r+B72CY+8fE0/wReoRPHq
l9PzWaqZrVWZtMoe+Hn1eB+2efvya3/9+ru33fXb714Fsr79NpD19us3b/Aa
zzidToVc2qaWWYOf7zbaCrCYFnVV2EpleqWVFXXfREFRRK4eVGEquhVEetg8
xeNGZxshVyuVNfQoLAESRncAZMByBr6sRVWbTIE9wLd+vUpm96qxM3G3UVal
dMhaCWakysVyJ6Qo2+0S1oGHwRprUxkrC6ZX5qDy7FIMUUCrBzGYEq7p+0Iu
VQHr8cYoO3hAFoV5FLbFQ2RhmaUSlap5/4lQms5AdAA/S9B0gYxS9VaXsAUc
6grXFotH3WQb/HxrWvgZ9zjSMzWbEAF800W+Vv73qbi6uD2esVayzLY6zwuF
n74A1W5qk7dEF8tQIWOssHpdgvgyMCI4HaykLF54uSEFgRO5bKSoClkqOBl4
oDyHuy39nvAcWFuCnwHtFKSe4uPHw7r79IRy00F9QGRw2LUqVS0LsVXZRpba
bifEJOD5YQ2adFJAkkp3D3y5BcuFZSOFMjVL36tSDkqMPlYsgaZckKg7sbPm
QZxh8TemYhUQ4N3FHYQMYKA4KyQw4+ju7FgsdQPeHH8ELhXWEYD8ANbgCin9
6HhAAg2qIDwjy0wXhax3zHA8W0wNCpkVvWOw452zuJUuNdO9EuqPRpV2T6ll
DdrVgKW18BRuyuehiJXdCwM6K6PoCuqBmtwib2RWG5Z6QgLojKlzZBMcFwjY
6j9BwUDcpBSSFQ/8JnzxB/p33BQEsDWNYsWjPZe68D86yvkbb9vwBARPU8Tn
KpVCRsO+mSE2+ZPCRpZsauDINjgucgsfPzof/fQ0CR9e4gckhb5At4nKSl7x
PZJNrBlmabc48CVaHKRjs1ovSc2DcpP3Sdxd7NdgC8AX6w36Lqc34B02YPdO
7viILJFrsthZbb2WRYvAX7vCyPxLC4v7VQq5A3ltlMzZJ5EYwMY04BhRGiBV
HA27I4v+ZnFrj2dCvEPFLIrdBCMWnptUbyshhJcF/JFlLeh1E2iHVchtHD3n
yCAaKKfPdAowVj4HnA7MDJwWsBbNHbf3bLsAZjzIQpWZ8tb47uLseCaei1p7
3gtlYVNwCSsCN4ZdD1j4vs3SU8iCpSL1ZCXDrdLwBVIEpXbh4v8xfv2F4Wtx
OxOXJCfkTKMzXYE65cFY4ICPwCo4pW0LCjXAT4HYlvTWc95LKCPCGYqczMQ8
/Z5XjW0KITR8H/wE3WA5ObB4SOTU1h7CIqgrpCkUkFYKACjrGSsKumKfeMyI
oA8QDIEFW9MZfeY8pyPLh9AB18XeBVYrNGnE0QkEMZSktxWWxJE9dhijVhJu
xVjmHa9XGtSTHsG9IBN0ekbMvMNABoITX4YfvpygODR8phNMeEHWAwiBdHok
+JmF7/rWBC4ZkaNTPFwhSBj4A3aMq6tSLouBMLCEjZQqe2HEEsr54gtxR3pn
CrPeIWwdj77qkXYq5mUXy/r6jFEe4lrsJdGIWItKC6cgTwKakt41Hi0VSsuZ
srfLmvwXOMR5T3zkCMAYGNnybQLibKMmyeZdAJggIZo9SASI45s18n2rHDR5
lBAhyc31WRBhi6P388tjYonm7yKPEC9NJgM8UHWDcusdBrz8nmeYua3nwQue
E3KZn8N+dKn3WA3u2WSaXANGM9hwDYnO3nZEzHjkfCkDEAQbFUQ/5+X6LlX1
14Czs7cBNwmIo/8QJBdDj6EkU6/uiOhRTinTV5BVwyFAbwBnF+QRJKpzKVGF
YheMBkQwjeKEw46ZrGvdBYk46MK3NxKWPrpa3BzPOFH8CtxOwbd+esdZ74ln
N17czFiUl+V0QVAQxXfa54R/DM8faxCjSMKQbp0bY5vPWWlfQbzx4+LgfhoQ
XIxrUsDqubrSNeQvJmtU4+8Gnak9/AH+pTggNxA1SgP4qHZBBJEH2RREV6Sd
1+fUp1aZQlREaA3jpSXc5RLT7m4HqTiYoj85c1L6FSAy5x7zTonOAASWcJaf
+Kmj+dlPx457i8xgzQe9quUTMSzjqAYQsMi9FQYDctrLeV9SNruS5bqVa+US
QHGvdgIUPrfixfUvi7sXE/5bvP9A17cXf//l8vbiHK8XP82vrsIF3zEewacP
v1y5G/Cqe/Tsw/X1xftzfhq+Fb2vrue/vaDwB6t8uLm7/PB+fvWCvVEsHwxr
7GwoOIAEGvYAPuaT5vxwdiNOvhmPCGhjBQaANl1jBQauQaQlx1qCpPwRhAbe
taqUrEn7igIreJVuAE5NKEHYmMdSIA4lZs4LxNwAw1MKNeuP7OJ7AgMmfDuY
KciGPS4oRG6qhpIWDPYZWIOrePGpKp+8xZHUpfZfDMGWXjXzM0s0xtlb6vZs
sCXIZTYcXVEEDkMBVtyoLTIMn50EHX8uq7UUeuwx1y4i99nPdCFeTML2AOTr
JsqRCKW6yEVKAf4C0CbbAq5PyoJ2TGLp+xMXH/cACj7ki1VLtZEP2tTedQSR
Biqsz1vBEbS1t0QCObqBwC6WrS4oGVkWJrsHYWCaBstxdUt3LNmHebz2YfYg
pQynWvBvOR3oMnJhLGbn5BXE7oKy9W7pNFCi5+oTQBUIt+l4RLsitmFGw4+Q
mkV8tJjiO1bJYbceOUVV5tPGTOGvAWevKR+WDUKjFTlICVkiiSgJBD55pAIB
X95cOBztLLHC4jJT1UumwIQWmqPj1IeNlMMludPpxlSi7/ypyuBwj6wJh3Qs
JVvGGOqSIsyNBZb91z6sTvZsr4k4yFa0L25vwuzmuCiKcQdFaFXWoWHCwz+6
olnfG3w8hXPUzX+9OHnxxFkUiP4TYF5QJCBI4cF7Rdi80ZyoJeWZCboyLOz4
jyQfRBgaMDRWFtCNslnSuSu4LRGsxzFcXsRPsAEtYwn9C6eO/DvhwOCD8C4X
f3xYEBuqAnIiJ7ONVg9gMcgMd/wowzcDqsLHh3VCPRA38dER4WRTa4bloVjp
fPhwQehQgamrL2En4OnJ03h5sHQXsYGTPqI6dwEtkEghE92Ftg1yfjwimP3X
UNc137ZKNT7DTRhIeKVt9kO65yylfFS0ozqdJzAt2nWON2zdLn+nhMh4veH8
srFOufYqKIdVfP4bOSoyhqjfQmkR2/4k9gPglygPjtxH7OH2mRPpC9dnZT+X
jSLrIa+EttWWha+0957PNsZg+TVaRw7mUC0XaQe3+N9SHvHoP0f7wU089XcU
96im4MJbUm5gh+Yr0xSztqbltlQUGb09IVXk6AVBnji1wWomx8QDjAu7UFW2
X5WLw+Zg1pQsSAwAS64VeKJPPk+hFcsB7jkOiVh4J/dadKmej6QQ0pnoXNus
dYKK6h+2T1K/zLX38MXZ9U2ygieWhcPFAqrl9WSdigq1T/1RYYE0tkzHRIqw
8RllARzKd+6RPNx3cXtYP3r797fFW5KtuTBCCaVbAS4fdIYBSXexng6vcyyd
EedXGlvKGiIzNxLefvfKJyjYc913q8MsDjkRUf6IAKClxMFvF3dsKBigT+O+
n+q4Xg6YBRd/k6YDOUY8FEDrwbYUV+ghjJPHtscDvrzXxcBSrSFhsdfl+Bz3
2Rw6kFsuRYgAbW4HwBMeY05JwnVIEkSKd14HwDNwaGqUMVKQlFcjaqaSIqis
rwIMJRa9gtnMF6cXKDWQ8k1bk/5QGQeSn8XNFbAHF4l7PqBBhbTYw8FJkJD3
1Gpl2N8mFKMT8p6QMrB9d9Y1BlA7cFOnsbgcCBjzpnx2gKG9OnjKxjeOjVzX
jzJ5t4GjNanMe4/eTzFWrvWqHzCNwzL20UIpsXB9o29mJ3gCl72/fP30dBxU
933PXQwYic+B9GAhEDE8uWEs4UbYnWo0Ud4Agcq3weKecSgko6i8gsRZzHi0
1XZKbVB8QFs2LPZGrhGGW7neh9us0aDujbxX5NwcVUMFyQ4a7oXJoCeSy1LU
j6CGtQEVt1hG4hZR78EJGjBxDvZ9ACeSqCgG5iipdPUvcOmhZEoru7wRHdF2
SY0gLl90NwQREu09PHaE0x9d978kj0P+41CeRloXhLkkYEFOPwRmMEmu7lPq
BYSUQ/ow3GxKNWkokXD1IpHpGnwyDnlFcXJIPIOnOwhoDh/q//xM4rPcRVTq
SRzHy1fecQAYqFnfEFNRiyPCXGhPgCDguGFugfyuS+ri6Yk0PUiSwm5oIajb
r65PHrIEH6WjuZK+pyVOuY6Uiwuayee5ka3JgYcuMlruy4XA4R0PnH/dlaDh
xom3ES4Wh8IV9hQc3Ah34rSFzDJV0WhRVGboV00Q1UWHgoe7FJf0LMkGnTqh
G8hVgYN2O26h0xkdTNfk4u9LLH2G+Qa6AUcRXRs1El1v3zv+6HEWa52LBJAR
hlSRPRKFqiQ8BPqHu0HP6DQX2Ny6tXdMFPuqqoBHXLrZK0GmPEsUwWmfJ580
cuVzwBsD0ArrWXQhjm5e3hyTqMIP1+DideV/vYafK9ls7EQsW0SR/igsJ8hE
KSYVEM6bDqQ/e3yMKTRhwS1ovJ+VKxS/cEPXWme95JkvKbICq96YUvA6AMus
OcQHHijCIanO1qKCKLKEeOMT+6jo4GaFwGBWXP9xeQgAAFrGF1jt58BTTiGq
wuz8GJgvGiHft7KUay4Y0to2tUsSu2srY6Ed9Bs8gpJbziR4BIJtDlb7m6k7
m3Oq+IymRET2KrxbUoKiL0kbCmEIdeksYcTl2U0+mZIHqsGVk1QOF8Q9qgqy
I21aenfHkafLs6rWYpeWk01gvEtmuUqCOu2GxJK2+HjUK4WSSjq3SBD/7tGA
A5R4EEoUP2tDsmvssmFV2UuQqzHaTSAi3sUpk0rqGgzwioaVohCNAu3i8sHa
i/NvPg3n7oPl6AkLeJ1HRJvkBwM5/dyLxD/EY0UceVF/S7DdyHgIJESVuY74
YMmHIQSBvTIi3fYzmIhCLNMEIIgiBKPVzl9CfqZqD/+sn4gYKPn7mTRsoaCw
ffkEdnHGm3ZxYw511r9Lg4vE/GhrHjroFDr4cdXDGaA17m5S/8jLo3Kk7PGr
xOE0qlT1bu/GU3nYA8iscTK89DDAyzix2KEEBZfBEdvLOdyJGTP4oAYrlmuN
JWVlnTO7DzkbZ01Mr7HJrcH1wvlwDhL5Jjmqq9JiYbctJUDydWta0HGqQoTw
gW0HfD0Bs5s/KRLaAacDgalPMqpBjTwWtSzXiucnpKdrR1RF+d3sk+WeoaiO
4zHREGBIw10HppBZ1xNJJgQnQd99hsaN3jp6qqvn9qq3A0i3N9OS4Ntvvnb4
9t/ITD1V+xo2HsW1x1VbrHTBypjtZZ0M0+JC9N/2T/Nvp8zDnBnMvni+z9Xc
DtdGSIGWqLSPtW7ArXX9xP1SJyrOoZTvUNeAZ4do0joESLME1YLIf7iXIBbY
cLNp1Xap0qkCKRbOPvCsdzVSBc44lHv6vE1Xw4Qe61xELcE64s0/WxyKZBBy
ML3lSEfFnXbry9ReOT5tT90sBmVNhyUZObyuqEzpZqqbK9S3R5q7cshAl1RF
6fvhjCdSaoXDDq6STEKI40aPbJIgA1dgCBKcTCWs2jJNDajzTD1wdHBdhuWK
lLtnOuhxamfvdVW5Vjg2KTjlYT+zv9D8PG4eHvbyvrLYmyXSjI4SpQ3K2e80
j0cRuj5Ss/VsEpAuj+v4EQlq+EIKcXCYyI1TaJyr7bL+RCaUNKvPAuBotxe3
HgqhJtgB1e0w93jkz68kmBtlkWnpJi527U0QYNlE5nFnkaoEjRtwYytJRuWF
dNOLtNURvm2ABhgan11ly0/l43tOWGJ0h3/nM8dDUWIPHw63mRJ+ddUD0q5H
iuLdFL7PCNJ3RPatcKjMcKA2j+V3AEB9ME44ORrZ42Q5xeaoB+QcZXckrFH4
8YeEhCFsj3LrUqeQ5WIWykhhfk5pSzR1SKdofH5Hdb8I6rO6NaI7EgWbqMXT
xZJ5JGI2drK3hroOGOSAONX1vcKYTwdse5y0xhXenQVzlYruhG9khTMRNVpe
seuyi+dC2F6OpdEtlL87L+fjWVRsdi+1gP5QkholBP7UNwcd/H9uy94oUbIr
I35g3iOO1/l3ixAJ6DIr2tzDAV8M6rVzP90fTJ0ICny93xodYgW9IePaJeMR
qaHHQiYtrUV1fxpCSSqnfuDevQHnB6ARE5imX3sPGKIhBNGP0kv3xparzFFO
SM2D51v1f91Gz/fV6eVBBP5nSZNxf8gQ3Rd2YkO6AGLAB2kVfl3KIHwSF/Re
8SmHIhu9LkQwEbM3mrep2qUXDjVNyvGIwRdStPCtz32qOjjJNUiagcsMi9J5
jGQ+ZG9ABWkJfdOk00rd3KTVatwIEjv1SGlcSboENwG6BcgimjR2jRaIHDgt
2Ew1nC00c6PYz4M3b1/Sa2ekYZcltal01oKU3PBlhzuplrxl9No1VbEZhTzt
p7w0EE0t4u5bHly27o3MqDbdAf+u/+2fmvKMlG+Fb/V60zCge9QU6QBHAWcx
ZTCVBOVIxpmcjUPsbWt8BpV64kcOWRTotuIjUVvbdEWA7k0mYkgoW0fiCJOd
NC0gMGThyDYgyALf3fAgM7Tkwhue9OaxLBmf8lfkL6O13bAadTkaYODk4OZO
y1kFfQtQsh27VyNBBKAHAAyzmbMwrhBYX+7TGWYSdUudY35Rx250lQzTIev2
NDJmAb/Awo4z58oZPtdWXU00gi0UmBmTtV1dhp8mg1wA3q+p2hbPXS2pEONe
EuaXVXxhOjUjxvSIola13Cpy+UOvDK8e75+e/Cu1zozswTEI5jCSS5qP5vYZ
L8OGPjxQ2TlO6s5iLFwzng2I8tDmWLjQbtQFm2NAagsMOlQaOjhFNzw955mK
Z4pcR4+G4MMC0EIWuyEc9qPzDNMeMKB1PDsOUqN/XMKKNeYGq7ZAI+ludYkd
LK+XPnVHFv9sMPGQBeCIciJ+rBUk3rq297uJ+A1O9yd2LP/eTuAWs2sh78cu
IOwHkfReLCQazpWRkICgC7LYK7wzcMArPRHzHEBWKd7JGnR+In7WSpwbF5p/
qFuw6HOV1RLSIZYfO0ldyW4s0CUKj+6f7FjjP9mBRoL1SuW1KQ//BId/abTj
BWndMwzhd5KcA9miH6795JPb+0MFDDjnztgdmNnMv6m/hLU42P4LF7m4TwRF
AAA=

-->
</rfc>